Qué hace productivo a un desarrollador

• Muchos factores influyen en la productividad de los desarrolladores
• Algunos son claros y fáciles de medir, pero otros son difíciles de medir y tienden a pasarse por alto

Saber qué construir (Knowing what to build)

• Construir rápido algo equivocado no es nada productivo
  • hay que saber qué quiere el cliente,
  • saber qué es aceptable para otros equipos (¿cuántos índices pueden ponerse en una tabla de base de datos?, ¿se puede compartir información que legalmente no está permitida?),
  • y saber qué se intentó antes pero no funcionó

Hacer menos trabajo

• Terminar el trabajo rápido está bien, pero es aún mejor que directamente no haya que hacerlo
• Los procesos de la empresa pueden agregar “trabajo ocupado” que reduce la productividad
  • a veces hay formas de ajustar fácilmente el proceso para entregar el mismo valor con mucho menos trabajo
• Puede ser necesario cierto nivel de esfuerzo para “mantener las luces encendidas (Keep the lights on, KTLO)”
• Esto incluye tareas que deben hacerse continuamente (por ejemplo, responder tickets de soporte), pero que no hacen avanzar un proyecto
• Estas tareas pueden verse productivas en varias métricas (cantidad de tickets resueltos, cantidad de commits fusionados), pero no llevan a la empresa a un lugar mejor

Herramientas con respuesta rápida

• Los desarrolladores usan herramientas constantemente: editor, git, sistema de builds
• El tiempo que agregan estas herramientas puede generar un costo bastante alto según la frecuencia con la que se usen
• No solo cuestan tiempo por hora, también rompen la concentración del desarrollador

El conocimiento en la cabeza del desarrollador

• Es difícil de medir
• Si todo lo demás es igual, un desarrollador con más conocimiento relevante es más productivo
  • porque sabe cómo funciona el código y no necesita revisarlo a fondo,
  • sabe cómo usar las herramientas y qué trampas evitar
  • hace las preguntas correctas
  • los desarrolladores 10x existen, y son “las personas que conocen bien el codebase”
• Esto significa que un equipo no debería ser dueño, en conjunto, de más cosas de las que puede mantener en su cabeza de forma colectiva. (Lo ideal es que el número de autobús sea mayor que 1: teoría del Bus Factor)
  • También significa que conviene minimizar la frecuencia con la que cambia la propiedad
  • Nadie sabe más sobre algo que la persona que lo construyó
  • Idealmente, quienes usan un sistema por primera vez deberían trabajar y aprender junto a personas que ya lo conocen
• Se necesitan límites claros entre sistemas
  • Una interfaz limpia con semántica simple permite pensar en las propiedades de la interfaz sin necesidad de conocer todo el sistema que hay detrás
• La documentación es una buena forma de transmitir conocimiento
  • Es especialmente importante cuando un desarrollador tiene que realizar una tarea específica con la que no está familiarizado
  • Si falta documentación, el desarrollador puede tener que investigar por su cuenta cómo hacer la tarea, cometer errores y rehacer el trabajo, o esperar a que otro equipo responda sus preguntas, lo que puede volver más lento el trabajo
  • Eso puede convertir rápidamente una tarea de 1 hora en una tarea de 2 días
  • Si 100 desarrolladores tienen que hacer esto, el costo de que falte una sola página de documentación puede equivaler al salario anual de un desarrollador
• También significa que debe haber más especialización (Specialization)
  • Exigir que todos los desarrolladores hagan una gama amplia de tareas es improductivo
  • Una hora invertida en el proceso de redactar ciertos sistemas de seguridad o planificación de capacidad no es lo mismo que una hora invertida en entender el dominio para resolver un problema

Infraestructura útil

• La infraestructura debe ayudar, no ser un obstáculo
• Debe estar razonablemente alineada con todo el trabajo que se necesita realizar
• Cada parte de la infraestructura se diseña pensando en ciertos casos de uso, pero en los proyectos a veces aparecen situaciones fuera de esos casos
  • En esos momentos es frustrante escuchar “solo tienen que usar nuestra infraestructura” o “nuestra infraestructura no puede hacer ese tipo de cosas”
  • Entonces hay que trabajar alrededor de la infraestructura o perder tiempo en reuniones para convencer a los responsables de la infraestructura sobre los requisitos

Poca deuda técnica

• El código existente nunca encaja perfectamente con el trabajo que quieres hacer
  • La persona que escribió el código original no tenía una “bola de cristal” para ver qué cambios ibas a hacer
  • Pero algunos códigos son mucho más fáciles de cambiar que otros
• La respuesta a “¿cómo podemos hacer X?” no debería ser “tenemos que rediseñar todo esto”
• Si hay mucha deuda técnica, incluso un pequeño cambio de funcionalidad puede requerir cambios mayores en el sistema
• Reducir la deuda técnica permite minimizar la superficie expuesta que hay que (a) entender y (b) modificar
• Los proyectos para pagar deuda técnica deben completarse
  • Si se abandonan a la mitad o se les baja la prioridad, el sistema puede quedar peor que al principio

Baja tasa de fallas

• Si fallan la ejecución de herramientas, los builds, los despliegues o hay regresiones por errores en producción, ese tiempo se desperdició
• Reducir la probabilidad de estas fallas mejora la productividad
• Además del ingeniero que experimentó la falla, también suele desperdiciarse el tiempo del equipo dueño del sistema que falló (porque tienen que analizar y corregir la falla juntos)

Las prácticas productivas son prácticas (Productive practices are practical)

• La mejor manera de aprender a resolver un problema específico es crear un prototipo
• Si el entorno dificulta el prototipado, incluso el enfoque más productivo puede verse bloqueado
• Si es difícil usar herramientas de monitoreo, los desarrolladores crearán menos dashboards, medirán menos cosas y las decisiones estarán menos basadas en datos
• Por el contrario, si un cambio grande se divide en code reviews más pequeños, es más fácil revisar y desplegar el código

Cuánto puede concentrarse un ingeniero

• Los ingenieros trabajan según un cronograma de entrega y necesitan poder concentrarse
• Esa concentración puede ser robada por reuniones e interrupciones
• Las interrupciones también incluyen comandos de CLI lentos, tests lentos y tareas que requieren investigación porque no se sabe cómo hacerlas
• Pensar en demasiadas cosas durante una misma semana también daña la capacidad de concentración
• Los deadlines que se acercan o las preguntas sin respuesta del manager ocupan RAM mental incluso cuando uno intenta concentrarse en otra cosa

Terminar el trabajo

• Construir el 50% no es 50% de productividad, es 0% de productividad
• No hay nada menos productivo que el trabajo que termina descartado
• A veces abandonar un proyecto a mitad de camino sí es la decisión correcta
  • A veces es correcto luchar contra la falacia del costo hundido
  • Pero no debería haber un patrón constante de cambiar prioridades antes de que el proyecto termine
  • En ese caso, la productividad del equipo puede caer a 0

Cierre

• No siempre se puede construir un dashboard para medir todos estos factores diversos, pero sí se puede entender cómo afectan la productividad cosas como las anteriores
• Resolver estos problemas puede aumentar enormemente la cantidad de trabajo que se logra hacer
• Algunos problemas pueden arreglarse con una facilidad sorprendente
  • Si se invierten unas horas en escribir documentación, la empresa puede ahorrar miles de horas
• Cuando necesites cortar un árbol rápido, empieza por afilar la sierra

[kofmania]

Sí, es un texto con muchas partes que cierran ideas.

[laeyoung]

"Si falta documentación, el desarrollo puede volverse más lento porque las personas desarrolladoras tienen que investigar por su cuenta cómo realizar el trabajo, cometer errores y rehacer tareas, o esperar a que otro equipo responda sus preguntas"

No es documentación de desarrollo, pero cuando les pedí a las personas que acababan de pasar por el onboarding que actualizaran los documentos de onboarding una semana después, la documentación mejoró. Al entrar a la empresa sin ninguna información, ellas son quienes mejor saben qué hace falta en ese momento.

También pienso que muchos Readme.md de proyectos open source en GitHub suelen estar relativamente bien escritos porque llegan muchas personas usuarias iniciales y dejan feedback.

[devsepnine]

Últimamente me están entrando demasiadas cosas y no doy abasto T_T

[ahwjdekf]

La infraestructura debería ser una ayuda, no un obstáculo --> pero actualmente, dentro de las empresas en Corea, con la seguridad como excusa, esto para nada aplica.

[hero512]

Entiendo el sentimiento, pero este artículo fue escrito en inglés. Parece que las empresas de habla inglesa también están en una situación similar.

[kuroneko]

Parece más una traducción que un resumen... Gracias por la recopilación tan detallada.