Nonsense

Escribí esto en otro lado y se me ha ocurrido dejarlo aquí “para tenerlo a mano” y quizá revisarlo un poco. El original, junto a otros mucho más interesantes, está aquí. Se centra un poco en la idea de presentar un camino de “cosas a aprender” para mejorar como programadores.

Cómo mejorar como programador

Me gusta el término geométrico actitud. Todos pensamos en el término psicológico, pero me gusta el geométrico porque está más libre de prejuicios. La actitud geométrica de un objeto en el espacio es simplemente la orientación que tiene. En dinámica suele tomarse como referencia una que sea relativa al movimiento del propio objeto. Es decir, en palabras simples: la actitud nos dice hacia dónde estamos mirando respecto hacia dónde nos estamos moviendo. Me gusta el término porque un avión solo puede volar si mantiene la actitud correcta, si no, termina entrando en pérdida y cayendo. Algunos aviones más avanzados, usando empuje vectorial son capaces de un control de la actitud que les permite realizar maniobras más precisas y complejas.

Si no tenemos un buen control de la actitud, solo podemos limitarnos a seguir hacia adelante y esperar tener suficiente sustentación. Igualmente, sin una buena actitud -geométrica- en nuestra profesión, será muy difícil (si no imposible) que podamos maniobrar nuestra carrera y nuestro progreso.

Un buen control de actitud implica principalmente dos cosas:

  • Ser consciente de la posición y orientación que tienes en este momento.
  • Tener capacidad para cambiar ambas cosas.

En palabras más sencillas aún: Poder “mejorar” no significa nada más que saber dónde estás ahora, saber a dónde quieres ir y hacer el esfuerzo de ir hacia ese punto. Como es evidente, todo esto es aplicable a cualquier profesión o, en realidad, a cualquier cosa que hagamos en nuestra vida.

Me gusta esta explicación porque es completamente independiente de lo que para cada uno de nosotros signifique “mejorar”. Nadie puede decirte hacia qué punto tienes que ir, esa es tu elección.

Las capacidades para ir hacia donde quieres

Como desarrolladores, nuestro objetivo más general es el de solucionar problemas, normalmente con la ayuda de algún ordenador y escribiendo algún tipo de código. Para poder hacer esto mejor, estas son algunas de las cosas que, en mi opinión, creo que pueden ayudarnos.

Fundamentos

El coste y el valor de las cosas.

Este es probablemente el concepto más importante que deberías aprender.

Hay diferentes costes. Aprende a diferenciarlos. Hay costes puntuales, que ocurren una vez, y costes recurrentes, que se prolongan en el tiempo. Hay costes de desarrollo y costes de funcionamiento. Costes de mantenimiento, de oportunidad… Es importante que sepas, cada vez que tomas una decisión, qué costes asociados tiene. Los costes no siempre se traducen en dinero, ojo.

También es importante que sepas diferenciar entre el coste y el valor de las cosas. Algo con muy poco coste puede tener un gran valor y viceversa. Y de nuevo, el valor no tiene por qué ser siempre económico.

Hay diferentes tipos de código y pueden tener diferente valor y diferente coste. Muchos factores lo determinan, pero los principales son cuánto tiempo/cuántas veces lo vayas a usar y cómo sea de extenso.

No es el código.

No te pagan por escribir código. El código casi1) nunca es tu objetivo.

No solo eso, el código ni siquiera es la parte importante de lo que haces. El código casi siempre es un coste, no un valor, un sacrificio que hay que hacer. Lo importante, realmente, es solucionar problemas. Y para eso, más importante que escribir código son:

  • Pensar. Pensar es lo que te va a permitir solucionar los problemas. Escribir código “solo” es expresar esos pensamientos.
  • Hablar. Hablar, con las personas que tienen el problema, con cualquier otra persona implicada en el desarrollo, con quienes van a usar tu solución, es lo que te va a permitir saber qué problema tienes que solucionar y si tu propuesta realmente lo soluciona.
  • Saber. Saber, conocer las posibilidades y opciones disponibles, las ventajas e inconvenientes, los costes y valores, es lo que te va a permitir tomar mejores decisiones. Está claro que esto lleva tiempo; más sobre el tema del tiempo más abajo.

Cada cosa requiere un esfuerzo y tiempo diferente.

En concreto, cuando se trata de tu aprendizaje, no intentes apresurar todo. Hay cosas que irremediablemente necesitan tiempo. La experiencia no se adquiere de forma inmediata sino… bueno, viviéndola. Por eso ten paciencia. Sé consciente de que quieres mejorar, pero sé consciente también de dónde estás ahora y qué estás haciendo ahora. Recuerda lo de la actitud; no es solo ser capaz de orientarte hacia ese futuro, sino también ser consciente de dónde estás en este momento.

Céntrate en los conocimientos fundamentales.

Diferencia lo general de lo particular, lo fundamental de lo específico, y céntrate en aprender bien los conocimientos generales antes que en acumular conocimientos específicos sin una base. Derivar una solución específica a partir de un conocimiento general es relativamente fácil. La acumulación de soluciones específicas puede que te lleve a un conocimiento general, pero, en general, es más difícil.

Detalles

Los detalles son, como decía antes, menos interesantes, pero voy a intentar extraer algunos consejos algo más concretos.

Aprende a escribir. A escribir bien, claro, bonito, sencillo.

Escribe documentos técnicos, escribe ficción, prosa, verso si te atreves. Escribe. Y cuando lo hagas, como con todo, hazlo prestando atención a lo que haces. Fíjate en cómo funciona el lenguaje, en cómo refleja y expresa tus ideas, en cómo otros interpretan esas expresiones y entienden ideas, con suerte, parecidas a lo que tú pretendías comunicar.

Aprende a comunicar. Esto será útil en sí mismo en muchas ocasiones. Tendrás que escribir una documentación, un email, un informe, dar tu opinión sobre cómo se debería hacer algo, explicar un problema con el que necesitas ayuda… Pero también será útil cuando escribas código. Cultivar una forma expresiva de escribir ayuda a tener una forma igualmente expresiva de programar.

Como complemento a esto: Lee. Lee mucho. Lee cosas variadas. Lee para aprender más y lee también para aprender a escribir.

Aprende cosas diferentes a las que ya conoces.

Parece muy evidente, pero no siempre nos damos cuenta de que lo que estamos aprendiendo no es tan nuevo o distinto a lo que ya sabemos.

Intenta aprender técnicas y paradigmas independientes, ortogonales, incluso opuestos. Aprende los principios de la Orientación a Objetos y también los de la Programación Funcional, que no son opuestos sino complementarios. Si conoces un lenguaje con unos ciertos principios básicos, aprende rápido otro con principios similares para extraer lo genérico, y otro con principios muy diferentes para comparar esos principios. Aprende un poco C y un poco de Ensamblador, aprende por lo menos uno entre Java, C#, C++, Ada, Python y Ruby, aprende JavaScript porque antes o después algo tendrás que hacer con él (la vida es así), aprende, si quieres, un poco de algún Lisp (un poco suele ser todo, pero eso ya lo descubrirás).

Aprende sobre tipos y tipado. No te empeñes en tomar partido por un lado u otro en discusiones sobre tipado (p.ej. estático vs dinámico), sino céntrate en entender las varias partes y lo bueno y malo de cada cosa.

Aprende este principio para organizar cosas:

  • Separa lo que va separado.
  • Junta lo que va junto.

No hay más misterio para crear código fácil de mantener. Ahora solo necesitas saber qué es lo que va junto y qué lo que va separado ;p

Aprende a aprovechar tus herramientas.

Aprende a usar los sistemas de control de versiones. Aprende a manejar tu entorno de desarrollo de forma productiva. Aprende a usar bien un editor básico. Aprende no solo a usar las herramientas sino también qué es lo que hacen (y en la medida de lo posible, cómo), así les sacarás mejor partido pero no _dependerás_ de ellas cuando no las tengas a mano.

Aprende a usar bien los comandos básicos del sistema. Aprende a consultar cómo usar comandos más avanzados.

Adquiere una idea razonablemente aproximada sobre todas las partes involucradas.

Aprende aunque solo sea un poco sobre las cosas que _no haces tú_. Puede que tú trabajo esté centrado al 100% en la Base de Datos, pero igualmente aprende un poquito sobre Frontend. Si haces Diseño, aprende un poco sobre Programación, si es al contrario, pues también. Intenta aprender también sobre infraestructuras, redes, servidores… Aprende lo que puedas sobre el negocio para poder entender lo que haces.. Aunque no tengas responsabilidad sobre todas estas cosas ni necesites saberlo directamente, intenta tener una idea general de todo lo que esté involucrado en el proyecto en el que estás.

Cuenta cuántas veces he usado la palabra aprende en este apartado. Reflexiona sobre ello. Concluye que el mensaje es que nunca debes dejar de aprender :)

Principios personales

No hagas caso a mis principios personales; define los tuyos. Pero en cualquier caso los míos son estos:

  • No hay mejor recompensa que la satisfacción de hacer lo que debe hacerse. Obviamente recibir un sueldo justo por tu trabajo es importante. Necesario incluso. Justo. Imprescindible. Pero nada te recompensará más que tener la capacidad de hacer lo que piensas que es correcto y la satisfacción de conseguir hacerlo.
  • Eres responsable de todo lo que haces. Si rompes algo, arréglalo. Si te equivocas, reconócelo humildemente. Si haces algo bien, permítete celebrarlo.
  • Di más O-tsukaresama desu. La expresión significa algo así como “Muchas gracias por tu trabajo y esfuerzo”. Sé agradecido y aprecia el esfuerzo que hacen los demás. Pueden saber más o menos, ser más o menos amables, o lo que sea, pero reconoce y aprecia el esfuerzo de todos y comprende que todos los esfuerzos suman para conseguir el objetivo.

Insisto, no hagas caso a nada de lo que he dicho. Como mucho piensa críticamente sobre ello y escoge, adapta, lo que te parezca razonable. Pruébalo, observa si te sirve y saca tus propias conclusiones.

1)
La excepción es el arte. Si lo que estás haciendo es arte entonces a lo mejor el código puede ser un objetivo en sí mismo.