¿Cómo saben los gerentes si una persona es buena o mala como programadora?

Típicamente, un administrador mirará

• ¿El programador hace las cosas?
• ¿Qué piensan sus colegas de ellos? ¿El código que escriben?
• ¿El programador se comunica claramente con el gerente?
• ¿Le gusta al programador aprender cosas nuevas? ¿Aconsejan bien a los demás?
• ¿Necesitan mucha atención de la gerencia para hacer las cosas?
• ¿Parece que el programador se divierte con su trabajo?

Es cierto que generalmente no ven (o no entienden a menudo) el código de los empleados, pero lo que antecede para ellos sirve como un proxy razonable para medir qué tan bien un empleado encaja en la función de programación que le impone su empleador. Si alguien no está haciendo las cosas, obtiene calificaciones bajas de sus colegas, no puede comunicarse bien, se frustra con una tecnología diferente, entonces está acostumbrado, siempre necesita supervisión y siempre está descontento, es una buena indicación de que no lo son. encaja bien con este trabajo. *

* Sin embargo, puede ser que en un contexto y entorno diferente sean muy felices y entusiastas. Tal vez solo sea ese tipo de programador al que se opusieron, y podrían hacer muy bien la programación en un contexto diferente. "Programador" puede significar trabajos muy diferentes en diferentes lugares. Pero el gerente se preocupa principalmente por su función de "programador" y por lo bien que se adapta un empleado.

No estoy de acuerdo con la afirmación de que los gerentes no miran el código. Cuando he dirigido equipos, he analizado algunos de los resultados de cada ingeniero, y uno importante es el código. Pero no es el único: correos electrónicos, documentos de diseño, informes técnicos, todo esto tiene su importancia.

Pero ese definitivamente no es el único factor. Si un chico está sentado en un rincón y escribe el código brillante pero es una bestia con quien hablar, no responde las preguntas, no comparte el estado y no se compromete cuando surgen problemas de desarrollo. No estoy tan seguro de que sea un activo para el equipo. Especialmente comparado con un tipo que escribe código moderadamente decente pero puede hacer todo lo anterior.

Aquí hay algunas cosas que veo cuando estoy en posición de entregar recompensas, pero con la gran advertencia de que es absolutamente una reacción visceral, porque nada de esto se puede cuantificar:

• Estado : es claro, preciso y & ¿oportuno? Cuando se discute, ¿está la persona en la cima del estado o un poco borrosa sobre los problemas actuales? ¿Tiene la persona el juicio correcto para levantar una bandera roja cuando algo se ha incendiado?
• Resolución de problemas : tanto preguntar como responder es importante. ¿La persona sabe cuándo pedir ayuda o dónde hace girar sus ruedas de manera indefinida? Mejor aún, cuando otros tienen problemas, ¿la persona ayuda a encontrar la solución o se convierte en parte del problema? Incluso vale la pena tener algunos puntos para tener la sensatez de retroceder cuando el problema no está en su área de especialización. También hay puntos para ir fuera del grupo o la empresa, e ir a sitios como este u otras respuestas de Internet.
• Atención al proceso , por lo general esto es bastante obvio, incluso en una compañía que no es anal-retentiva, si alguien está desvirtuándose del sistema, se ve en el caos que dejan atrás. Si otras personas están limpiando las características de otra persona porque no se adhirieron a la orientación o la arquitectura, entonces tenemos un problema. Los puntos de bonificación van a aquellos que descubren formas de hacer que la consistencia y la calidad sean más sencillas .
• Tasas de finalización frente a errores frente a complejidad : haga las cosas, pero hágalo bien. Todos tenemos algunos errores, pero si el tipo se hace las cosas rápido y con problemas, tenemos un problema. Por lo general, encuentro que esto no es algo que se pueda evaluar en el sentido cotidiano: tiene que ser una revisión de una versión, una fase o un trimestre fiscal.

Y el aporte de otras personas. Con frecuencia he estado en una posición en la que varios ingenieros estaban a cargo de varias partes del proyecto. A veces, los líderes del equipo y, a veces, solo los propietarios de una pieza particular de producción (como "el tipo de compilación"). A la gente le ENCANTA hablar de los extremos: los actos de heroísmo o la frustración de los niños problemáticos. Por lo general, en el acto de dar seguimiento a estas cuestiones, descubro mucho sobre AMBAS partes.

También hay un factor en eso relacionado con Managing Humans . Ningún ingeniero es exactamente como cualquier otro. Así que no todos brillan bajo la misma luz. Uno escribe código libre de errores brillantes, pero otro ayuda a resolver problemas transversales que rompen el código de todos. Uno es genial en persona, uno es mejor por escrito. Uno es incoherente a las 9:00 AM, uno está fuera de aquí a las 3:00 PM. Hay una cierta necesidad de dar un paso atrás, averiguar qué es lo más beneficioso para el equipo y lo que podría ser un factor de sesgo personal (como el deseo de matar a ese chipper a las 4:00 AM, solo porque no puedo funcionar hasta las 11: 00 AM).

Esto varía una gran cantidad dependiendo de la experiencia técnica del administrador.

• En su mayor parte, probablemente te estén juzgando por la forma en que te comunicas . Cómo se comunica con el gerente y cómo se ve cómo se comunica con sus colegas.
• Si tienes suerte de tener un desarrollador líder que esté más cerca del administrador, el administrador puede buscar información del desarrollador principal.
• Tenga en cuenta que la responsabilidad principal del gerente es hacer las cosas . Necesita ver cómo se producen diversos resultados y objetivos para cumplir con el plan de negocios. Entonces, si de alguna manera puedes ver como si tuvieras una influencia directa en el resultado , esto será un buen augurio para ti.

En general, no lo hacen.

Es por eso que la programación es un "Mercado para Limones". enlace

El código se confunde, y por lo general no es por 2 o 3 años antes de que lo sepa. Los programadores suelen quedarse 18 meses, por lo que nunca ves a los culpables en el fallo.

Los gerentes deben tomar su palabra de que, por ejemplo, un lanzamiento lleva cuatro meses y cien iteraciones. ¿Quizás esté editando muchos archivos de implementación a mano y leyendo los archivos de registro en busca de errores mezclados con el estado? No saben que podría hacerse mejor.

Así que sé honesto, profesional y trata de mejorar. Con la experiencia, un gerente comenzará a ver patrones de comportamiento bueno y malo.

  

¿Cómo saben los gerentes si una persona es buena o mala como programadora?

Comenzaré con una generalización general: la mayoría de los gerentes no pueden distinguir a un programador "bueno" de un programador "malo".

Con eso fuera del camino, lo que la mayoría de los gerentes (me he reunido o trabajado) considera "bueno" en un programador no es el mismo conjunto de habilidades que otro programador consideraría "bueno".

  

¿cómo lo hacen?

Un administrador orientado a resultados buscará cosas como "inteligente" y "hace las cosas". A ellos no les va a importar si te presentas a trabajar en pantalones de chándal siempre y cuando hagas las cosas a tiempo y dentro del presupuesto.

Un administrador orientado a procesos está más preocupado por "cómo se hacen las cosas". Esto significa llegar al trabajo a tiempo, usar la ropa adecuada y si tiene la portada correcta en el informe del TPS.

  

la persona trabaja bien, si se le debe poner a cargo de algo

Estar "a cargo" requiere diferentes habilidades que escribir código. Si una persona tiene las habilidades de las personas necesarias para liderar un equipo, entonces esa persona debe ser aprovechada para hacerlo. Si promocionas personas en función de los elementos clave del trabajo que están desempeñando actualmente, eventualmente llegarán a un nivel donde ahora son incompetentes. Esto se llama The Peter Principle .

Obviamente, siempre es útil contar con un administrador con conocimientos de programación que realmente pueda leer el código y, lo que es más importante, profundizar en el sistema de seguimiento de errores y entender lo que está sucediendo, saber que no todos los errores se crean de la misma manera y que solo se entrega el código incorrecto a tiempo. no cuenta mucho.

Pero ese es un caso ideal. Para que un gerente obtenga la medida de un programador desde una perspectiva no técnica, tengo un par de sugerencias.

• ¿Resaltan de manera rápida / regular / consistente cuando hay problemas para hacer las cosas para cumplir con los requisitos actualmente especificados ... y son completamente molestos por eso (después de todo, esto es desarrollo de software, si no es lo suficientemente complejo como para tenerlo?) estas cuestiones, no es un proyecto de desarrollo real).
• Si no están seguros de algo, ¿lo dicen inmediatamente? Sólo un programador que confía en su propia capacidad lo haría (y sabe que si no te gusta, pueden conseguir otro trabajo fácilmente). A la inversa, alguien que sabe que están fuera de su profundidad tiende a esconderse y buscar cobertura.
• ¿Qué dicen / implican otros programadores del equipo acerca de los otros programadores? Si es un gerente medio decente, está en las trincheras con su equipo de programación, especialmente durante las pruebas de integración y el tiempo de solución de errores. Entonces, si no recibe este tipo de comentarios, alguien más debería estar haciendo su trabajo.
• Y mi favorito: lo que yo llamo el programador 'tomcat'. Si, después de un rato, se da cuenta constantemente de que varios programadores siempre se arremolinan alrededor del mismo escritorio del programador (asumiendo que están haciendo un trabajo y discutiendo algún problema problemático, y no el buscador residente de sitios web divertidos y divertidos) ... entonces hay una razón para otro Los programadores están gravitando hacia el escritorio de esa persona. Si aún no son líderes de equipo, entonces probablemente deberían estar preparados lo antes posible.

Si cualquiera o todos estos se aplican, es probable que tenga un buen programador en sus manos. Tenga en cuenta que, como buen programador, no solo califico su capacidad de codificación, sino otras cosas útiles como poder comunicarme con otros seres humanos ;-)

Es posible que el administrador no sepa cuándo el código que escribes es brillante o si se podría mejorar por un factor enorme, pero lo que sí sabe es: ¿Cumpliste el plazo con el código que funcionó? ¿Es usted una persona en la que puede confiar para solucionar los problemas que otras personas crean? ¿Notó el cliente o usuario un problema que se escaló a su gerente? ¿Hubo un desastre importante en su vigilancia (eliminó la tabla de usuarios, olvidó configurar las copias de seguridad, envió un correo electrónico a los clientes con datos de propiedad de otro cliente que no deberían haber visto, etc.) ¿Alguien le felicitó por su trabajo (especialmente por escrito)? ¿La gente dice cosas buenas o malas a tus espaldas?

1. En la mayoría de los casos en los que su administrador no evalúa su código, sus colegas lo evalúan (ya sea de manera formal o informal cuando intentan trabajar con su código). Su jefe usará las opiniones de sus compañeros (de nuevo, ya sea formal o informal) hasta cierto punto.
2. Su confiabilidad general y la rapidez con la que avanza y termina las tareas suele ser un factor muy importante, aparte de su capacidad de codificación.
3. Comunicación. Si está haciendo mucho y lo está haciendo bien, ¡su gerente necesita saberlo! (Evita presumir, por supuesto). Aprenda a "administrar a su gerente" y no simplemente ser pasivo. Ayuda a tu jefe a saber cómo trabajas.

Los administradores son codificadores en sí mismos y, por lo tanto, pueden, mediante una simple observación, averiguar si el codificador es bueno o no.

Si sus administradores no son programadores (y usted está en el negocio del software), está jodido.

Como administrador, estas son algunas de las cosas que observé al evaluar a mis programadores:

• Retroalimentación entre pares. Le pedí a los programadores de mi equipo y a los programadores de otros equipos que me enviaran comentarios sobre mi gente.

• Respeto de los compañeros . Cuando mis programadores se topan con un problema que no pueden resolver, dicen "vamos a pedir tal y cual consejo".

• Hace las cosas . Digo "Quiero X" y al día siguiente, X se hace.

• Hace las cosas inteligentes . Digo "quiero X" y al día siguiente, no solo X está terminada, sino que todas las cosas similares a X están resueltas y no necesitan más atención.

• Me arregla . Digo "quiero X" y el programador dice "X no está bien, deberíamos hacer S, y he aquí por qué".

No hay muchos buenos administradores por ahí (vea la pregunta relacionada: ¿cómo saben los programadores si una persona es buena o mala gerente?). Manejar bien a las personas es difícil, y requiere mucho tiempo y trabajo. Tan pronto como dirigía a 5 personas, casi no tenía tiempo para la programación. Cuando estaba administrando a más de 8 personas, ya no podía administrarlas tan bien como se merecían.

Creo que la premisa de tu pregunta es algo defectuosa, ya que afirma que los gerentes no miran el código. He trabajado en muchas situaciones en las que mis gerentes eran colegas ingenieros y participé activamente en las revisiones de códigos.

Sin embargo, definitivamente hay una pluralidad de situaciones en las que una persona no técnica está a cargo de los ingenieros de software, y no pueden confiar en su propio conocimiento y experiencia.

En estos casos, los gerentes responsables llamarán a los compañeros del ingeniero para pedirles consejo. Preguntarán a las personas no técnicas de la organización con las que el ingeniero interactúa para ver si tiene buenas habilidades con las personas que sean compatibles con una mayor responsabilidad.

Los irresponsables solo irán con sus reacciones "instintivas" si usamos algún tipo de "métricas" generalmente insostenibles.

Es un juego de dados, pero siempre puedes renunciar y esperar algo mejor en otro lugar.

Donde trabajo, cuando se realizan las evaluaciones de los empleados, los gerentes envían un interrogador informal y anónimo a quienes interactúan regularmente con el empleado; Tanto compañeros desarrolladores como clientes. Esto les brinda a los otros desarrolladores la oportunidad de aportar información sobre el desempeño como un programador que los gerentes pueden pasar por alto.

El gerente tiene que mirar los medibles. Qué aspectos del trabajo son medibles en términos de trabajo realizado, calidad del trabajo. Es posible que no sepan si está haciendo un trabajo de calidad, a menos que genere muchos errores o no permita que el usuario final haga lo que se supone que debe hacer.

Su trabajo le cuesta al administrador dinero en gastos, por lo tanto, tiene que ser financieramente rentable para continuar con el empleo.

No estoy diciendo que esta sea la mejor manera de hacerlo, pero podrían basarse en la satisfacción del cliente. Si les gusta la aplicación, aceptan la cantidad de errores y sienten que agrega nuevas funciones de manera oportuna, ¿podrían sus desarrolladores realmente ser tan malos?

Por supuesto que podrían. Pueden hacer fuerza bruta a través de la codificación porque tienes a 10 personas haciendo el trabajo de dos. O los clientes están satisfechos porque vendes tu aplicación a un precio muy bajo.

Otro problema con este enfoque, es que tiene que esperar hasta que una aplicación esté casi completa antes de que el gerente no técnico pueda recibir comentarios de los clientes. Crea una aplicación por un año solo para lanzarla y a nadie le gusta.

La vida sería más sencilla si pudieras confiar en decirle a la gente que "Simplemente haga que funcione". Cuando comprendes y haces que las personas se adhieran al proceso correcto, eliminas muchos problemas. Puede tener plazos exigentes que sean realistas. Cualquier tonto puede generar demandas poco realistas y correr el riesgo de perder personas con talento.

Creo que la mayoría de nosotros en un equipo técnico sabemos quién mola y quién apesta. A menos que tenga una rotación tremenda, la crema sube a la cima y el peso muerto se hunde. Los desarrolladores maliciosos siempre están en algún tipo de problema: se olvidan de probar su código antes de verificarlo, por lo que las compilaciones se rompen, siempre tienen una excusa cuando no hacen algo, y así sucesivamente.

Creo que no saben si alguien es un buen programador , pero no tienen las habilidades para hacerlo. Comprueban si alguien es un buen desarrollador . La programación es una actividad de desarrollo, pero el desarrollo tiene muchos otros. Así que verifican si está a tiempo, si sus estimaciones son buenas, si hay muchos defectos en las cosas que ha hecho en su sistema de seguimiento de errores, sus habilidades, compromiso, comunicación, etc.

Lo que algunos gurús de It a veces olvidan y se enojan es que nuestro trabajo no es solo programación, sino que también tenemos muchas otras cosas que hacer que son muy importantes. Si bien su gerente no verá cómo se ve su código (porque no le importa en absoluto), verificará si usted es un jugador de equipo, responsable, respetuoso y hace un trabajo de alta calidad en general .

A veces pienso que el código está sobrevalorado.

Creo que hay muy pocas personas (y mucho menos gerentes) que no tienen una buena comprensión general del orden jerárquico para los desarrolladores. Todos piensan que son desarrolladores de primer nivel, las únicas personas que no saben quiénes son los malos desarrolladores, son esos malos desarrolladores. De todos modos, si fuera a buscar a alguien para clasificar a los desarrolladores con los que trabajan, estoy seguro de que sería una tarea fácil para la mayoría de las personas. Así que no hay magia para determinar quién se está desempeñando muy bien y quién está promediando o mal, etc ... El único problema en el que los desarrolladores y gerentes no estarán de acuerdo con los tipos de vendedores, los que suenan como si supieran lo que están hablando. sobre pero realmente no lo hacen. La mayoría de los gerentes son engañados por ellos, pero los desarrolladores no. Por lo general, el vendedor necesita una falla épica antes de que el gerente se entere.

Después de eso, son los sesgos de su administrador los que determinan su clasificación. Para algunos, la codificación es una tarea de nivel de entrada, por lo que si bien puede ser excelente en la codificación, no obtendrá la promoción que está buscando. Mientras que otros consideran que el diseño o los aspectos arquitectónicos son los más importantes. Y otros creen que la definición y recopilación de requisitos (es decir, análisis de negocios) es lo más importante. Si quieres saber qué es importante para tu gerente y no obtuviste una clasificación de alto desempeño, pregúntales qué debo hacer para obtener una clasificación de alto desempeño. Aprenderá lo que es importante también para ellos en esa respuesta y luego depende de usted asegurarse de sobresalir en esas áreas de importancia.