En unos meses cumplo 25 años desde que presenté mi proyecto final de carrera de Ingeniería en Informática (“la tesis” le llamaban en mi universidad) y algo más de 15 desde que leí mi tesis doctoral. Llevo años pensando en escribir sobre cuál fue el mayor error de mi carrera profesional y curiosamente -o no- me parece el mejor consejo -doble- que puedo dar, no hacer lo mismo:
No te adelantes, no te dejes seducir por puestos de dirección, gestión o representación. Durante los primeros 20 años de carrera sólo preocúpate de aprender y practicar para ser un experto de élite en el área en que estás trabajando. Cuando la domines creerás que lo sabes todo pero en realidad no sabes nada, aprende una nueva y repite el proceso: ganarás tanta humildad como conocimiento.
Ya llegará el momento -si lo deseas- de ocupar cargos de dirección o gestión, cuando seas un profesional reconocido: tendrás ya mucha experiencia en proyectos, sabrás bastante de la psicología y sus problemas sociales, tomarás mejores decisiones y serás de ayuda -que no un gestor molesto- y la gente a tu cargo te respetará y confiará desde el primer día. Afortunadamente con el dominio del software en tantas áreas se puede vivir bien como un buen ingeniero con experiencia. Además -desafortunadamente- es muy difícil encontrar ingenieros de alta calidad y con conocimientos en diferentes áreas.
No puedo dejar de poner otros que aprendí con errores que ahora intento no volver a cometer:
  1. Cuando trabajes en grupo, sobre todo si estáis intentando solucionar un problema, no eches la culpa de nada a tus compañeros, déjales que se equivoquen -es parte de la búsqueda-, colabora y asume las responsabilidades aunque no hayan sido tuyas.
  2. Por el contrario, si alguien nunca asume una responsabilidad o error, o culpabiliza a otros hasta de que no le dejan hacer nada, intenta que quede fuera del equipo. O que al menos no moleste.
  3. Participarás en proyectos interesantes y en otros que son marrones. En realidad todos pueden ser interesantes, depende de la actitud con que los encares: siempre hay cosas que mejorar y aplicar ideas creativas. Tengo el ejemplo reciente de un compañero que le tocó uno de esos proyectos marrones hasta que se dio cuenta que podía reducir los tiempos de ejecución de batches con threads concurrentes, se lo pasó pipa aprendiendo y practicando. No sólo le quedó un programa mucho más rápido y eficiente,  ahora él es un profesional mucho más formado y capaz que hace un par de meses.
  4. Puedes ser un doctor o un graduado en el MIT, pero a la hora de verdad tu compañero autodidacta y tú ejercéis de ingenieros. Trátalo como tal, los títulos formales solo sirven como carné de autoridad para la universidad ;), entre colegas no cuentan, solo lo que has demostrado saber hacer.
  5. Lee mucho código de terceros, fundamentalmente de las librerías, módulos y programas que usas habitualmente. Es una de las mejores formas de aprender.
  6. No dejes de leer, no solo de libros técnicos específicos, también de historia de la informática y ciencia, un poco de filosofía y psicología, álgebra, estadística y algo de cálculo.
  7. No te contentes con dominar una herramienta o lenguaje, aprende cómo funciona toda la pila que lo sustenta: el hardware, el sistema operativo, la máquina virtual o compilador, el API, las librerías, etc. Aprende C o ensamblador, son clarificadores de cómo funcionan las máquinas y todo lo que hay por encima.
  8. Domina al menos tres lenguajes diferentes que cubran: compilados, dinámicos, y funcionales.
  9. Tus programas nunca serán perfectos ni lo suficientemente buenos. Con el paso de los años te avergonzarás de tu propio código. Esto es bueno, has mejorado.
  10. Cuando programes piensa en los lectores de ese programa: escribe y comenta en inglés, que el código sea elegante, si el código te parece espagueti o ilegible descártalo y empieza de nuevo, no dejes de refactorizar mientras programas. No tengas miedo de descartar programas, no es tiempo perdido. Programar es como escribir un libro pero más complejo, si hasta los mejores autores siempre descartan capítulos o textos completos, ¿por qué tú habrías de acertar a la primera?
  11. No empieces a programar como un mono, pasa horas pensando, camina, conversa con colegas, pregunta, haz un prototipo, descártalo y vuelve a empezar hasta que esas primeras líneas no te den asco ni te generen desasosiego por lo que se viene: todo lo contrario, deberían entusiasmarte a seguir programando.
  12. De todas las ideas o propuestas, elige siempre la opción más sencilla (el KISS). Si no hay ninguna que sea claramente sencilla es porque falta pensar más. Si durante el desarrollo te das cuenta que hay soluciones más simples para hacer lo mismo (es muy habitual), descarta y comienza de nuevo.
  13. No hagas optimizaciones prematuras ni tampoco diseño de lo desconocido. Lo primero genera código más difícil de verificar y lo segundo complica el sistema con funcionalidades que nunca se usarán.
  14. Si cuando sale una nueva tecnología eres capaz de darte cuenta en qué podría servirte pero te ríes del hype y buzzwords es señal de que estás madurando como profesional.
  15. Si además de acabar tus proyectos en tiempos razonables y con programas fiables, los haces con buen humor, te acaban ilusionando hasta los más coñazos y festejas como un crío cuando pudiste solucionar una tontería que te tomó horas, ya eres un buen profesional. O al menos no un coñazo de profesional. Que es casi lo mismo.
PS: Ahora veo que me falta algo fundamental, siempre explica a tus colegas por qué haces algo o tomas una decisión. En el código o tomando un café.