¿Puede usted ser administrador y programador al mismo tiempo? [cerrado]

Depende de la cantidad y el tipo de programación que debe realizar y de la cantidad y el tipo de tareas de gestión que debe realizar.

Ser administrador significa muchas interrupciones, cambios de rumbo y cosas como reuniones, etc.

Si su programación está "limitada" a pequeñas piezas de trabajo no urgente, puede ajustarlas en torno a sus tareas administrativas. Si necesita dedicar una cantidad significativa de tiempo "de calidad" a una tarea de programación, entonces no obtendrá ese tiempo debido a sus responsabilidades gerenciales.

Si su equipo es grande y / o complejo, tendrá que dedicar más tiempo a administrar que si fuera un equipo pequeño dedicado a uno o dos productos / proyectos. Descubrirá que simplemente no tiene tiempo para realizar una programación significativa, incluso en tareas pequeñas.

En un trabajo anterior tuve este rol y funcionó para mí porque mantuve mis tareas de programación pequeñas. Realmente funcionó a nuestro favor.

En primer lugar, pude evaluar todas las solicitudes recibidas y, si fueran pequeñas, agréguelas a mi cola (que siempre fue corta) o regresé al cliente (en este caso, a otro administrador) con una escala de tiempo más precisa para cuando El trabajo se haría.

En segundo lugar, significaba que a los desarrolladores del equipo no se les quitaba constantemente su trabajo actual para corregir errores menores o hacer pequeñas mejoras.

En tercer lugar, los clientes estaban contentos ya que sus problemas urgentes se solucionaron con bastante rapidez.

Me mantuvo en contacto con el código base para poder tener conversaciones significativas con mi equipo sobre problemas y con mis gerentes y clientes sobre escalas de tiempo sin tener que involucrar al equipo todo el tiempo.

Formé parte de un equipo de desarrolladores donde un programador también fue nuestro gerente. Esto llevó a un colapso total de cualquier cosa que se asemejara a la productividad. En resumen, todas las decisiones fueron tomadas por ese chico + él era un micro gerente completo. Cualquier idea o sugerencia con la que él no estuviera de acuerdo fue rechazada o rechazada. Esto eventualmente mató toda creatividad y motivación.

Por lo tanto, creo que es una mala idea tener a alguien en el equipo de desarrollo en una posición "superior". En mi caso, el tipo era un administrador de comando y control, pero incluso un gran administrador influirá (involuntariamente) en los otros desarrolladores, lo que finalmente lleva a un rendimiento más bajo. Al menos el equipo le está reportando.

Sí
He visto a algunos gerentes que eran programadores y gerentes al mismo tiempo, Créeme que trabajar con estos muchachos fue maravilloso.
Ser gerente y programador no solo permite a los gerentes liderar desde el frente, sino que también motiva a los subordinados a dar lo mejor de sí.
La mayoría de los empleados se quejan de sus gerentes de que los gerentes no valen la pena, pero el gerente que no solo administra, sino que también escribe el código, siempre ofrece los mejores resultados.
Los dos gerentes que mencioné, la programación fue su pasión, que no solo ayudó a otros, sino que también produjo una aplicación casi sin errores.

He sido gerente de proyectos de programación durante años, con diferentes compañías, proyectos y equipos.

La gestión de proyectos y la programación son tan diferentes tipos de trabajos / roles, que diría que no se pueden hacer ambos al mismo tiempo en un nivel "excelente". Es un compromiso: maestro de nada, jack of all trades, tipo de cosas.

Para mí, el mayor problema es el cambio de contexto entre el modo de administrador y el de programador. Parece que se involucran en diferentes partes del cerebro (o algo así). Un día programando, algún día administrando puedo hacerlo bien, pero cambiar entre esos roles constantemente es difícil.

He visto ambos escenarios. Los administradores de desarrollo hacen {cierto porcentaje de su tiempo} de codificación, y un administrador de desarrollo, sin hacer ningún tipo de codificación.

El problema es que cuanto más alto sea, más probable querrá que se le pague más, y la única manera de obtener eso en muchos es mudarse a la gestión. (No todos, por supuesto, pero muchos lugares). Por lo tanto, esto puede hacer que las personas que realmente no están preparadas para ser gerentes queden atrapadas en esa situación.

(Por supuesto, hay compañías en las que puede ascender a través de Dev, Dev lider, que es diferente de Dev manager, por supuesto, a posiciones como Arquitecto, etc.)

Lo más probable es que, siendo un técnico, puede ser inútil en la gestión de personas, además de que lo aleje del código. Así que te conviertes en un mal administrador, y estás haciendo menos de lo que disfrutas, ¡y presumiblemente te metiste en el desarrollo para!

Para mí, para ser un gerente, realmente debes estar fuera de la codificación, pero mantente totalmente actualizado con la tecnología para que al menos puedas hablar de temas con coherencia.

A medida que sucede, comencé a trabajar independientemente por este motivo. No me interesa la gestión de personas, y creo que no sería particularmente bueno en eso, además de que no llegaría a codificar tanto.

Se puede hacer, pero está lleno de trampas. El tamaño del grupo y el nivel de interrupción juegan un papel importante, pero el riesgo más importante es que el gerente también sea el líder técnico. Demasiada opinión de mano dura cuando no hay suficiente tiempo / esfuerzo para justificar la opinión puede llevar a algunas malas decisiones. Y, el debate sobre la dirección no es un campo de juego muy nivelado entre un gerente y el resto del equipo.

Para aquellos que están considerando este camino, algunos consejos:

• Salga del rol de arquitectura e identifique clientes potenciales en su grupo.

• No funciona en los elementos de ruta críticos. Arregle errores, trabaje en prototipos u otros elementos que se puedan descartar rápidamente cuando su jefe encuentre muchas más 'cosas importantes' para distraerlo.

• Eleve su nivel de atención y enfoque hacia la eficiencia general, defendiendo y promoviendo el equipo, el proceso, la moral y otros aspectos necesarios para tener un equipo exitoso. Es probable que su objetivo sea mucho más que un proyecto exitoso (independientemente de lo que digan su jefe, PM u otro).

• Ayude a su equipo a crecer: ser más independientes, auto organizados, adeptos técnicos, un mayor nivel de conciencia.

• En muchos sentidos, usted es el o un puente entre el equipo y el mundo exterior. Una parte importante de su enfoque debe estar fuera del equipo.

Para responder a la pregunta, sí, se puede hacer. No, no es fácil y muchos nuevos gerentes de la parte técnica de la casa, que pueden haber sido grandes líderes, no pueden hacer la transición al trabajo de un gerente exitoso.

Un buen gerente puede ser, sí. Mientras se mantenga asertivo y consistente, generalmente no hay problema.

Si se les dice a los empleados que mencionen los problemas de los compañeros de equipo con el gerente ... y el gerente también es un compañero de equipo, puede ser difícil. Es esencial ver todos los comentarios de manera objetiva y darse cuenta de que puede estar equivocado de vez en cuando. También debe proporcionar algún tipo de medio anónimo para comentarios.

Es extremadamente común (como dijiste) ver esto en empresas nuevas.

Creo que no.

Ambos trabajos requieren mucha concentración, energía y dedicación. Es muy difícil realizar ambos al mismo tiempo. Cuando tuve que asumir algunas responsabilidades de liderazgo del equipo, se redujo la cantidad de tiempo que pasé en la programación (y, por consiguiente, la cantidad de trabajo relacionado con la programación realizado por mí).

Conozco a otro colega que asumió el rol de gerente de un rol de líder de equipo y dejó de programar por completo en un mes (aunque intentó hacer ambas cosas).

También conozco a un arquitecto a quien se le pidió que se hiciera gerente. También dejó de codificar dentro de un mes después de asumir responsabilidades de gestión. El mismo arquitecto después de 8 meses tuvo que volver a la codificación debido a problemas de campo críticos. Él contribuyó significativamente en la corrección de errores, pero dentro de un mes, tuvieron que encontrar un gerente de reemplazo para que asumiera sus responsabilidades administrativas.

En mi experiencia limitada, no he encontrado a nadie que administre otros programadores y códigos como un programador completo.

En mi opinión, aunque es posible en la mayoría de los escenarios, no es un buen acuerdo. Hay numerosos artículos sobre cómo las personas que son competentes como desarrolladores son notadas y llevadas a una función de gestión de equipo, aunque este no sea su conjunto de habilidades específicas o incluso una posición deseada. Luchan por mantenerse enfocados en la "administración" porque consideran que el "trabajo" es hacer la programación, no crear informes e ir a las reuniones.

Spolsky escribió en su artículo en la Developer Abstraction Layer lo siguiente:

"Con una compañía de software, la primera prioridad de la administración es crear esa abstracción para los programadores".

En el artículo, (opino pero creo que bien razonado), el rol del administrador no consiste en ingresar el código o el desarrollo del software, sino crear un entorno donde aquellos que lo producen puedan centrarse completamente en él.

Mi ex jefe lo intentó. Hubo demasiadas interrupciones de su función de gestión.

Él sigue siendo uno de los mejores desarrolladores que conozco.

Absolutamente puedes, pero eso no significa que sea fácil. Se necesita un cierto tipo de persona para ser un buen desarrollador, se necesita un cierto tipo de persona para ser un buen gerente y un cierto tipo de persona para ser ambos. Si puedes encontrar a esa persona (o eres esa persona), hay ventajas definitivas. Los gerentes de programadores de primer o segundo nivel deben entender realmente lo que hace y se encuentra su gente todos los días. Es difícil de hacer si no era un desarrollador y es difícil mantenerse en contacto / actualizado sin seguir desarrollando.

El mejor gerente que he tenido (he estado en el negocio ~ 25 años), fue un desarrollador activo, mi gerente y medio propietario de la empresa (alrededor de 40 emps). Era especial, pero claramente tuvo éxito en esta pregunta.

POR SEGURO NO !!

Puedes intentarlo, pero terminarás administrando más que nada. El problema es que no puede codificar cuando las personas lo llaman cada 5 minutos o cuando intentan hacer reuniones de "estado" cada hora. Es ridículo ... lo estoy haciendo ahora, por lo que me topé con este hilo.

Aunque un gerente de una empresa de tecnología DEBERÍA .. no ... DEBE saber cómo codificar. Simplemente no podrá estimar o entender los problemas del cliente. La codificación y la gestión son dos tipos de personas. Un lado son geeks y son incómodos con la gente (enfréntalo, geeks, sabes de lo que estoy hablando), y el otro es bueno con la gente. Debes elegir un lado. Usted no llegará a ninguna parte con la codificación si hace ambas cosas. Si le encanta la codificación y puede hacerlo las 24 horas del día, los 7 días de la semana, si su esposa no se interpone en su camino, MANTÉNGASE DE LA DIRECCIÓN Incluso tomar un recorte salarial si es necesario. Estoy a punto de hacer esto, pero no creo que a los jefes les guste esto porque les hago la vida más fácil haciendo la parte de administración. Tendré que volver al trabajo independiente si no están de acuerdo porque la felicidad y hacer lo que amas es mucho más importante que el dinero y las ilusiones que compra. De lo contrario, terminarás siendo un esclavo como todos los demás.

Mis mejores deseos con tu esfuerzo y por favor, sigue publicando estas publicaciones. Ustedes son increíbles.

Lea la sección "Falta de una ruta de carrera centrada en la programación" en este sitio. Cosas bastante buenas y muy relevantes: enlace

Es posible que una persona tenga tanto un buen gerente como buenas habilidades de programación, aunque el dicho "un gato de todos es un maestro de ninguno" viene a la mente ...

Sin embargo, la combinación de ambas funciones al mismo tiempo me parece propensa a realizar ambos trabajos a la mitad. Depende de la cantidad de administración que se deba hacer, pero inevitablemente se trata de hacer malabares con dos tareas de una naturaleza completamente diferente, y el cambio de enfoque que esta demanda es bastante grande. Me doy cuenta de que me desempeño bastante menos en la sección de codificación cuando también tengo que realizar algunas tareas de administración (en mi caso, administrar los cursos y redactar informes).

Otra desventaja es que estás administrando un grupo, pero también eres una parte directamente involucrada. A veces eso vale la pena, a veces puede causar grandes problemas. Si otros programadores no están de acuerdo con su trabajo, el hecho de que usted sea el administrador puede evitar que estén completamente abiertos.

Nuevamente, cuando estás codificando en el mismo proyecto que estás administrando, mantienes un poco más de sensibilidad con el código en sí, por lo que en ese caso el bit de programación puede ayudar al bit de administración. Todo depende de lo que tenga que administrar, cuánto tiempo demande y cuánto se mantenga relacionado con el código en el que está trabajando.

Así que supongo que no hay una respuesta clara, pero tiendo a evitar mezclarlos demasiado. Mis 2 centavos

bueno, he leído que los gerentes de proyectos de software definitivamente deberían ser programadores.

Creo que un administrador es un administrador por una razón: para administrar. Tomaría esto como una regla de oro ... algunos pueden ser una espada de doble filo.

Conozco un caso donde funciona. El hombre es una especie de adicto al trabajo, por lo que trabaja a tiempo completo como gerente y casi a tiempo completo como programador.

Teniendo en cuenta las horas de trabajo normales, no creo que una función tan doble sea una buena idea. Un programador administrador (o administrador de programación) siempre está tentado a hacer gran parte de la programación por sí mismo, en lugar de hacer que sus programadores lo hagan. Siempre existe esta excusa "se necesita más tiempo para explicar que para hacer", pero a la larga, el 50% del trabajo de programador que hace falta en la parte de administración, por lo que otros programadores son menos eficientes.