Quizá nos han educado para buscar un empleo del que vivir, trabajar en algo con lo que ganarnos la vida y pagar las facturas a final de mes. Quizá, digo, no pusieron durante nuestra educación el énfasis necesario para que siempre busquemos trabajar en algo que no sólo nos guste, sino que nos apasione. Otra cosa distinta es que eso mismo lo busquemos como empleado o como empleador, aunque lo que aquí quiero recalcar es que la excelencia, la calidad, siempre surge cuando amamos lo que hacemos con una intensidad superior al resto de nuestras obligaciones.

No existe ningún trabajo en el que todas las tareas que tienes que realizar sean siempre gratas; para conseguir un objetivo final, un proyecto con resultados, hay que hacer muchas cosas diferentes, unas nos pueden gustar más, otras menos, pero si cuando terminamos el proyecto, dando paso a una nueva fase en él o comenzando otro completamente nuevo, no sentimos cierta satisfacción, orgullo personal o una sencilla alegría por haber terminado algo con calidad y lo mejor posible dadas las circunstancias, entonces es que no estamos dedicando nuestra vida laboral a lo que realmente nos apasiona.

En software esto tiene un impacto enorme, aunque no siempre nos damos cuenta de las consecuencias desastrosas que esto tiene para la ejecución con éxito de un proyecto.

De acuerdo, hay quienes son capaces de dedicar ocho o más horas a una actividad que ni les va ni les viene, lo cual no deja de ser una virtud, necesaria además en aquellos países donde la crisis financiera todavía tiene un impacto grande. No obstante, quienes nos planteamos nuestra carrera laboral como algo ascendente, con pasos positivos y progresivos hacia el éxito, lo que sea que cada uno entienda por éxito, no podríamos trabajar en algo por lo que realmente no sentimos pasión.

Nunca vas a ser bueno, un profesional altamente cualificado, si has elegido hacer algo que no te llena, que no te gusta. Es así de sencillo pero así de contundente.

Del mismo modo, en una profesión donde la excelencia tiene una relación tan directa en la vida de los productos software que construimos, esta característica de los desarrolladores es más relevante que en cualquier otra profesión.

Me gusta mi profesión, a veces tan poliédrica, me gusta realizar productos que le resulta a un usuario final de enorme utilidad. Hay ocasiones en las que un sencillo pero elegante refactoring que hago y que mejora de algún modo la calidad del código que escribo, me hace sentir muy bien.

Igualmente me siento bien cuando me resulta fácil detectar cualquier problema en la instalación de un cliente donde tenemos desplegados algunos de nuestros productos (se ha hecho el suficiente esfuerzo para que el software se pueda depurar), cuando nos plantean una nueva necesidad y vemos que perfectamente se puede encajar en las capacidades de integración del producto, cuando un cliente te felicita porque le resulta fácil utilizar la interfaz de usuario sin recurrir a la guía de usuario (interfaces amigables) o cuando te felicita también porque lo que antes tardaba en hacer varias horas, ahora lo puede realizar a golpe de clic ahorrando costes a su compañía (valor para el cliente final), y un largo etcétera.

Para conseguir eso, hacen falta muchísimas horas de trabajo, disciplina, perseverancia en la creación de pruebas unitarias y de integración, refactorización continua de código y de diseños en cada nueva funcionalidad, clase, librería, etc. implementada y todo eso, desde luego, no se podría hacer si no te has vuelto adicto a ese momento mágico en que etiquetas una nueva versión de tu producto o creas un nuevo branch sabiendo que la versión que cierras en ese momento está bien conseguida, tanto en funcionalidad como en calidad interna de código. Si a esto lo llamamos excelencia, entonces no puedes llegar a ella si pasas ocho horas o más al día trabajando esperando que te ingresen una nómina a final de mes.

Uno de estos momentos, que yo llamo de epifanía, fue cuando colgué mi primera web allá por el 2008 (bueno, no es que ahora esté realmente orgulloso de ese trabajo, pero esa era mi primera incursión en entornos web después de años dedicado a aplicaciones y entornos de backend muy escalables y optimizados).

Una persona que no encaja en lo que hace y en lo que pasa muchas horas de su vida, necesariamente no se va a esforzar por realizar el mejor trabajo posible: la pregunta que los desarrolladores de software profesionales se deben hacer cuando terminan una tarea, es ¿puedo mejorar esto en algo?, ¿puedo abstraer de aquí algo para mejorar el diseño de la solución?, ¿podría simplificarlo aún más?.

Un desarrollador puede terminar su trabajo y ya está, un desarrollador bueno se plantea algunas o todas esas preguntas de vez en cuando o puntualmente, pero un desarrollador excelente se hace esas preguntas continuamente.

Como responsable de grupo de trabajo, una de mis funciones es crear un equipo con personas que se sienten a gusto haciendo lo que hacen, que les guste realmente la mayor parte de las tareas de desarrollo que desempeñan, pero, sobre todo, que se sienten felices cuando se termina algo con una calidad magnífica.

No podemos innovar en áreas de trabajo que no nos gustan del mismo modo que no podemos ser lo más productivos posibles en aquellos trabajos que odiamos.

La primera vez que leí sobre este aspecto del desarrollo de software fue en The Passionate Programmer, de Chad Fowler, uno de los libros que descubrí hace años y que me convencieron de que programar era mucho más que escribir líneas de código.

Sólo podemos programar bien si realmente nos gusta este trabajo y esta profesión tan exigentes.

Esto es exactamente de lo que habla Ken Robinson en el TED en la charla antológica y su libro El Elemento, de cómo la pasión por lo que uno hace lo cambia todo:

https://www.ted.com/talks/ken_robinson_says_schools_kill_creativity

Comparte esta entrada...

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...