He leído este post en javaHispano y lo iba a menear, pero, no. Creo que se merece antes una reflexión.
Apenas hace unas semanas que Ricardo publicó un post (y luego este y este otro) sobre lo que, según él, debía ser un buen programador. Dice algunas cosas como que el programador es un privilegiado, que no hay dinero que iguale la satisfacción de hacer feliz a un usuario y que tienen un alto reconocimiento social.
Impresionante el aluvión de críticas que recibió de un post bastante inocuo, sobre todo con el hecho de que muchos de los que comentan en él se sienten atrapados en su empresa, en unas reglas de negocio y plazos de entrega muy ajustados que hacen que su labor de programadores no sea, para nada, tan romántica como propone Ricardo.
No voy a entrar a valorar esas afirmaciones, aunque sí pienso que el hecho de ser buen programador o no no tiene nada que ver con la remuneración obtenida a cambio del trabajo o con el reconocimiento social obtenido, incluso con la felicidad obtenida por el desarrollo del software en sí.
Lo que sí me ha llamado mucho la atención es la cantidad de quejas recibidas de personas descontentas con su puesto de trabajo alegando: problemas físicos por la falta de ejercicio, problemas familiares por la falta de tiempo que dedicar a los seres queridos, problemas de calidad del software debido a los plazos ajustados… En definitiva: problemas porque están puteados en su empresa.
Gregor Hohpe, arquitecto software de Google, habla en el ServerSide Java Symposium en Las Vegas de lo fácil que es que un buen código se deteriore, se vuelva lento, buggy e ilegible.
Propone escribir código para las personas y no para las máquinas como solución conceptual a este problema.
Más allá de que tiene más razón que un santo, me sorprende la cantidad y tono de los comentarios vertidos en el enlace que publican en TheServerSide y en el propio enlace de javaHispano.
La mayoría de programadores se quejan de los mismos dolores que en el artículo de Ricardo: problemas con la dinámica del negocio, problemas con jefes incompetentes, problemas con horarios y agotamiento físico… que hacen imposible la limpieza del código, hacen imposible que el software tenga calidad.
Es decir, resumiendo, que ser programador implica necesariamente hacer más horas que un tonto sistemáticamente, hacer malos programas, pasar del usuario (el enemigo), dejar de ver a la familia, dejar de hacer deporte, dejar de tener vida social, cobrar poco y tener jefes inútiles.
Si alguien ha leido hasta aquí e iba asintiendo con la cabeza mientras leía el último párrafo, un consejo: cambia de empresa.
Reconozco que trabajar de programador para ganarse la vida (inclúyase en la definición de programador cualquier otra profesión relacionada que implique tener que tocar una línea de código aunque sea muy de vez en cuando) dista de ser tan romántico como Ricardo comentaba en su artículo.
La mayoría de personas trabajan a cambio de una remuneración económica y el reconocimiento que obtienen aparece más como consecuencia del alcance y beneficio social del trabajo realizado que por el simple hecho de tener esa profesión.
Ahora bien. La calidad del trabajo es inversamente proporcional a la desfachatez del sujeto que realiza el trabajo, y eso no tiene nada que ver con ser programador o no. Si el código es nefasto, arréglese. ¡Pues no he dedicado horas de trabajo en hacer refactoring y en mejorar, generalizar y documentar código que puede ser utilizado en otros sitios!
La satisfacción de un trabajo es el trabajo bien hecho. Los que echan horas, también lo saben y conozco a mucha gente que trabaja 10 horas de tirón porque disfrutan con lo que están haciendo. ¡Vamos! ¿Quién no se ha quedado pegado a la pantalla un rato más porque estaba a punto de terminar aquella cosa que ha estado pensando con detenimiento hasta encontrar la solución perfecta?
Claro, que, para darse cuenta de estas cosas, hacen falta años. Hace falta haber estado puteado, hace falta haber programado mal y peor, hace falta haberse retrasado, hace falta haber mantenido el código de otros. Luego, después de tanto tropezón resulta que la carrera sí servía para algo y que el mejor código es, de verdad, el que se escribe para que lo lean otros y no una máquina.
Blog jubilado de Paco Ros 