Lo sé, lo sé, que el título de post clama al cielo, pero, aunque todo el mundo parezca tenerlo claro… A veces parece que se nos puede olvidar. ¿Eres de los que piensa que el título es incorrecto? …. Sigue leyendo…
Cuando alguien desarrolla software, el tipo de trabajo que realiza es intelectual, vamos, que no es mecánico. Eso no es ni bueno, ni malo, es distinto. Ejemplo de una tabla comparativa encontrada googleando un poco.
No es lo mismo un trabajo mecánico (bajo nivel de complejidad y de situaciones nuevas o inesperadas), que un trabajo intelectual complejo y cambiante.
No quiere decir que esté de acuerdo con lo que pone, la verdad, parece como si en algunos trabajos «manuales» no hubiese que emplear la mente, y creo que eso no es cierto… pero me sirve para introducir contexto…
No es lo mismo un trabajo mecánico (bajo nivel de complejidad y de situaciones nuevas o inesperadas), que un trabajo intelectual complejo y cambiante.
El trabajo más importante que hace un desarrollador de software NO es «picar código», es PENSAR.
¿Por qué te cuento todo esto? Porque, volviendo al título de post, el trabajo más importante que hace un desarrollador de software NO es «picar código», es PENSAR. Ese «sonido de teclas» debe ser la CONSECUENCIA de pensar en lo que tengo que conseguir, y no al revés.
Y, hoy en día, veo que seguimos confundidos en ocasiones, y es muy importante saber las diferencias, o nuestra lógica nos llevará a tomar medidas erróneas o sacar conclusiones erróneas (que algo sea lógico no quiere decir que sea cierto).
¿Qué medidas erróneas se me ocurren que haya vivido en la industria del software? Pues… ¿alguno sabe que existían contratos donde te pagaban por línea de código escrita? A cualquier desarrollador que le preguntes le parecerá absurdo, de hecho, seguramente la calidad de los productos que se elaborasen con ese tipo de contrato muy muy buena ya te digo yo que no era (estoy seguro que en vez de hacer el código de manera más robusta, entendible y mantenible se añadirían algunas lineas de código de propina…)
Pero sí, estaban aplicando esa lógica, intentar medir la productividad de un programador por líneas de código…. (Ay Dios!).
Que hoy en día no se empleen este tipo de contratos (espero que no existan ya!) no quiere decir que no se emplee la misma lógica para tomar algunas decisiones.
Homer Simpson: «¿Podéis teclear… mmmm… un poco más rápido?»
Cuando introduces frameworks como XP, Kanban o Scrum en algunas organizaciones, viene la primera e inevitable queja sobre la cantidad de reuniones que tienen… que, si, que entiendo que a veces hay roles que en el día a día tienen el temido efecto de «muerte por reunión», pero no creo que sea por este tipo de reuniones, que tienen un objetivo claro y definido y que aportan valor desde el minuto 0. Reuniones donde se PIENSA antes de ponerte a programar o «TECLEAR».
Y bueno, no voy a hablar de los que dicen que un Scrum Master «puro», como no teclea, claro, no aporta valor… en fin… fruto del mismo error en el planteamiento del tipo de trabajo que comentábamos al principio.
Y si, algunos managers podrán decirte, que ni reunión previa ni leches, que tenemos que ser ágiles (toma ya!): yo digo que quiero una funcionalidad A o un cambio B y automáticamente quiero oir sonido de teclas desarrollándola…. Lo siento, que más me gustaría, pero esto no funciona así. Supongo que el tipo de programador que quieres es el de las pelis de Oceans Eleven o Twelve o yo que sé por cuál van ya, donde están esos hackers delahostia haciendo sonar el teclado que hecha humo para poner en rojo los semáforos de toda una calle. A lo mejor es eso… la culpa la tiene Hollywood, una vez más… ¡¡¡Malditos!!!
Lobezno de hacker en Operación Swordfish, ¡como teclea sin garras el tío!
Las consecuencias: Productos inmantenibles cuyo destino es ir a la basura más pronto que tarde (Deuda Técnica) o productos con errores e inestabilidades continuas (bugs).
Pero de la diferencia entre bug y deuda técnica y como se genera, hablaremos otro día…