Cómo seguir a partir de aquí

Cuando empecé a escribir todo esto, no tenía demasiadas expectativas. Por un lado sabía que todo esto iba a ser poco más que un compendio de mis propias ideas y experiencias. Por otro, tenía muy claro que mi intención no era escribir más sobre la programación repitiendo lo que otras muchas personas antes que yo ya habían hecho. No, la intención era centrarse expresamente en la aproximación en cómo pensar y qué pensar antes que en cómo escribir código o cualquier otro aspecto similar.

Al final he escrito muy poco código y aunque probablemente en la segunda parte haya bastante más, esto creo que tampoco es inesperado.

En cualquier caso soy muy consciente de que todo esto solo es un comienzo. En cierta forma es una especie de legado y es a la vez poco más que un batiburrillo de consejos que daría a alguien que está a punto de emprender un viaje. "Ten cuidado con esto", "Acuérdate siempre de esto otro", y así. Y como siempre ocurre con estos consejos, siempre se quedan cortos y la realidad del viaje será difícil de prever.

Por todo esto, me siento en la obligación de dar unos pocos consejos prácticos finales, que sirvan un poco para decirte que lo que ahora hagas y lo que ahora consigas, ya solo depende de ti, que ahora lo que necesitas es dejar de leer y empezar a aplicar estas ideas.

No dejes nunca de aprender

Como se suele decir nadie nace sabiendo y por mucho que aprendamos lo único que nos queda claro es que siempre hay muchísimas más cosas que aún nos quedan por aprender. No dejes que esto te desespere o te desanime. Esto es lo normal. Lo importante es ser consciente de las cosas. Siéntete orgulloso de lo que sabes y celebra lo que aprendas, pero a la vez sé humilde porque sabes que hay mucho más que aún te queda.

Busca, para aprender, la ayuda de las personas correctas. No siempre será fácil, claro, pero busca siempre un tipo de persona de la que aprender. Esta no es necesariamente la que aparentemente sabe mucho. Los mejores programadores que he conocido, rara vez presumían de que sabían mucho. Busca esa persona que tiene un particular entusiasmo, no por enseñarte todo lo que sabe, sino por compartir contigo el aprendizaje de ambos. Puede que parezca una persona propensa a tener discusiones, pero si es la apropiada te darás cuenta de que son discusiones que tiene tanto contigo como consigo misma y que, al final de cada discusión, algo habréis aprendido ambos.

Busca también buenas fuentes de conocimiento. Esto, en nuestros días de internet con la cacofonía de millones de voces simultáneas, no siempre es fácil. Muchos dan la apariencia de saber a base de subir el volumen. Mi recomendación personal va en dos sentidos. Por un lado tengo cierto cariño o preferencia por libros más: clásicos, genéricos, sencillos. Es mucho más interesante adquirir conocimientos generales, que específicos, ya que estos siempre terminan derivando de aquellos. Por otro lado prefiero identificar un número pequeño de buenos autores, que un gran número de autores mediocres. No sólo se hace más fácil de identificar, sino también de seguir. Dicho esto, recuerda que casi siempre se puede aprender algo interesante de cualquier persona.

Dedica un tiempo expreso a aprender. Bien sea leyendo o mejor aún haciendo algún desarrollo personal. No soy muy amigo de katas y ejercicios repetitivos pero sí creo que es bueno hacer algunos ejercicios de vez en cuando, incluso aunque parezcan sencillos, siempre que nos permitan ejercitar el pensamiento.

Intentaré recoger algunas referencias interesantes en el apéndice de la primera parte. No sé si pondré suficientes; seguramente no, pero los buenos programadores suelen tener dos o tres libros que recuerdan con particular aprecio. Pregúntales por ese tipo de libros, mejor que por un libro específico para aprender X o Y.

Paradigmas, técnicas, metodologías, herramientas

Existen múltiples formas de aproximarnos a la programación. Oirás hablar de muchas de ellas. Programación funcional y orientada a objetos, programación declarativa, guiada por el dominio, guiada por tests, guiada por el interfaz, de dentro a afuera o de afuera a dentro... Otras cosas que oirás tendrán muy poco que ver con la programación, muchas de ellas serán metodologías de gestión. También encontrarás otras técnicas que aún estando relacionadas con la programación, se centrarán en el trato con personas, comunicación, expresión, colaboración...

Siguiendo con lo anterior, aprende todo lo que puedas de estas cosas. Pero aprende también a identificar correctamente qué son y para qué sirven. Algunas pueden convivir juntas y se complementan, otras se superponen y se sustituyen y deberás elegir una u otra. Yo no puedo decirte -ni creo que honestamente nadie pueda decirlo con la seguridad necesaria y sin otros intereses- cuál te va a servir en cada caso. Algunas técnicas funcionan mejor con ciertas personas, con ciertos equipos o con ciertos entornos. No te preocupes excesivamente por esto, pero intenta fijarte en qué te funciona de cada cosa que hagas y en qué te aporta cada una que aprendes.

Eso sí, cuando busques aprender cosas, intenta que estas sean cosas "nuevas". Nuevas para ti, quiero decir; cosas que sean distintas a las que ya sabes. Por ejemplo, hay bastantes lenguajes de programación que se parecen mucho unos a otros. Aprender algo que es igual que lo que ya sabes no te va a aportar tanto como aprender algo que plantea ideas diferentes.

No solo eso. Aprende siempre cosas pequeñas y grandes. Aprende detalles de lo que estás haciendo ahora para hacerlo mejor, pero a la vez aprende ideas generales, que puedas aplicar hoy y siempre.

Un tema que no he abordado aunque podría haberlo hecho es el de elegir tecnologías o herramientas para un proyecto. Es una duda bastante habitual sobre todo para personas que no tienen aún demasiada experiencia, pero, ojo, también para quienes la tienen. Vas a empezar un proyecto y ¿cómo decidir qué tecnologías o herramientas usar? No he querido plantear el tema porque no creo que haya una respuesta universal. O, bueno, sí, hay una, pero es relativamente poco práctica: "Elige lo que mejor convenga en cada caso". Realmente hay mucha discusión y creo que es algo que depende tanto del caso que es difícil dar respuesta. Lo que sí puedo decir es esto: Elige opciones que se adapten bien a lo que necesitas, después adáptate tú a la herramienta con un compromiso suficiente. Es decir, que pienses con calma tu elección antes de hacerla, analizando bien qué te ofrece cada opción, y una vez que hayas escogido una herramienta, una tecnología, una plataforma, trata de utilizarla lo mejor posible, tal como está pensada para usarse. Las herramientas tienen cierta flexibilidad para adaptarse a diferentes situaciones, pero si las retuerces tanto, si las fuerzas para usarlas en formas para las que no están pensadas, terminan rompiéndose. Así que, elige la que mejor se adapte pero también asume que tendrás que adaptar parte de tu situación a la herramienta. Y si eso no te sirve, si no te soluciona el problema o te produce otros problemas, entonces cambia de herramienta. Eso sí, tampoco estés cambiando continuamente de una a otra, de la más nueva a la siguiente más nueva con promesas de que esa solucionará todos tus males, porque eso nunca va a pasar.

Es un proceso largo

Como decía antes, siempre hay más cosas que aprender. Y encima según pasa el tiempo más cosas irán apareciendo. De nuevo, no desesperes con esto. Asume y recuerda siempre que es un camino que lleva muchos años.

Recuerda también que es un proceso tanto de aprender a programar mejor como de aprender a pensar mejor, a tener más puntos de vista, a identificar más opciones, a entender mejor las cosas y el mundo que te rodea.

Como consejos un poco más específicos, me voy a limitar a dar estos como cosas que irás aprendiendo con tiempo y experiencia:

• El coste y el valor de las cosas. Pon empeño en aprenderlo; en gran medida lo aprenderás a base de invertir esfuerzo y de observar lo que consigues.
• No es el código. El código viene después. "Primero resuelve el problema. Después escribe el código."
• Comparte y colabora. Busca la ayuda que necesites y ofrece la que puedas dar. Se aprende bien en equipo -incluso aunque solo sea un equipo de dos personas- cuando se hace compartiendo y colaborando. Y se trabaja bien también.
• Comprende todo lo que hagas. No hagas cosas "porque se hace así" o porque lo dice el manual. Aprende a usar bien tus herramientas pero aprende también cómo funcionan y por qué funcionan así las cosas. Nunca hagas las cosas sin saber por qué.
• Separa lo que va separado y junta lo que va junto. Y da buenos nombres a las cosas.
• Adquiere un conocimiento razonable sobre todas las partes involucradas. No sólo debes entender lo que tú haces. Intenta tener siempre una idea, como mínimo aproximada, sobre el resto de partes que estén involucradas. Lo que hagan otros programadores, lo que hagan las máquinas, lo que quieren los usuarios...
• Aprende a escribir bien. A escribir en general. Te ayudará tanto a la hora de escribir código como a la hora de comunicarte con otras personas. Aprende a escribir de forma clara, concisa, precisa, bonita y sencilla. Después, con los años, desarrolla tu estilo propio.

Sé una buena persona

No te voy a decir lo que es una buena persona. Esas son tus creencias personales.

Pero sea cual sea la idea que tengas de ser una buena persona, incorpórala a tu idea de ser un buen programador. Haz bien las cosas y haz cosas buenas.

Segunda parte

La segunda parte de esto es un ejercicio práctico. No tengo ni idea aún cómo me saldrá, pero la intención es la de compartir y mostrar cómo se podría aplicar todo lo visto hasta ahora a un caso real. Igual que en la primera parte, seguramente no haya muchísimo código, sino que más bien habrá pequeños trozos aquí y allí, ideas y conceptos, planteamientos y planes.

Como digo aún no sé cómo saldrá, pero en cualquier caso es bueno que tú hagas tu propio proyecto. Nada de todo lo dicho hasta ahora tiene sentido si no lo aplicas de forma práctica.

Nota: La segunda parte no llegó a pasar de un par de capítulos y no se encuentra disponible