Si un programador escribe sólo 30 o 50 líneas de código por día ¿qué hace el resto de la jornada laboral?

Hay una falacia en esta pregunta. Dado que no es preciso que un programador «escriba» sólo 30 o 50 líneas de código por día. Supongamos que sean 30.

Esto es como evaluar a un cientifico que descubre una fórmula por la cantidad de mililitros que manipula comparado con los litros que un albañil puede llevar en un balde.

source code lines by day
source code lines by day

Image by AlfredMuller from Pixabay
Las estadísticas indican que 30 líneas son las que llegan al producto final, o al entregable. En realidad a esto le deberíamos restar también el software entregado que termina no usándose.

Pero igualmente reviste otra falacia. El programador no escribe líneas de código como un operador que carga información o un asistente de un escritor que tipea lo que escucha de un audio. El programador debe pensar qué va a escribir, y cómo hacer que lo que escriba genere el resultado que le están pidiendo.

Hay todavía más, el desarrollo de software es una actividad incremental, no es como una casa o un puente donde es muy raro quitar el ladrillo que se puso para avanzar en la obra de construcción. Dado el costo bajo de hacer modificaciones (frente a otras actividades), es muy común aceptar que aquel que pide el trabajo, no sepa exactamente lo que quiere. Aún esos requerimientos y expectativas pueden cambiar a medida que va percibiendo y usando el progreso del proyecto.  Entonces hay mucho que cambiar en el propio proceso de entregas y hasta terminar. Esto se traduce en muchas líneas de código que no llegan al producto final.

 

En muchos casos, el programador también tiene que comprobar que lo que hizo funcione. Por lo que también pasa gran parte del tiempo probando lo que hizo, al menos en forma individual dado que muchas veces hay equipos separados de testing. Pero aún en entornos donde hay equipos de testing el programador no se pone a zapatear arriba del teclado y producir cualquier resultado a la espera que el equipo de testing le reporte los errores para despues arreglarlo. Un programador que en ese reporte genere errores mayores a los del promedio tendrá una mala reputación, por lo que le importará probar su trabajo antes de entregarlo aunque exista un equipo de testing.

Entonces el programador pasa gran tiempo poniéndose el gorro de usuario final, y el gorro de tester y pasa gran tiempo comprobando que lo que hizo era similar a lo que le pidieron.

Pero hay aún más. En la cadena alimentaria del desarrollo de software el programador es como «los vegetales» . Es aquella fuende de alimento primaria de la cual todos los demas roles se nutren.

Por otra parte tiene que gastar mucho tiempo en explicarle a los que piden imposibles que algo no se puede hacer en los tiempos que esperan.  En otros entornos tienen que estar averiguando las claves de los clientes para acceder a los recursos. En otros casos armar otros entornos para trabajar sin pisarse con la actividad de otros, por ejemplo cuando utilizan una base de datos en comun. Tambien tienen que conseguir los recursos, como notebooks, dos monitores, permisos, accesos de red que a veces los de IT no tienen listo, o no sabían que había que preparar. En muchas oportunidades tienen que ayudar a los recruiters a preparar tests técnicos para los nuevos, o hasta participar de las entrevistas.

También es habitual que tengan que coachear a nuevos desarrolladores, que la empresa contrató como junior pero los venden como senior, entonces hay otros desarrolladores que salvan ese gap a costa de su propia performance.

Y muchas veces tienen que escuchar la arenga infructuosa de sus líderes pidiendo que logren imposibles, mientras miran su reloj ( o teléfono movil) para ver cuanto falta para empezar a trabajar.

En otros casos tienen que hacer reportes de status indicando porcentajes de progreso del trabajo que realizaron, o ir a las reuniones iniciales cuando un cliente pide un proyecto. En muchos casos hacen estimaciones con los pobres datos que les dan y en muchos más casos trabajan extra para cubrir esas estimaciones ajustadas que su propio orgullo les hizo generar.

Y esas 30 líneas …. son como la fórmula de la Coca Cola… Esas 30 líneas … es de lo que vive todo el ecosistema que se nutre de los programadores.

 

Deja un comentario