¿Cuántas horas productivas (codificación) por día puede esperar obtener, en promedio, de un ingeniero de software? Paso bastante tiempo investigando, diseñando y refactorizando, en lugar de simplemente “crear código”.

Depende de cómo se defina la codificación.

Para un equipo bien motivado, 6.5 horas por día serían razonables, lo que incluye “investigar, diseñar, refactorizar” y actividades relacionadas.

El tiempo dedicado a escribir código no tiene sentido ni es imposible de medir. ¿Cuenta las pausas entre líneas cuando piensa durante más de 5 segundos? ¿Cuenta el tiempo que lleva construir el proyecto mientras lo ejecuta? ¿Qué pasa con los 30 segundos gastados para encontrar en qué clase era el método sangriento que necesitaba editar?
Además, varía ampliamente con las fases del proyecto, las fases de sprint, el estado de ánimo, el número de reuniones durante el día y una serie de otros factores: un día puede pasar buenas 10 horas con las manos en el teclado, el otro puede pasar sin escribir un linea sola.

Una medida popular que ha estado circulando desde los años 90 es que para proyectos grandes el promedio es de aproximadamente 20 líneas por desarrollador por día . Creo que esto todavía está dentro del estadio. La verdad es que los desarrolladores pasan más tiempo mirando el código en lugar de escribirlo , lo que tiene ciertas implicaciones importantes en la industria, y la principal es que vale la pena escribir un código bueno (es decir, mantenible).

Cada vez que se interrumpe su programador, ha perdido unos 15 minutos de tiempo de codificación. ¿Por qué? Lleva tanto tiempo volver a la zona donde un programador está realmente codificando productivamente. Cada vez que ocurre una interrupción, debe eliminar mentalmente toda la información del programa de su cabeza y lidiar con la interrupción.

¿Cuántas veces se interrumpe tu programador por día? Estos pueden incluir:

• reuniones (sí, todas las reuniones)
• Hora de prepararse para dicha reunión
• revisiones de diseño
• revisiones de código
• revisando y respondiendo al correo electrónico
• ruido de la oficina (cuanto más silencioso, mejor, los auriculares ayudan pero no se arreglan)
• documentación
• prueba manual
• proceso de liberación
• programas de chat
• Número de proyectos en los que están trabajando (idealmente 1, con una pérdida horrible en 2+)

Cada vez que su programador cambia en lo que está trabajando, incluso durante una conversación de cinco segundos, la saca de la zona. Tarda unos 15 minutos en volver a lo que estaba trabajando. Para un día típico de 8 horas, aquí hay una ecuación que puede usar:

8 horas – ((número de interrupciones) * 0.25) – (tiempo total de todas las interrupciones) = Tiempo de codificación del programador (estimado)

Usando la ecuación anterior, puedo mostrar que cuatro preguntas rápidas de 2 minutos se quemarán durante una hora de tiempo de codificación ese día. Lo mismo es cierto para dos reuniones de 15 minutos. Cada una de estas acciones no parece mucho, pero se suman muy rápidamente.

Como empresa, debemos sacrificar la productividad máxima de codificación para trabajar con otros elementos empresariales. Esto es especialmente cierto para las pequeñas empresas. Tenemos que lanzar nuestro software. Tenemos que reunirnos con nuestro equipo para realizar revisiones de diseño. Hacemos revisiones de código para que el conocimiento se transfiera y los errores se detecten temprano. Estos son sacrificios necesarios del tiempo de programación para mantener un negocio en funcionamiento.

Teniendo esto en cuenta, la lista anterior (especialmente las reuniones) debe reducirse al mínimo absoluto posible en cualquier negocio. Las reuniones suelen ser lo peor de lo peor. La mayoría es una completa pérdida de tiempo del programador. También puede ser un mal negocio, ya que cada programador costará aproximadamente cuatro veces su salario por hora para sentarse allí escuchando en esa reunión *. Eso es alrededor de $ 200- $ 300 por hora por programador. Contando el tiempo de preparación, esto podría ser miles de dólares en pérdida de productividad. ¿Esa reunión es realmente obligatoria?

Estas son solo un par de sugerencias que rascan la superficie de la productividad del programador. Recomiendo encarecidamente el libro Peopleware para obtener más ideas y estrategias para aumentar la productividad en su empresa.

* Salario + beneficios + pérdida de tiempo de programación.

Es bastante difícil de entender, incluso si solía ser un desarrollador y ahora posee una casa de software como yo.

Tal como dijiste, la programación no se trata solo de codificación. Cada proyecto es diferente y debe juzgarse de manera diferente.

En las primeras etapas de la construcción de un nuevo sistema, la codificación generalmente lleva menos de la mitad del tiempo porque es el momento de cumplir con los clientes, reunir requisitos, analizar sus procesos, investigar soluciones, herramientas y crear cronogramas y plazos.

Luego, cuando estamos en un modo de construcción real, la mayor parte del tiempo se dedica a la codificación. Yo diría que alrededor del 90%

Luego, cuando nos estamos acercando al final del proyecto, el tiempo se divide de manera equitativa entre la codificación, que incluye, pruebas finales, corrección de errores, adición de los últimos cambios como nuevas características y documentación, capacitación de los usuarios y finalmente mantenimiento del código y apoyando a un cliente en cualquier necesidad.