Por fin, vamos a terminar la saga de los “Good Developer, Bad Developer” conociendo la visión de dos “buenrollistas” Julien y Pablo. Nos hablan de su preocupación por la calidad del proceso y del producto a la hora de ser buen desarrollador.

Su actitud positiva hacia su trabajo y hacia los demás se contagia. Cabeza y corazón en lo que hacen. Almas tranquilas con las dosis justas de locura, ellos son los Reggae Developers.

Su opinión sobre la afirmación:

Good developer cares about the product quality. He is also very much concerned with the process quality. Good developer pushes himself to create bug-free code; bad developer leaves it to QA to find bugs to fix

Julien Castelain

La unión hace la fuerza.

Alma de desarrollador en constante y pacífica lucha por escribir un código limpio, testeable y mantenible. Su objetivo es aprender y divertirse mientras trabaja en serio. Optimista pragmático enamorado de las cosas más simples haciéndolas extraordinarias.

Julien nos comenta:

— Como desarrollador, estés trabajando por tu cuenta o para un cliente, el objetivo es “producir” algo estable que funcione como debería y también que se pueda “evolucionar” fácilmente, lo que implica escribir código “limpio” y mantenible. Para llegar a esto, está claro que vas a tener que probar tu código a todos los niveles,  eso no significa que un tercero (como el equipo de QA, por ejemplo) no pueda encontrar fallos a nivel de funcionalidad, ellos están también para ayudarte y detectar cosas que no has podido ver (no somos máquinas … o como se dice en mi pueblo “l’erreur est humaine”.

Es mucho decir que un desarrollador que deja esta tarea al equipo de pruebas sea malo, porque según el proyecto o el cliente las especificaciones que tienes como desarrollador no son la mismas que tienen el equipo QA, y eso se olvida mucho.

Estoy seguro que el desarrollo de software “empresarial” es un trabajo de equipo, y es cierto que es fácil culpar al desarrollador y a su trabajo, pero hay que ver también el trabajo de otros protagonistas. —

Pablo Aznárez

Dime y lo olvido, enséñame y lo recuerdo, involúcrame y lo aprendo.

Corazón de niño escondido sonríe tímidamente mientras desarrolla. Despistado buscador de la mejora continua, entiende el fracaso como los ensayos del éxito. Carisma humilde de vencedor extrañamente entusiasmado con el humor absurdo.

Pablo cree que — para ser un buen desarrollador no sólo depende de uno mismo, hay muchos factores que influyen negativamente impidiendo explotar sus cualidades: plazos de entrega que se ajustan muchísimo y que no tienen en cuenta pruebas unitarias-funcionales, implementar nuevas tecnologías en los proyectos, parches, parches y más parches que se deben casi siempre a un mal análisis, o proyectos en los que han trabajado muchos programadores (muchos de ellos becarios o con poca experiencia) que hacen que nadie sepa quién ha hecho qué y cómo, haciendo costosa la refactorización del código.

No hablaremos de los tiempos para I+D, un desarrollador de vocación lo hace como “hobby”, en sus ratos libres, pero hablamos (de nuevo) de la entrada en escena de la empresa y los compañeros de equipo, los cuales deberían estar abiertos a implementar nuevas tecnologías o metodologías que ayudarían seguro a reducir los pazos de entrega, corrección de errores, creación de un código limpio, etc, etc.

Todo esto (entre otras cosas) puede hacer que la ilusión, ganas y esfuerzo de un buen desarrollador se resuma a “si funciona es suficiente”. —

Reflexión

Julien, Pablo; gracias por ser un ejemplo de compromiso y actitud positiva. Me quedo con dos de vuestras reflexiones:

Es fácil culpar al desarrollador y a su trabajo, pero hay que ver también el trabajo de otros protagonistas.

Todo esto (entre otras cosas) puede hacer que la ilusión, ganas y esfuerzo de un buen desarrollador se resuma a: si funciona es suficiente.

Cuánto talento … We’re jamming, jamming and I hope you like jamming too.