Comencé a programar en el colegio, con unos 15 años. Siempre se me dió bastante bien, y finalmente estudié la antigua Ingeniería Técnica en Informática de Gestión en la universidad. Mi lenguaje favorito por aquellos años era C++, así que me dediqué a buscar un trabajo donde se utilizara, cosa de la que me sigo arrepintiendo. En líneas generales, siempre he pensado que no encaucé nada bien el inicio de mi carrera profesional, y con inicio quiero decir los 7 primeros años. Además, como ya conté en mi blog me desmotivé un poco ante lo que me encontré tras finalizar la carrera, en mis primeras empresas el ambiente no era especialmente bueno, y yo no veía motivo de peso para seguir formándome por mi cuenta.
En un período determinado se sumaron una serie de factores que, a modo de catarsis, me hicieron replantearme por completo la forma en que estaba afrontando mi vida profesional, cambié el chip por completo, y comencé a hacer lo que, en mi opinión, todo programador que se tome en serio su carrera debería hacer, y que se puede resumir como "formación continua": leer para aprender de los mejores (ver la sección bibliografía), estudiar, practicar sin parar...También me aventuré a dejar España y mudarme a Londres para, entre otras cosas, estar más cerca de las principales figuras de nuestro mundillo. Aquí he tenido la posibilidad de ver en acción e incluso charlar con gente como Uncle Bob, Sandro Mancuso, Trisha Gee, Simon Maple...y otras personas más "anónimas" pero con muchísimo que aportar también.
A principios de 2015 comencé a escribir en mi blog de manera regular, costumbre que me está reportando muchísimo a nivel personal. En mi opinión, no hay mejor forma de chequear tu conocimiento sobre alguna materia que escribiendo sobre ella.
En la actualidad trabajo en Pivotal, donde, además de aprender una barbaridad, me dedico a hacer coaching a empresas que intentan adoptar las prácticas de Extreme Programming.
Si quieres saber más sobre mí aquí tienes algunos enlaces:
Tengo muy claro cual es la principal cualidad que debe tener un buen programador, y no es en absoluto técnica: humildad. Es necesario ser humilde para reconocer errores, para aceptar críticas de los demás sin tomárselas como afrentas personales, para rehacer (o incluso eliminar) código que nos ha costado horas desarrollar, para reconocer que hemos metido la pata en una entrega en lugar de culpar a los de operaciones, etc.
Realmente el nivel técnico que pueda tener una persona no me importa en absoluto mientras sea capaz de reconocer sus carencias y trabajar en ellas. Esto me lleva directamente a otro rasgo importante, afán de superación. Me gusta mucho decir que, si no te sientes avergonzado del código que escribiste hace un año, seguramente estés haciendo algo mal. Hay que mirar fuera constantemente e intentar ser un poco mejores cada día. Si cada día aprendemos aunque sea una cosa nueva, al cabo del año serán cientos de cosas, que se irán acumulando en nuestro bagaje para poder ser el mejor profesional que podamos.
La tercera cualidad que quiero mencionar es empatía. Empatía para comprender las inquietudes y motivos de nuestros clientes a la hora de pedir cosas absurdas, empatía para escribir código que pueda ser leído sin problemas por otro programador en el futuro, o empatía para enseñar pacientemente al nuevo programador sin experiencia de nuestro equipo.
Me gusta describirme como "Ingeniero de Software", aunque "Desarrollador" me parece perfectamente válido. Sin embargo, creo que mencionar la palabra Ingeniero deja bien claro que tomamos decisiones de manera responsable, eliminando totalmente cualquier reducto a la metdología Waterfall que tanto daño ha hecho, cosa que "Desarrollador" no lo consigue en la misma medida.
Considero que en nuestra profesión los roles deberían estar muy limitados. No creo en la típica escalera Junior => Senior => Arquitecto => lo que venga, como bien dice Modesto San Juan, la arquitectura es una skill y no un rol.
Cada vez se discute más la necesidad de pasar por la universidad para poder ejercer como informático. No tengo una opinión demasiado formada a este respecto, realmente creo que la universidad, sin prepararte excesivamente bien para el mercado laboral, sí sirve para educarnos en la resolución de problemas complejos, cosa que debemos hacer cada día en nuestros puestos de trabajo. No obstante, una persona autodidacta puede alcanzar la misma capacidad si encauza bien su formación, y de hecho añadiría que, con los recursos que existen en Internet actualmente, se pueden conseguir unas habilidades de desarrollo incluso mejores que las que puedan adquirirse en la facultad.
En cuanto a los diferentes conocimientos que cualquier programador debería tener, no quiero entrar en la reiteración y repetir cosas que otros mentores ya han mencionado en este espacio: bases de datos, los principales conceptos de programación orientada a objetos y programación funcional, el protocolo HTTP, estructuras de datos...Lo que voy a hacer es listar los que, en mi opinión, son los puntos flacos de un alto porcentaje de los programadores, en mi experiencia, y que no deberían perderse de vista jamás:
-
Calidad: de nada sirve conocer las últimas tecnologías (en ocasiones hypes), lenguajes, frameworks, si luego escribimos un código lleno de bugs. La calidad no debería comproterse jamás, como profesionales debemos entregar código por el que seamos capaces de poner la mano en el fuego, de la misma forma que un electricista no debería terminar una instalación eléctrica pensando que en algún momento puede fallar. Para conseguir esto, lo más importante de todo es el testeo, aprended todo lo que podáis sobre testing, los diferentes tipos de test, y si os llama la atención, aprended TDD. Yo considero que el TDD es asombroso, pero no voy a entrar en esa discusión cuando aún existe un gran número de empresas que siguen testeando manualmente.
-
Legibilidad: en la misma línea de la calidad, no me interesa que utilices un stack cojonudo si luego yo no soy capaz de entender lo que hace un puñetero método. El código que se entregue al finalizar un proyecto debe ser lo suficientemente legible para que cualquier programador medio pueda mantenerlo sin tener que darse cabezazos contra la pared durante días. Para aprender a escribir buen código, los dos libros de cabecera son Clean Code y Code Complete. Para escribir un código legible, también es muy útil aprender Domain Driven Design (aunque DDD tiene otros beneficios añadidos).
-
Control de versiones: Git se ha establecido como la herramienta estándar de control de versiones, y deberiáis tener un conocimiento razonable de como utilizarla, más allá de pull, commit y push. Estoy hablando de cosas como, gestión de ramas o interactive rebases. Un buen recurso para aprender los fundamentos de Git es esta web.
-
Refactoring: el refactoring debería ser una constante en vuestro día a día. A todos nos gusta decir que somos ágiles, y entregamos código constantemente, olvidándonos de las tediosas fases de diseño y análisis. Pues bien, sin un refactoring constante de nuestro código, a todos los niveles, Agile no funciona. En todo momento tenéis que reflexionar sobre el estado de vuestro código, y llevar a cabo las acciones de refactoring necesarias. Para llegar a unas skills de refactoring óptimas, lo primero debería ser leeros el libro de Fowler, y lo segundo, dominar vuestro IDE (IntelliJ, Eclipse, etc), puesto que las facilidades que exponen para automatizar estas acciones de refactoring son tremendas.
-
Inglés: ¿recordáis el esperanto? Ese lenguaje no cuajó, pero el inglés tomó su lugar. Aprender un idioma es tan complicado que, a nada que no tengamos una motivación muy fuerte, es fácil no prestarle ninguna atención. Bien, eso tiene que terminar, ponéos en serio con el inglés de una vez por todas. Aquí tenéis una serie de consejos que escribí al respecto.
Termino aquí, aunque me deje muchas cosas. Finalizo con un último consejo, que se han convertido en un mantra que repito a diario. Por favor, no dejéis ventanas rotas.