El peor programador que conozco
(dannorth.net)- Un equipo de consultoría en un Big Bank intentó medir la productividad individual por historias completadas/puntos de historia, y Tim Mackinnon obtenía repetidamente 0 en esa métrica
- La razón por la que su puntaje era 0 no era que no trabajara, sino que no tomaba historias a su nombre y pasaba la mayor parte del día haciendo programación en pareja
- Con desarrolladores menos experimentados, en lugar de darles directamente la respuesta, fomentaba el aprendizaje con preguntas socráticas; con seniors, encontraba junto con ellos mejores soluciones a partir de perspectivas distintas
- El equipo trabajaba de forma más efectiva, productiva y alineada cuando Tim colaboraba con ellos, y al final el gerente descartó en silencio la métrica de productividad individual mientras mantenía a Tim en el equipo
- Medir la contribución individual por separado puede convertir en 0 aportes como los de Tim, así que la productividad debe verse desde el impacto de negocio y el flujo a nivel de equipo
El “programador de 0 puntos” creado por las métricas individuales
- Un equipo de Big Bank introdujo métricas de desempeño individuales para la evaluación del rendimiento y el desarrollo profesional
- El gerente evitó métricas fáciles de manipular, como líneas de código o número de bugs, y eligió medir historias completadas o puntos de historia porque, según él, representaban valor de negocio
- Como en una herramienta similar a Jira cada persona aparecía asignada a una historia, era fácil crear una métrica de productividad por individuo
- La puntuación de Tim Mackinnon no era solo baja: cada semana y en cada iteración era literalmente 0
- El gerente pensaba que había que sacar a Tim del equipo y reemplazarlo por alguien que realmente “entregara” historias, pero el líder del equipo se negó
Lo que Tim realmente entregaba
- Tim no tomaba historias a su nombre; en cambio, trabajaba haciendo pairing con distintos miembros del equipo todos los días
- Cuando trabajaba con desarrolladores menos experimentados, los dejaba conducir y los guiaba suavemente hacia la solución
- No imponía ni empujaba una respuesta
- Creaba momentos de aprendizaje con preguntas como “what if”, “how else” y preguntas socráticas
- Con desarrolladores senior, trabajaba de una manera más cercana a la cocreación o al sparring, aplicando distintas visiones del mundo al problema para llegar a resultados difíciles de imaginar en solitario
- Más que entregar software directamente, Tim hacía crecer al equipo que entrega software
- Todo el equipo se movía de forma más efectiva y productiva
- Trabajaban con mejor alineación y de una manera más tolerante
- La experiencia de trabajar juntos también se volvía más agradable
- Cuando el gerente iba a observar al equipo, Tim siempre estaba con otra persona haciendo “el trabajo de esa persona”, pero el resultado tenía mejor calidad y el tiempo para entregar valor era menor
- Al final, el equipo decidió quedarse con Tim y optar por la responsabilidad del equipo en lugar de métricas de productividad individual
- Hacían seguimiento y celebraban el impacto de negocio que entregaban a la organización como una unidad de alto desempeño
¿Dónde hay que mirar la productividad?
- Medir la productividad sí es necesario, y para tener accountability lo ideal es contar con impacto de negocio medible
- Dinero ahorrado
- Dinero generado
- Dinero protegido
- Si es difícil medir el impacto directo en el negocio, también se pueden usar métricas proxy de negocio
- En sistemas adaptativos complejos, ya se tambalea la premisa de que se pueda aislar y medir por separado la contribución de una sola persona
- Las métricas DORA no miden el aporte de un pistón individual, sino cómo funciona el sistema de trabajo
- Pueden verse como métricas de cultura de Westrum
- También pueden verse como métricas de cómo los cambios técnicos fluyen hacia producción
- Las métricas individuales pueden convertir en 0 la contribución real de personas como Tim, y es más apropiado observar el desempeño a nivel de equipo y el flujo a nivel de sistema
1 comentarios
Opiniones de Hacker News
Hace unos 20 años trabajé en una empresa de software mediana que vendía apps de escritorio para Mac y Windows, pero el equipo tenía en su mayoría experiencia solo en Mac y apenas estaba aprendiendo Windows, así que la versión para Windows tenía muchos problemas.
En ese entonces yo era conocido como experto en Windows, así que me contrataron para mejorar esa versión y ayudar al equipo a familiarizarse con la programación en Windows.
La primera parte del día solía ser como “visitas a domicilio”: iba por las oficinas de otros desarrolladores para hacer pair programming, investigar bugs y hablar de buenas prácticas de la API de Windows; más tarde, un colega me preguntó “cómo podía disponer de tanto tiempo”.
Unos meses después, en la evaluación, recibí el comentario de que “mi productividad no estaba a la altura de lo esperado, especialmente considerando que la productividad del resto del equipo había subido últimamente”, y yo pensaba que justamente para eso me habían contratado.
Compartir conocimiento es el mayor beneficio que le puedes dar a otros desarrolladores, pero quienes eligen ese camino reciben muy poca recompensa.
Sin desarrolladores así, no estaríamos ni cerca del mundo del software que tenemos hoy, y aunque no reciban agradecimiento directo, sin duda tienen valor.
Todas las reparaciones tenían la misma prioridad, pero distinta dificultad; como hacía falta un mes para aprenderlo y nadie quería hacerlo, me encargué de la reparación de estaciones base, lo que tomaba más tiempo, pero era mucho más importante para la operación.
En la reunión de fin de mes mostraron un gráfico de pastel de utilización, y yo quedé viéndome mucho peor que los seniors experimentados.
Ahí aprendí por qué los seniors elegían solo las tareas rápidas y fáciles, y que la política interna existía; en realidad fue una suerte haber tenido un jefe pésimo al inicio de mi carrera.
Mi nuevo jefe admitió que en la primera evaluación originalmente había preparado un plan de mejora de desempeño, pero lo descartó después de que nos mudamos a una oficina abierta y vio a la gente haciendo fila para pedirme ayuda y que yo no rechazaba a nadie.
Perder mi lugar con cubículo fue algo molesto, pero gracias a eso empecé a ver las oficinas abiertas de forma positiva.
Claro que ahora ya no trabajo en ninguna oficina, y no pienso volver a aceptar un trabajo que no sea remoto.
Solo después de construirse una reputación se puede cambiar algo; antes de eso, es difícil.
Demasiada gente optimiza para el “equipo” y termina despedida o relegada en ascensos por una percepción negativa de la dirección; en cambio, a quienes se ganan buena reputación según los criterios que la empresa valora en ese momento se les suele tolerar durante bastante tiempo incluso mal comportamiento.
Si se fue de inmediato a un lugar mejor, si empezó a repartir menos su tiempo para ajustarse a las métricas de desempeño de la empresa, o si logró convencer a alguien lo bastante alto en el organigrama de que en realidad lo habían contratado para ese rol.
Me recuerda a una anécdota de Bell Labs.
Alguien calculó quiénes eran los empleados más productivos usando criterios como la cantidad de patentes, y descubrió que muchos de ellos almorzaban con la misma persona.
Esa persona no tenía una productividad individual alta, pero siempre hacía preguntas profundas y persuasivas que volvían a sus colegas, de forma medible, más productivos.
Los abogados del departamento de patentes de Bell Labs intentaban encontrar un principio organizacional que explicara por qué algunas personas eran más productivas, y el único rasgo común era que los empleados con muchas patentes solían almorzar o desayunar con frecuencia con el ingeniero eléctrico Harry Nyquist.
Nyquist no les daba ideas concretas; hacía que la gente se abriera y pensara, y sobre todo hacía buenas preguntas.
Los grupos de personas son estructuras delicadas, así que un buen ambiente de equipo y buenas preguntas pueden mejorar las cosas de manera invisible.
Si no, es difícil que reciba un sueldo justo.
Yo creo que no.
En una empresa donde trabajé durante varios años, si no generabas 10 puntos por semana quedabas sujeto a un plan de mejora de desempeño, sin importar si eras junior o senior.
Pasé por varios equipos, y bastaba con ver el nivel de estrés de los desarrolladores para saber de inmediato cómo medía los puntos cada equipo.
Los equipos que intentaban medir los puntos de buena fe estaban estresados, la mayoría mostraba señales de burnout y trabajaba 60 horas por semana.
En cambio, los equipos que trataban el sistema como un juego y entendían que era una tarea imposible le ponían a los tickets la mayor cantidad de puntos posible, o los dividían en tickets pequeños para seguir acumulando puntos, y estaban felices y sin estrés.
En ese entorno, jugar según las reglas era una estrategia de ingenuo, y cuando finalmente renuncié, los 7 ingenieros senior de la empresa se fueron detrás de mí en menos de 4 meses.
El objetivo es dividir historias con mucha incertidumbre y riesgo en historias que puedan lograrse de forma constante y sin estrés.
No digo que ese lugar de trabajo se vea bien, pero los desarrolladores que sintieron que estaban jugando con el sistema en general parecen haber actuado de la forma que Scrum intenta fomentar.
Eso sí: imponer un mínimo de puntos por semana e incentivar la inflación de puntos es una gestión terrible.
Porque logró sacarle más trabajo a la misma gente que si no hubiera ejercido presión.
Un antiguo jefe decía abiertamente que para terminar proyectos “contrataba gente y la quemaba”, y planeaba que con que trabajaran de forma útil durante 6 meses alcanzaba.
Si soportaban el estrés y la baja compensación y se quedaban, para la empresa era como un extra; yo tampoco aguanté mucho.
Si no terminabas todo esa semana, cerrabas el ticket como completado y abrías el trabajo restante como un bug nuevo.
“Cuando una medida se convierte en objetivo, deja de ser una buena medida”.
En algunos lugares era más importante saber qué podía esperar un gerente que la productividad pura orientada al objetivo.
Quienes estimaron de buena fe quizá pensaban que la gerencia también actuaba de buena fe, pero muchos proyectos se construyen sobre deseos, o con fechas límite artificialmente cortas para “motivar” a la gente.
Ese estrés tal vez no generaba mucho valor más allá de la satisfacción emocional del gerente.
Cuando personas no técnicas evalúan el desempeño de un ingeniero de software, los resultados pueden ser dramáticos.
Mi amigo “Tommy” era un encargado de IT con excelentes habilidades en redes, y pocas semanas después de entrar a una empresa de energía estatal tuvo que reconstruir por completo la red con equipos modernos, incluyendo todos los edificios de la sede central.
La empresa quería contratar a un proveedor externo, pero cuando Tommy vio el costo estimado por el departamento de finanzas se sorprendió y dijo que podía hacerlo él mismo con solo el hardware físico —routers, switches, cables— y 2 personas encargadas del cableado.
Terminó el trabajo en pocas semanas por menos de una décima parte del presupuesto inicial, pero lo único que recibió fue un “gracias, buen trabajo” verbal de su jefe.
Qué amargo es ser un técnico de IT en una época en la que los jefes son anticuados y no entienden el valor real.
Después Tommy podría haber entrado como contratista y recibir una compensación adicional.
Un desarrollador realmente brillante con el que trabajé escribía tanto código excelente como código espantoso que había que reemplazar de inmediato, y ambas cosas lo hacían genial para trabajar con él.
No hace falta explicar el valor del buen código, y es posible que todavía esté usando código suyo.
Pero también era excepcional en situaciones de emergencia.
Cuando un cliente quedaba completamente detenido y podía ser culpa nuestra, aparecía de inmediato, entendía rápido el problema y escribía e instalaba con rapidez un código spaghetti y sucio que hacía que el cliente volviera a funcionar.
Era un código doloroso de ver, que no se podía commitear ni refactorizar, pero evitaba la crisis inmediata mientras alguien lo arreglaba bien más adelante.
Yo admiraba aún más esta segunda habilidad, porque ante todo era una destreza rara, y además él era simplemente una buena persona, así que todos lo querían.
Aun así termino el trabajo rápido, y mi código raro ha salvado el día varias veces al resolver emergencias o ganar licitaciones.
Me cuesta comunicarme con los desarrolladores “perfeccionistas”, y para ellos, si el código no está suficientemente diseñado, aunque entiendan que hace falta velocidad, parece no tener valor.
Por supuesto, ellos probablemente piensen lo mismo de mí, pero al revés.
Ahora hacemos reuniones semanales para mitigar el problema, y funciona bastante bien.
Lo más difícil es decidir qué tipo de enfoque corresponde cuando no es una emergencia, pero el cronograma es ajustado y las especificaciones son poco claras; al menos ahora lo decidimos en conjunto.
No es imposible aprenderlo por cuenta propia, pero a mí me resulta realmente doloroso ese método de memorizar problemas y soluciones comunes hasta el punto de poder tipearlo todo de forma mecánica.
A menos que seas dueño de la empresa, siempre te evaluarán por el valor aparente.
Si tu empleador no puede ver visualmente tu valor, es poco probable que puedas permanecer allí.
Un sistema de desempeño completamente meritocrático sería ideal, pero si otra persona tiene en sus manos tu contratación o evaluación, tu éxito depende 100% de cómo esa persona te perciba.
Esa percepción surge de lo que se ve por fuera, tenga o no valor real para la empresa.
De lo que hablo aquí no es de habilidad de programación ni de valor real, sino de empleo y evaluación; también hay muchas personas muy productivas que saben gestionar bien su reputación.
Personalmente, quiero que los seniors del equipo realmente saquen adelante las tareas difíciles.
Está bien ayudar a que los juniors trabajen, pero las tareas difíciles y complejas que un junior, por falta de conocimientos, experiencia y habilidades interpersonales, no puede hacer siguen necesitando a alguien con oficio.
Ninguna programación en pareja puede reemplazar eso por completo.
Hay que evitar una situación en la que las funcionalidades de bajo valor estén muy bien implementadas, pero el trabajo de alto impacto y alta prioridad no se termine porque las personas con más experiencia están ayudando a las menos experimentadas con cosas como aprender a escribir pruebas unitarias.
Que lo tenga asignado un junior no significa por defecto que sea un problema fácil; si no, ¿cómo se supone que harías crecer a los ingenieros?
No todos los seniors deberían dedicar su tiempo a mentoría y colaboración con juniors, pero si en el equipo hay algunas personas así, actúan como multiplicadores de fuerza y benefician a todo el equipo.
Aunque no lo supieran al momento de contratarlo, si él encontró un nicho útil, la empresa debería haberlo convertido en un rol formal.
Era un coach, y eso estaría bien si lo hubieran contratado para ese rol, pero probablemente, si querían un coach, lo habrían contratado aparte.
Hay funcionalidades difíciles que un junior no puede terminar aunque le des tiempo infinito, porque todavía no tiene las habilidades, y esas habilidades tardan años en desarrollarse.
A veces se necesita ayuda de un senior, pero si por eso el senior no puede construir nada, desde el punto de vista de la empresa el sentido es débil.
Las funcionalidades difíciles deberían dárselas a alguien lo suficientemente senior y, si quieres formar a un junior, compartir con él las partes más fáciles de ese trabajo y hacer que el senior explique lo que está haciendo.
La actitud de Tim de ayudar a todos es excelente, pero también es extraño que los demás programadores necesiten tanta ayuda que Tim no tenga nada de tiempo para producir sus propios resultados.
El problema no es Tim, sino una gestión que consideró aceptable una estructura en la que los profesionales siempre necesitan ayuda y un Tim casi voluntario está disponible para ayudar en cualquier momento.
Si uno de los seniors la hubiera construido bien desde el principio, un junior también debería haber podido modificarla.
Si ese senior la construyó y aun así la estructura la vuelve difícil y compleja, cabe preguntarse por qué lo llaman senior.
Aun así, el trabajo de todos los seniors no puede reducirse solo a ayudar a los juniors.
Hoy en día es difícil convertirse en alguien así.
Todo gira alrededor de resultados visibles, así que personas así suelen ser candidatas a recortes, y lo viví en carne propia.
Los team players, mentores y arquitectos de software quedan cada vez más desplazados, y su lugar lo ocupan coders que producen grandes cantidades de código.
Aunque la deuda técnica haga que la capacidad de entregar funcionalidades y mantener el sistema empeore con el tiempo, a los managers les gustan los desarrolladores que escriben de forma constante más de 5000 líneas por semana, sin importar la cantidad real de funcionalidades lanzadas o bugs.
Como team lead e ingeniero que ha gestionado proyectos complejos, alguien que escribe más de 2000 líneas de código por semana me da miedo.
Son más de 100 000 líneas de código al año, y hay que pensar en la complejidad innecesaria.
Es muy probable que la misma funcionalidad pueda implementarse en 10 000 líneas, con menos bugs y en la mitad del tiempo, pero entonces serían apenas 380 líneas por semana y al manager no le gustaría.
Suelo pensar que un desarrollador que saca miles de líneas no está reflexionando con suficiente profundidad sobre la dirección de largo plazo del proyecto, y siento que la mayor parte de ese código está cerca de ser código desechable.
Google, en cierta medida, institucionalizó esto con el rol de Tech Lead, y se espera que ese ingeniero actúe más como multiplicador de fuerza y mentor que como colaborador individual.
No siempre funciona según el diseño, quizá solo rara vez, y puede que el TL termine atrapado en coordinación de personas, planificación y discusiones menores, sin poder trabajar como ingeniero.
Aun así, la intención del rol es buena.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
La idea de medirlo todo y actuar según los números que se pueden obtener existe desde el siglo XIX.
Los managers han repetido las mismas prácticas desde entonces, y los resultados también han salido de forma bastante estable en la misma línea.
El dueño de una empresa donde trabajé por poco tiempo quería reescribir el servicio web desde cero cada seis meses para seguir los frameworks web más nuevos y las modas.
Habría contratado en el acto a un héroe de 5000 líneas por semana.
En proyectos de mantenimiento, a veces pasaba una semana sin escribir una sola línea por mi cuenta, y otras veces incluso dedicaba toda la semana a reducir la cantidad de líneas de código.
Excelente.
En remo existe un entrenamiento llamado seat racing, en el que se meten y sacan personas en distintas combinaciones de los ocho asientos para encontrar la combinación más rápida.
La fuerza individual también es un indicador, pero quién se sube al bote de competencia lo determina la velocidad del equipo.
Al final, es raro que la combinación más rápida incluya simplemente a los ocho más fuertes, y a menudo hay una o dos personas “mágicas” que, aunque en el papel no parezcan mejores, hacen más rápido a cualquier bote en el que las pongas.
Mejoran sutilmente el equilibrio, el ritmo y la potencia de los demás.
Algunos entrenadores no están dispuestos a aceptar esto y se resisten, y como resultado ganan menos.
Es muy parecido a los equipos de software y, al final, lo importante son la combinación y los resultados.
Cuando me piden coaching sobre “liderazgo técnico”, siempre digo que hay que prestar mucha atención a los empleados facilitadores.
Su ayuda hace que otros empleados sean más productivos y efectivos, y algunas personas obtienen más satisfacción laboral ayudando a que otros hagan un gran trabajo que haciendo cosas sorprendentes por cuenta propia y llevándose todo el crédito.
Este tipo de personas a menudo obtiene puntajes bajos, pero si se van, la productividad del equipo disminuye en términos netos.
Por eso intento dar herramientas para distinguir entre alguien que en realidad no es productivo y alguien cuya productividad se manifiesta en el éxito de los demás.
Nunca es buena idea medir una sola métrica y gestionar en función de ella.
Porque quienes manipulan la métrica “ganan”, y ese comportamiento termina llevando a ascensos.
También se lo dije al liderazgo de Google, pero Laszlo dijo: “Este es el sistema que tenemos, no es perfecto, pero vamos a seguir con él. Queda en tus manos decidir si trabajas dentro de él o no”.
Esa sola reunión bastó para saber si la alta dirección realmente quería crear un mejor entorno de ingeniería o no.
Muchos gerentes nuevos, especialmente quienes antes fueron ingenieros colaboradores individuales, creen que si conservan a los “mejores” integrantes y dejan ir a los “malos”, mejorarán tanto la moral como la producción del equipo.
Pero su idea de “mejor” se basa en el criterio con el que antes hacían bien su propio trabajo, no en el criterio para gestionar personas.
Por eso tienden a favorecer a quienes tienen habilidades y hábitos parecidos a los suyos, y a valorar menos a quienes tienen habilidades y hábitos distintos.
Siempre es interesante ver el momento en que se les abren los ojos al darse cuenta de esto.
La política de tasa de interés cero hizo proliferar roles como el de directores sénior que gestionan tableros de Jira y listas de tareas, y dejó escasez de personas capaces de hacer el trabajo real.
No me opongo a la idea de que pueda haber personas que faciliten la productividad de otros, pero al final, para que algo se termine, se necesitan esos “otros”.
De lo contrario, la organización se necrosa.