Después de las opiniones realizadas por los Soul Developers con respecto a dos de los puntos del artículo “Good Devoloper, Bad Developer”, continuamos con las reflexiones de los caballeros de las buenas prácticas, inspiradores de sabiduría y literatos del código: Gentlemen Developers.

Israel Alcázar

Informático de vocación. Dedica parte de su tiempo ayudando a equipos de desarrollo realizando labores de Formación, Coaching Técnico y Mentoring. Le apasiona compartir conocimiento y el trabajo con personas. La motivación y la pasión son las armas mas potentes con las que contamos las personas.

La mejora continua es una de sus obsesiones por ello se encuentra en búsqueda de nuevas formas de trabajar. Apasionado de la web y la tecnología móvil también dedica parte de su tiempo a coordinar el grupo de JavaScript en Madrid y es uno de los organizadores de SpainJS, una conferencia internacional sobre JavaScript.

Good developer understands the problems of the customers. Bad developer understands only the technical problem at hand. Good developer does not define the why, but constantly strives to understand why. He’s responsible for the how, and still sees the big picture. Bad developer is focused on building classes and methods and configuration files, but does not get the big picture.

Israel comenta que — puede ser un fallo bastante habitual que los desarrolladores nos olvidemos muchas veces del por qué del software que desarrollamos. Nos olvidamos que ese software que construimos tiene que servir a alguien para mejorar su forma de trabajar y hacerle mas productivo.

Hay que reconocer que a veces sólo nos centramos en cultivar nuestra parte mas técnica. Asistimos a eventos, charlas y conferencias técnicas pero, se nos olvida que también, sería bueno cultivar otro tipo de cualidades. Cualidades como empatía, paciencia, visión de producto. Todas ellas igual o mas  importantes que las actitudes técnicas.

Un buen desarrollador, debería pensar antes de “tirar” una sola línea de código en los usuarios que utilizarán la aplicación, en qué problemas tienen y cómo queremos ayudarles. Por eso, antes de ponerte a programar piensa en tu usuario.

Dicen que entre el 50-70% de los defectos que se encuentran en el software provienen de un mal entendimiento de los requisitos. Un buen desarrollador, intentará minimizar el número de defectos. Esforcémonos por entender bien esos requisitos a través de las personas.

También perderemos foco si olvidamos el propósito general de la aplicación. Esa foto general de lo que se supone debe hacer la aplicación deberíamos tenerla siempre presente. Actúa en local (en tu código) pero piensa en general (en toda tu aplicación).

Existen algunas técnicas ágiles como las Incepciones al inicio de un proyecto que sirven para conseguir ambos objetivos: entender mejor a nuestros usuarios, no perder de vista el objetivo principal de la aplicación.—

Félix Manuel Menéndez

Analista, ideólogo, crítico de ideas, desarrollador clave y superviviente de cualquier proyecto tecnológico. Multidisciplinar más que especializado. Cuando desarrolla o cuando escribe, nota como se activan partes similares de su pensamiento. Caballero inspirador y de gran sentido ético. La literatura ha sido siempre su compañera de viaje.  Si no hubiera sido desarrollador, hubiera sido escritor. Su mayor obra: su hija. Siempre mirando al futuro.

Good developer is not afraid to go into anyone’s code. Bad developer is afraid of others looking into his. Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify.

Una vez establecidas las premisas Félix comenta que — Good developer is not afraid to go into anyone’s code, puede servir como indicador de la profesionalidad o el compromiso de un trabajador ante un problema que desearía no afrontar, como si se tratase de un cirujano con una operación complicada por delante. Nuestro trabajo no siempre es divertido, y no tiene por qué salir bien.

¿Dónde nace este código presuntamente terrorífico? La respuesta que a todos nos gusta escupir es la falta de profesionalidad de los demás. Pero es apresurada y dañina.

Teniendo en cuenta que el mantenimiento se prolonga en el tiempo más que la construcción, todos queremos escribir un código genial que nos permita afrontar esa fase con garantía de éxito. Por los motivos expuestos, en ocasiones entregamos código mejorable (eufemismo). Si siempre se toma la decisión de quitar prioridad a la parte técnica (un cliente que el primer día te dice que no quiere pruebas unitarias va por este camino), terminamos con bases de código de pesadilla.

Bad developer is afraid of others looking into his. Mi experiencia me dice que justo el opuesto, es cierto.

Por el efecto del Impostor (hermano del Dunning-Kruger, quién más miedo tiene de qué miren su código suele ser el buen desarrollador, que entiende que el desarrollo de software es una búsqueda de equilibrios, capaz de distanciarse del concepto de perfección, y sabe los atajos que ha tenido que tomar para que la pieza que acaba de escribir encaje en el contexto del proyecto.

Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify. Salvo para pequeños trozos de código aislado, escribir código limpio y documentado lleva más tiempo. En un proyecto real, cada cambio es complejo y es difícil dar la mejor solución a la primera.

Los detalles no emergen hasta el momento en el que las letras empiezan a aparecer en la pantalla (ver la cita de Clean Code). Puedes diseñar, escribir, las líneas en tu cabeza y restar ese tiempo del que estas tocando el teclado, pero eso es una trampa. Cada elemento que convierte en bueno un fragmento de código (por ejemplo, las pruebas unitarias, que son, además, documentación) hay que escribirlo, lleva tiempo, no aparece de la nada. Y, a veces, hacer buen código significa simplificar (recomiendo leer “The Most Beautiful Code I Never Wrote” de Jon Bentley.

Reflexión

Israel, Félix es una maravilla poder aprender tanto de vosotros ¡gracias! Me quedo con dos titulares:

Cualidades como empatía, paciencia, visión de producto. Todas ellas igual o mas  importantes que las actitudes técnicas.

Por el efecto del Impostor (hermano del Dunning-Kruger), quién más miedo tiene de qué miren su código suele ser el buen desarrollador.

¡Hasta la semana que viene!