Pensando en programar

Introducción

A lo largo de los años, mientras iba aprendiendo a programar, me di cuenta de que me atraían algunos temas más que otros. Es lo normal, a cada uno nos gustan más ciertos aspectos de la programación que otros. En mi caso hay toda una serie de temas que me gustan. Temas de expresión y de lenguajes, temas de aprendizaje y de enseñanza, temas sobre por qué hacemos las cosas y para qué, y también algunos temas sobre lo que significa programar, pensar y solucionar problemas.

Además de esto, la oportunidad que he tenido de conocer a bastantes programadores por el camino y de poder acceder a bastantes libros y recursos de formación, me ha dejado clara una idea: Existe una notable escasez de literatura que se centre en el que probablemente sea uno de los pasos más complicados en el desarrollo de las habilidades de un programador. Hay mucho, muchísimo escrito mirando hacia temas básicos. Sintaxis y gramática de lenguajes de programación, conceptos fundamentales, paradigmas generales… Por otro lado, quizá no sea tan abundante pero también existe una cantidad apreciable de contenido avanzado y específico.

Sin embargo, entre un punto y otro, me he encontrado a demasiados programadores que se encuentran con la misma dificultad -con muy ligeras variaciones-. Esto se refleja en preguntas como “Una vez montado sí lo veo, pero, ¿cómo empezaría un proyecto desde cero? ¿Cómo lo oriento?” o como “Entiendo los conceptos y una vez vista la solución, comprendo por qué funciona y todo, pero ¿cómo se te llega a ocurrir esa solución?”. Y esto no es un problema solo para programadores con poca experiencia. En bastantes ocasiones, he visto cómo programadores que aparentemente llevaban bastantes años y, en principio, sabían “hacer cosas” razonablemente bien, encontraban una gran dificultad en enfrentarse a situaciones nuevas.

En mi opinión, lo que ocurre es que, como decía, falta literatura que se centre en programar más allá de escribir código o incluso de diseñar arquitecturas. Falta, aunque alguna hay, una guía que enseñe a pensar como un programador. Es decir, que explique cómo enfrentarnos a los problemas y cómo encontrar las soluciones.

Tomando como punto de partida una cita sobre programación que me gusta particularmente

Primero resuelve el problema. Luego escribe el código. John Johnson

necesitamos un modo de aprender a resolver el problema. Hay millones de palabras sobre cómo escribir el código, que, en el fondo, debería ser casi una banalidad.

¿A quién está dirigido este libro?

Como se puede deducir de lo anterior, este “libro” está especialmente dedicado a todos aquellos programadores que se encuentran en esa situación de dificultad. Diría que el perfil típico es el de alguien que tiene ya unos conocimientos básicos generales de programación. Alguien que conoce un lenguaje -o quizá en algún caso más de uno- y lo maneja con cierta rutina. Pero a la vez, se limita bastante:

  • a trabajar dentro de un equipo en un proyecto de duración media o larga, donde generalmente se defiende siguiendo pautas establecidas ya por otros.
  • a repetir proyectos pequeños o medianos, siempre de características bastante similares, porque es lo que conoce.
  • a seguir tutoriales (webs, vídeos, etc) que explican cómo hacer prácticamente cualquier cosa nueva con la que se encuentra.
  • a aplicar una serie de buenas prácticas o utilizar buenas herramientas porque son las que están establecidas pero sin tener una idea realmente clara sobre de dónde surgen esas prácticas o por qué esas y no otras.

Todo esto, no es necesariamente malo. Una persona puede trabajar así, de una forma más o menos mecánica, con un conocimiento más o menos detallado de lo que está haciendo, durante muchos años y es una forma razonable de ganarse la vida.

Este libro a quien está realmente dirigido es a quien, en esta situación o en una parecida, se da cuenta y decide que quiere, que necesita, algo más. Que quiere ser capaz de dar el siguiente paso en la programación, pasando de lo que describimos más mecánicamente como “escribir código” -código que funciona, por qué no- a realmente “solucionar problemas”.

Como es lógico, existe la posibilidad de que el libro pueda ser útil también para personas en otras situaciones. Quizá, por ejemplo, puede servir también a quien viniendo de alguna otra disciplina afín o trabajando con programadores, quiera comprender mejor en qué consiste realmente el desarrollo de software y dónde se encuentran las dificultades. También puede servir a quien haya tenido una formación relativamente mecanicista sobre programación. Sé que existen, por ejemplo, bastantes cursos y programas de formación que pretenden enseñar a programar en unos pocos meses o incluso semanas. Sin entrar a valorar la calidad de ninguno de dichos programas, mi opinión es que la formación que dan en general es bastante superficial y sobre todo está centrada en cómo escribir código. Estos cursos pueden, en algún caso, ser un buen primer paso, pero claramente no pasan de ahí y necesitan una continuación más sólida.

Por supuesto, este libro también puede resultar interesante para quien le guste reflexionar sobre estos mismos temas, sobre cómo pensamos y porqué tomamos unas u otras decisiones. Espero que sea un libro suficientemente entretenido.

Por otro lado, nada garantiza que ningún contenido de este libro resulte de interés específico para ninguna persona concreta. Si te decides a leer y no encuentras nada que te sirva o te interese, 仕方ないわね1), es lo que hay, no puedo hacer mucho más. Ahora bien, si crees que encajas en la descripción, si crees que este libro te debería servir a ti, pero que, por el motivo que sea no lo hace, no dudes en ponerte en contacto. Puedes dejar un comentario en un capítulo concreto si hay algo en particular que no te quede claro o que eches en falta, o puedes enviarme un mail si el problema es más amplio o quieres que añada algún tema que no encuentres aquí.

Estructura y contenido

Antes que definir el contenido del libro, quiero señalar que veremos poco código. O, mejor dicho, veremos una cantidad razonable código, pero cuando lo hagamos siempre será para presentar la expresión de alguna idea. Saber escribir código es un requisito que asumiré en el lector y no nos pararemos a explicar el significado de una determinada sintaxis, el funcionamiento de una función particular o el uso de un API.

Aviso que la mayoría de ejemplos en los que aparezca código estarán escritos o bien en JavaScript o bien en algún tipo de pseudo-código, que ni siquiera nos molestaremos en definir formalmente. Personalmente creo que el uso de un pseudo-lenguaje informal puede encajar bien con el objetivo del libro. En cualquier caso, esto es algo que iré viendo por el camino.

Es bastante probable que, de vez en cuando, algún trozo de código esté escrito en otros lenguajes. La elección de JavaScript como base no responde a ninguna preferencia en particular, sino a que considero que, hoy en día, podemos tomarlo casi como una especie de lingua franca. Quien más y quien menos ha tenido que trabajar en alguna ocasión con él. Y para quien no, la sintaxis es suficientemente sencilla y familiar como para que no sea una dificultad. Sin embargo, en ocasiones, las características de JavaScript a veces no serán las mejores para expresar ciertas ideas. De ahí el uso ocasional de otros lenguajes. En cualquier caso, creo que por la naturaleza de los temas a tratar, precisamente el uso de uno u otro lenguajes no debería tener demasiada relevancia.

En cuanto a la estructura del libro, la idea inicial es la de seguir el desarrollo de un proyecto de principio a fin… O al menos esa era la idea inicial. En realidad, creo que aunque seguiremos esa vía, será mejor no hacerlo sobre un único proyecto, ya que un único proyecto puede no adaptarse a todos los asuntos que quiero tratar. Así, he pensado en tener tres, quizá cuatro, proyectos, de diferente alcance y complejidad, que puedan cubrir más temas y más variados. También el poder tener proyectos diferentes nos ayudará a poder ver diferencias en nuestros razonamientos dependiendo de las circunstancias.

El recorrido del libro va a ser una experiencia bastante personal. No solo personal para mi, que intentaré volcar mi cerebro sobre palabras, sino que la actividad de pensar, que es lo que vamos a tratar, es algo fundamentalmente personal. Como ya sabemos desarrollar software también incluye otras actividades mucho más sociales (comunicación, coordinación, compromisos…). Posiblemente roce puntualmente algunos de estos temas en lo que implican a nivel personal, pero no tengo intención de incluir temas que considero son fundamentalmente empresariales. Es decir, que no tengo interés en hablar de metodologías organizativas, de gestión de equipos, de técnicas de producción.

Los proyectos

No quiero dar una descripción detallada de los proyectos por motivos que ya se verán en su momento. En cualquier caso, he pensado en utilizar estos tres proyectos:

  • Un kiosko de información de un centro comercial. Es un proyecto de baja complejidad que plantea desarrollar un programa que permita buscar establecimientos y ver su situación en un plano.
  • Un juego, posiblemente un juego de mesa con varios jugadores, sin una carga gráfica demasiado intensa. El juego probablemente sea Espías y Confidentes. Considero que este es el proyecto de mayor complejidad. También puede que usemos algún otro juego más sencillo tipo parchís, oca, o trivial.
  • Un sistema sencillo de presentaciones. Un segundo proyecto de baja complejidad, con la idea de introducir algo de variedad sin necesitar demasiada explicación.

Cuando llegue el momento, pondré una explicación más detallada de cada uno de ellos. También es posible que, si veo que puede ser interesante, incluya algún otro ejercicio o desarrollo menor.

¿Quién soy yo?

Hasta ahora, cuando he escrito alguna cosa o he estado enseñando a alguien algún tema, nunca he dado mayor importancia a quién era yo, a por qué era yo quien enseñaba o si yo tenía la capacidad para escribir sobre esos temas. Esto no va a cambiar mucho en esta ocasión. Sinceramente no creo que ni mi experiencia, ni mi capacidad o conocimiento sean particularmente destacables o diferentes a las de otros.

Sin embargo, visto cómo el libro se pretende centrar mucho en “pensar”, creo que es conveniente aclarar algún detalle. Como es obvio, el libro terminará reflejando en buena medida una -entre miles- forma concreta de pensar y de hacer las cosas: la mía. Así que supongo que es conveniente por lo menos, a modo de aviso, explicar de dónde viene esa forma mía de pensar.

Mi formación es de Ingeniero en Automatización y Electrónica Industrial. Podría decir que llevo programando desde los X años, o desde que era niño, pero es irrelevante y, además, seguramente mentiría porque no lo recuerdo con tanta precisión y estoy seguro que en esa época lo que hacía con el ordenador era poco más que trastear y hacer el tonto.

Algo más relevante es que llevo unos 25 años programando en entornos bastante variados. Mi formación es bastante autodidacta. No totalmente, porque en la carrera algo de C, Pascal, Ada y ensamblador aprendí. Y también tuve algunas asignaturas sobre diversos temas de computación. Pero al margen de esto, he tenido que aprender muchas cosas por mi cuenta, y aquí es donde viene lo relevante: A lo largo de los años he tenido la suerte de poder leer bastante y, por suerte o por lo que sea, he tenido la oportunidad de acceder a una mezcla bastante variada de autores “clásicos” y modernos. Esto creo que es una de las cosas que me ha dado una visión más amplia de lo que supone programar. Y comento esto no como algo especial o positivo sobre mi, sino para que se entienda de dónde vienen las cosas en las que creo. De libros viejos y de libros aburridos xD

Por último añado sobre mi que soy una persona bastante crítica en especial con charlatanes, vendedores de humo, y con algunas ideas que mucha gente acepta como buenas. Tengo mis propias ideas sobre lo que creo que es bueno y correcto y tengo algunos valores personales que me importan a mi. Es muy probable que en algunos momentos incluya comentarios basados en estas creencias. El lector es libre de no compartirlas, evidentemente; pero creo que puede ser bueno, como mínimo, plantear algunas de estas cuestiones para que cada uno las medite y saque sus propias conclusiones.


1)
Shikatanai wa ne

Discusión

Escribe el comentario. Se permite la sintaxis wiki: