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).