Llegar a ser un programador “ninja” o “rockstar” (que no sé muy bien que es, pero te lo ponen en todos los anuncios de trabajo) es muy difícil, basta con leer las confesiones de los propios programadores. Pero convertirte en un programador pésimo, el peor programador que jamás ha existido, es mucho más fácil. Basta con seguir estos consejos (a añadir a la lista de cosas a aprender en tu primer día de trabajo):

  • Cuanto más complicado sea el código que escribas mejor. Así demuestras tus capacidades y encima consigues que no te echen porque nadie más será capaz de entender tu código. De hecho, ni tu mismo, cuando pasen dos semanas
  • Mientras programes bien no hace falta que seas bueno comunicando lo que haces. Si quieren saberlo, que miren tu código.
  • No hace falta aprender SQL. Eso es para viejos, hoy en día hay muchos otros lenguajes (y tipos de bases de datos) más chulos
  •  Tampoco hace falta aprender HTML, esto lo dejamos para los diseñadores
  • El jefe siempre tiene razón. Nunca le cuestiones. Aunque su opinión técnica te parezca completamente errónea, seguro que tiene razón que para algo es el jefe. No intentes mejorar su opinión.
  • StackOverflow es Dios. Puedo pegar cualquier trozo de código de ahí en mi programa y estar seguro que funcionará. No hace falta ni que entienda lo que hace. Si tiene muchos votos es la buena.
  • Siempre hay que utilizar el último framework JavaScript que salga. Está clarísimo que un nuevo framework deja inmediatamente obsoletos todos los anteriores (dice la leyenda que el código escrito con ellos podría incluso dejar de funcionar).  Es imprescindible reescribir todo el código antiguo sin falta.
  • No hay que escribir comentarios ni documentar nada. El buen código se entiende sólo.
  • Si hay algo que no sabes hacer con el lenguaje de programación que te toca, es un problema del lenguaje. Invéntate tu propio lenguaje. Sin ninguna duda, la humanidad necesita más lenguajes de programación. Punto positivo si tu lenguaje es esotérico.
  • Optimiza al máximo tu código, teniendo en cuenta todo lo que puede llegar a pasar en los próximos siglos. Tu código tiene que estar preparado para todo. No pasa nada si acabas con un código nada mantenible o todo el proyecto se retrasa por tu culpa.
  • Los tests son para los débiles. Tu código es perfecto, no hace falta testearlo.

Los consejos están inspirados, con adaptaciones y añadidos propios, en este post donde el autor pregunto en twitter cuáles eran los peores consejos que le podían sugerir.

Evidentemente, estoy abierto a oír vuestros consejos. Cualquier comentario que me ayude a ser un peor programador será bienvenido.

La imagen de cabecera corresponde a la famosa restauración, me atrevo a decir que fallida, del Ecce Homo de Elías García Martínez. Composición fotográfica de Ricardo Ostal/AP