How I learned the NATO Phonetic Alphabet

Did it ever happen to you that during a phone call you had to spell something? An airline code, an email, an invoice number, etc. At those situations, I always regretted not having learned the NATO phonetic alphabet.

NATO Phonetic Alphabet

Flash forward to September 2019: I found myself in a talk about learning and memory techniques during the Automattic Grand Meetup. It picked my interest so I decided to investigate a bit and signed up for the Learning how to Learn MOOC.

In this post I’m sharing how I’ve applied my new gained knowledge to learn something useful that I had put off for a long time. I also hope to interest you in the topic of learning how to learn.

1 – Deal with procrastination

The main reason I had postponed learning the NATO Phonetic Alphabet is that I thought I had a bad memory and it’ll be a lot of work — I procrastinated. Procrastination is a mechanism our brain uses to cope with challenging feelings induced by certain tasks: perhaps we believe we can’t do something, maybe it’s boring, makes us feel anxious, etc. Essentially, procrastination is not about time-management, but about emotion-management.

To deal with procrastination means to deal with and rewire our emotions about the task. Doesn’t sound easy, right? The good thing is that there are a few practical things we can do:

  • Time-box short periods of focus, break and reward. Time 20 minutes during which you’ll exclusively focus on the task at hand and do whatever you can: no pressure in the output, just focus on doing anything. Then, give yourself a break and a reward — exercise a little, eat some chocolate, surf the web, whatever works for you. Do not forget about the reward! It’s a crucial part of rewiring your feelings about the task. Finally, repeat the process a couple of times more.
  • Focus on the process, not the product. Planning and have small wins/rewards is an important part of dealing with procrastination. Things like writing down the next tasks you’ll work on at the end of your day or cross-off the ones you’ve done help you focus on the steps. By focusing on the process, not the final goal, it’s easy to control our feelings of discomfort.

For me, the first focused session was about familiarizing myself with the NATO Phonetic Alphabet: essentially, I surfed the web and read about it. Then, I stopped and gave myself a reward. My second session was about how would one go about memorizing all the 26 symbols (see next tip). Break and reward. I spent the third session developing the system I had researched. Again, break and reward. By the fourth session, I was ready to start memorizing.

2 – Tap the visual and spatial memory

Through many thousands of years, our brain has evolved to be amazingly good at remembering places, visual things, as well as anything that involves the senses. When dealing with abstract concepts it’s useful to encode them into memory leveraging those abilities. For someone who hadn’t consciously done this before and feels that has an average memory, this is easier said than done.

If we look around us, though, there are multiple real-life examples we can draw inspiration from:

I hadn’t done it before, so I spent my second focused session thinking about how would I put in practice the things I had learned. I also reviewed what others did for inspiration: the NATO publishes a guide that links images to the words, some people create a song, etc. Of all the things that I found, the approach suggested by Nelson Dellis -4th time winner of the USA memory championship- was the most appealing to me: he creates an image by merging the letter and the word associated with it.

For example, for the pair A-Alpha he pictures sprouts of Alfalfa coming out of the A letter; for the pair P-papa he pictures a cartoon of his dad with the shape of the P; for the pair U-uniform he pictures the U being a basket where you’d store uniforms; and so on. I highly recommend the video if you’re interested in the mechanics of this.

After I knew the system I wanted to use, I decided it was time for a break (and a reward!). After a while I came back energized to create my own — actually, my unconscious brain already had already suggested some ideas (see next tip). Being my first time ever doing this kind of thing, it took around an hour to come up with my own memorable images for each one of the 26 letter-word pairs.

3 – Focus, rest, and recall

Now that I had a system in place, the next step was memorizing. I went through the phonetic list stopping a few seconds in each of the images I had created. After a few rounds, I stoped and did other things. Then I tried recalling them from memory: I didn’t get all of them but I did get many. I repeated the pattern (focus, rest, and recall) a couple of times during the day. The days after I mostly did recall using the Anki app where I had stored the pairs previously.

It turns out this strategy works a lot better than just going through the list over and over until you are exhausted. There are a number of things at play here:

  • Switching between focus and rest states helps your brain digest the information, so to speak. In the focus mode, you’re able to direct your thoughts to a problem. Although you can’t command your diffuse unconscious brain to work on the things you want, you can prime it to do it — aka make suggestions. How? For example, by taking a break after a focused session (go for a little walk, take a one-second nap like Dali or Einstein, do the home chores, etc.).
  • Space the repetition. Once you reach the point of almost no errors, repeating has diminishing returns — it’s just not effective and creates illusions of competence. To store something in long-term memory, you have to modify the forgetting curve instead. How? Spaced repetition. Instead of cramming a 2h session repeating the same material over and over, do smaller sessions spaced through several days. Useful ways to be deliberate about practicing is scheduling your review and study sessions in a calendar, use flashcards to keep track of progress, etc.
  • Recall from memory. Long-term memory is a storage mechanism that prioritizes which memories are consolidated and which ones aren’t that important. By recalling the information, we’re strenghthening the path to retrieve it later. In many ways the mechanism is very similar to paving a cowpath: a memory is strong when it was used a lot during different intervals. Recalling and testing yourself are the most effective techniques you can use to reinforce what you want to learn. Also teaching it to someone else, which is a good technique to uncover the holes in your understanding.


Although the tips I suggested here are universal, how do you apply them to a specific situation varies from problem to problem.

Take memorization techniques, for example: PAO, Major System, Mnemonics, Memory Palace, etc. Some are useful to convert concepts into images, others to link or inter-connect different ideas. It takes time to know which technique is more adequate to a specific problem. That intuition is only built with practice.

Other essential functions of learning that I didn’t use in this process were understanding and chunking. I had a list of 26 symbols that matched a letter in the alphabet and they didn’t have any other meaning; I also didn’t have any pre-requisite knowledge, so to speak. If I was trying to understand a mathematical formula or how a web-browser works, chunking would have been essential. The process is similar to putting together a puzzle and involves compressing the information, learning to deconstruct the concept you’re trying to understand, reason by analogy, transform the concept to a different mode/language (from a formula to a graph, from graph to simple words), etc. It’s a messy process.

The topic of Learning How to Learn is fascinating. There is so many practical things you can do to improve and some of them are so counterintuitive. It’s also a fun way to challenge the pre-conceptions about yourself and indulging a bit of goofyness while you work hard to grok something.

If this post picked your interest, I recommend checking the Learning How to Learn MOOC and/or the book is based from, A mind for numbers. They are comprehensive and contain extensive documentation and research, while keeping things actionable.

Dvorak two years after

In November 2016, I switched from QWERTY to Dvorak. The past year, the change wasn’t noticeable yet, so I was hoping this year would.

This is the completely unscientific test I run: I visit TypeRacer and record races – I’m going to settle at 20 from now on. The texts aren’t the same from year to year, I just trust the random nature of TypeRacer to give me different kind of them: short, large, with tons of punctuation, with very few breaks, and so on.

It looks like I’ve already surpassed my previous baseline after two years using Dvorak – both in terms of speed and accuracy. I had been using QWERTY for about 15 years before switching, so that’s impressive. I guess I’m able to introduce bugs in my code faster!

In a more qualitative note, 2018 has been a year of consolidation. Unlike in 2017, I haven’t changed my input devices and my keyboard configuration has remained the same – that has probably helped my muscle memory to develop faster. I still don’t have a steady rhythm and there are some characters I struggle to type. The accuracy results are more meaningful to me than the speed, as that speaks about my finger health long-term, which was the main reason I was interested to give Dvorak a try.

Function keys in Thinkpads

I usually work with an external ThinkPad keyboard, which matches the configuration of my laptop’s. Lately, though, I’ve been using my laptop’s keyboard more and more. At some point, Lenovo decided to design the 6th keyboard row in a slimmer way and switched the standard F1-F12 keys to function keys (volume, brightness, etc). This is very inconvenient if your work involves typing a lot, as editors tend to offer handy shortcuts with the F1-F12 keys.

This is how you change the default configuration: FN + ESC.

Touch typing in Dvorak

On November 2016 I had a free month between jobs. Apart from some resting, reading, and general preparations for my new adventure, I still had quite a bit of free time to do new things or build good habits. It was while cleaning my office that I found a keyboard I had bought a couple of years back:

Its layout was a beautiful matrix -which is good for your fingers- and came with Dvorak by default. So it struck me: how about improving my typing during the coming weeks?

As a programmer, typing is an essential skill for me. I had been doing it for more than 15 years in a learn-by-doing way, and I plan to keep typing for years to come. I thought it would be fun to spend a couple of hours a day training in touch-typing and give Dvorak a second try. And so I did.

How it felt

Before I switched, I recorded about 15 typing sessions at TypeRacer using the QWERTY layout, which logs typing speed (words per minute) and accuracy (% characters right over the total). I was at 67 wpm and about 95% accuracy at the time.

Progress was very humbling at the beginning; it felt like learning to walk again, and I swear that, sometimes, I could even hear my brain circuits being reconfigured! After a few weeks, though, I was at 40 wpm and, by the end of the month, I was at 50 wpm. I stopped quantifying myself by then: as I started working, I had a lot of typing to do anyway.

During the first months, real-time communication -chat, slack- was the only moment I struggled and felt like perhaps the switch wasn’t a good idea. I don’t know what people thought of me, but my writing at the time was typing-bounded – I was certainly a very slow touch-typist by my own standards. But time passed and I improved.

Spáñish Dvorak and symbols

Throughout the process I changed my setup quite a bit:

  1. I started by using the Programmer Dvorak layout with a TypeMatrix keyboard.
  2. After a few months, I switched back to my good old ThinkPad keyboard because having to use a mouse again after years without it was painful.
  3. A few months later, I switched to the Dvorak international layout, because the Programmers Dvorak didn’t quite suit me.
  4. Then, I tweaked the common symbols I use for programming so they were more ergonomic for my daily tasks.
  5. Although the bulk of my typing is in English, I still need to write decent Spáñish, which basically means using tildes on vowels and ñ so I switched to the Spanish Dvorak.
  6. Finally, Spanish Dvorak wasn’t the improvement I was looking for, so I’ve ended up accommodating tildes, ñ, and other symbols in the Dvorak international as I see fit.

This is how my layout looks like today:

All these changes through the year have affected my ability to build muscle memory – sometimes I still need to look at some specific symbol on the keyboard. However, the current version has been unchanged for months, so I only need a bit more time for them to stick.

Performance to date

Given that I was a QWERTY user for 15 years, I thought I would give the new layout a year before comparing any numbers. The fair thing to do would be comparing after 15 years, but I’m a bit impatient for that. So I went to TypeRacer and noted down the results for about 20 races:

In terms of speed, it looks like I’m mostly there. My median speed now is 65 words per minute, 2 wpm less than before. I had a higher peak (83 vs 79), but I was under 60wpm in more sessions.

In terms of accuracy, I’ve improved a bit. My median accuracy has increased by 1,5 points, and I had only 2 sessions below 95%.


My accuracy has improved, and having fewer mistakes to correct will help me become a faster typist as time passes. By learning to touch-type I also have grown more endurance.

This experiment was very humbling. I believe it increased my brain plasticity by an order of magnitude. Although I hope to improve my numbers, what’s more important to me is to promote a healthy use of the tools I heavily depend upon.

My office i4

I’ve been working from home for more than 3 years now, and my setup has gone through several iterations – the current one is i4.


After joining Automattic, I was encouraged to think about my office setup. The company sponsors the kind of high-quality office perks that you’ll expect in companies at this level, and I took that opportunity to upgrade my own in ways I had been already thinking about. The fact that you are not in their offices, but in your home adds a different feeling to it. Although I appreciate the company efforts and perks, I’d like to stay frugal within comfortable limits, so I didn’t get anything I wouldn’t buy with my own money. I think of my office setup as a gift for the elder me – I wish he’ll be proud of what his younger self is doing for him.

For i4, these are the new additions to my office:

HAG Capisco 8016 chair, which promotes and supports several seating positions.

DIY kit from Autonomous, to build my own height adjustable desktop so I could change between seating and standing positions.

We, humans, are not designed for seating. A lot has been said about the optimal seating position, but an idea that has gained recognition in ergonomics is that changing positions frequently may be the best long-term strategy.

For the past two months, I’ve been experimenting with that idea to learn what works better for me. I’ve used three main positions -traditional seating, saddle seating, and standing- and a lot of other crazy ones. What I’ve found out is that I change positions through the day as my body asks for it, but I mainly use the saddle position (most of the time, but especially when I need to write) and standing (for consuming information). The traditional seating feels a bit unnatural to me now, although it may be a side effect of using the Capisco which is more tailored for other postures. I also have a more traditional chair at home, but I rarely use it.

This is i4. This setup fits me so well that I cannot imagine what i5 will look like yet.


Como parte de mi refuerzo de aprendizaje del inglés, en los últimos meses he estado escribiendo varios textos: formales, informales, críticas, emails, académicos, informes, etc. Mi herramienta favorita actual para esos momentos es Grammarly. Las sugerencias van más allá de la mera corrección ortográfica y son contextuales al estilo de la redacción, te recomienda sinónimos a palabras usadas en exceso, se integra en mi flujo diario de trabajo digital (email, Simplenote, etc) y me envía informes semanales de los errores más habituales que cometo, en el navegador funciona como tesauro al seleccionar una palabra, etc ¿qué más se puede pedir?

Al poco de experimentar la versión gratuita me hice premium; fue un flechazo a primera vista. Aunque no lo he usado todavía me gusta además que, de manera natural, te invite a contactar con un humano para revisar textos que son devueltos en menos de media hora, 3h o un día. Han visto muy bien que la gente con la sensibilidad para usar este tipo de herramientas son presciptores naturales de un servicio de traducción humano.

Como todo buen software, tiene sus peculiaridades que hace que les tengas cariño: por ejemplo, las comas de Oxford han sido un descubrimiento y todavía estoy decidiendo de qué bando estoy. Por el momento, lo único que verdaderamente me molesta es que sólo pueda usarla con los textos de inglés. Me gustaría ver algo así para el español, gallego o portugués. ¿Una especie del famoso dardo en la palabra actualizado al siglo XXI?

Programación de interfaces basada en componentes

En mi travesía por aprender cómo mejorar lo que hice en mi último proyecto, estoy empezando a apreciar el encaje que tienen ideas como el immediate mode, las funciones puras y la inmutabilidad. Conceptos que transcienden modas y que, al entender su utilidad y trade-offs, se introducen en el conjunto de herramientas que tenemos a nuestra disposición, sea cual sea el contexto en que programamos.

Hay otro concepto al que recientemente le estoy prestando atención: programación de interfaces basada en componentes.

¿En qué consiste?

En la creación de elementos reutilizables que sean autosuficientes. Es decir, estables por sí mismos y que no dependan de estado global.

Lo que hacemos ahora
Lo que necesitamos hacer

Es muy interesante comparar cómo diversas herramientas proponen la creación (o no) de componentes. La selección tecnológica es, en sí mismo, un tema con muchos matices y tonalidades y existen diversas aproximaciones para comparar toolkits de programación. Algunas aportan algo, otras no y otras depende.

Por ejemplo, a la hora de comparar dos toolkits líderes de sus respectivos sectores como Wicket y React podríamos hacerlo de la siguientes maneras:

Sin embargo, si los comparamos en términos de cómo componen la interfaz, vemos que su aproximación es similar: proponen crear componentes que encapsulen conjuntamente HTML, CSS y JavaScript. ¿Cómo lo hacen? Tanto Wicket como React crean los componentes mediante un lenguaje de programación (Java/JavaScript) y no mediante un lenguaje de marcado (HTML).

  • Componente en Wicket. En Wicket, la unidad mínima de reutilización es el Panel, que consiste en varios archivos:, panel.html y opcionalmente otros de localización como
  • Componente en React. En React, el componente es un archivo JavaScript que devuelve código HTML. JSX es únicamente azúcar sintáctico que ayuda a que el código JavaScript sea más expresivo.

Esta aproximación los diferencia de otros toolkits como Angular, Polymer, JSP o Mako, que serían ejemplos de lo contrario: la composición de la interfaz se hace mediante un lenguaje de marcado -HTML- o derivativos que compilan a él.

¿Esto supone una mejora?

La respuesta rápida: sí, porque en un lenguaje de programación tienes a tu disposición 50 años de investigación en computer science, destilados con más o menos suerte. Hombros de gigantes sobre los que mirar más lejos.

La respuesta más elaborada: las interfaces son sistemas complejos, necesitamos subcomponentes para simplificar su creación y mantenimiento. Hay dos áreas donde un lenguaje de programación supera al de marcado para crear subcomponentes: encapsulación y expresividad.


La encapsulación consiste en la creación de elementos que podamos (re)usar sin la obligación de entender sus propiedades internas, ni de empezar todo desde cero cada vez. En un lenguaje de programación tenemos herramientas para encapsular elementos y funcionalidades como paquetes, módulos, clases, funciones, herencia, mixins, patrones de diseño, etc. Por el contrario, en un lenguaje de marcado como HTML, las opciones son inexistentes.

Iniciativas como WebComponents se han creado 20 años después del propio HTML. Son bienvenidas, pero no podemos obviar el elefante en la habitación: sólo nos ofrece la creación de paquetes, no todo lo demás. En Wicket y React los componentes son elementos que están programados en Java/JavaScript y, por lo tanto, podemos hacer con ellos lo que normalmente haríamos con cualquier otro trozo de código: herencia, composición, aplicar patrones de diseño, etc.


La expresividad consiste en la capacidad de programar los distintos matices que deseamos. En un lenguaje de programación tenemos a nuestra disposición mecanismos como tipos de datos, control de flujo, inversión de flujo, bucles, paso de mensajes, etc. HTML no tiene nada de esto.

Los toolkits que pretenden componer mediante un lenguaje de marcado -JSP en Java, Mako en python, etc- no poseen esa expresividad. Para solventarlo, tratan de integrar parte de ella en un lenguaje propio que compila a HTML: un sistema de plantillas. Un ejemplo típico que casi todos los sistemas de plantillas poseen son algunas construcciones para controles de flujo y bucles. Por ejemplo, en JSP:

<c:when test="${isThisVariableTrue}">
 <h1><fmt:message key="Title" /></h1>
 <c:if test="${isThisOtherVariableTrue}">
 <fmt:message key="showMessage" />
 <c:out value="${value}" />
 <c:if test="${isThisOtherSecondVariableTrue}">
 <fmt:message key="aDifferentMessage" />
 <c:out value="${aDifferentValue}" />

También necesitan crear mecanismos para pasar información del código a la plantilla y suelen ofrecer nuevos tags HTML para realizar acciones que HTML no permite. Interacciones que cualquier lenguaje de programación incluye por defecto pero que un sistema de plantillas integra con esfuerzo, limitaciones y a costa de aprender una nueva sintaxis no reutilizable en otros contextos. Para controlar la complejidad necesitamos más expresividad que la que nos aportan bucles y condicionales. Si lo único que puedes utilizar es un martillo, todos los problemas te parecerán clavos.


Sería simplista decir que Wicket y React se han convertido en líderes de sus respectivos sectores únicamente por la propuesta de creación de interfaces mediante componentes. Es, sin embargo, un fundamento que comparten y plausible para explicar por qué React tiene éxito y Polymer no: como la productividad aumenta al usar esta aproximación, se acaba extendiendo por microdecisiones de agentes interrelacionados que buscan su propio beneficio.

Al pivotar la construcción de componentes sobre un lenguaje de programación y no sobre un lenguaje de marcado tenemos a nuestra disposición todas las herramientas de encapsulación y expresividad disponibles en el lenguaje, lo que facilita domar la complejidad inherente a la creación de interfaces. El aumento de productividad es de órdenes de magnitud.

Para entender en toda su complejidad los efectos del cambio, conviene releer parábola de los relojeros.

Vagrant con Debian Jessie

Estos días he estado creando un entorno de desarrollo con vagrant para un nuevo proyecto que corre sobre Debian Jessie con tecnologías un poco antiguas.

Una de las bases de datos de ese proyecto tiene más de 12Gb de volcado, pero la máquina de debian viene con 10Gb para todo el sistema, así que me puse manos a la obra para redimensionar el espacio asignado en disco en la máquina virtual.

Esto resultó un proceso menos trivial de lo que yo me esperaba, asi que publico aquí unas notas sobre la configuración completa de la máquina para mi yo futuro y como ayuda para cualquiera al que le pueda ser útil.

Instalar el entorno base

Lo primero fue descargarme el binario de vagrant. No usé el propio que viene en los repos de mi sistema porque ellos no lo recomiendan. Luego, me puse a buscar una máquina Debian Jessie de 64 bits y me encontré con la “oficial“. Así que tener un Debian listo para poder jugar fue tan sencillo como:

vagrant init debian/jessie64

Configurar la zona horaria

Instalando ciertas librerías de i18n y l10n para el proyecto, me encontré con problemas porque la VM no tenía la zona horaria correcta, así que me instalé un plugin que me permite configurar la zona horaria de la VMs.

vagrant plugin install vagrant-timezone

En mi caso, he seteado la zona horaria para todas las máquinas, aunque se puede configurar de manera individualizada para cada una. He puesto mi zona horaria como “CET”. Aunque en la docu del proyecto dicen que es posible usar la variable :host para que la tome automáticamente del equipo, a mí no me funcionó.

Así que en mi ~/.vagrant.d/Vagrantfile he incluido:

Vagrant.configure("2") do |config|
  if Vagrant.has_plugin?("vagrant-timezone")
    config.timezone.value = "CET"

Aumentar el espacio en disco

En este apartado necesitamos hacer 2 cosas: primero, asignar más espacio a la máquina virtual; luego, configurar internamente las particiones para que reconozca ese espacio. Para la primera parte estuve viendo este tutorial. Para la segunda, lo hice de otra manera inspirado por éste.

Lo primero que hay que saber es que vagrant puede usar diferentes providers, que son los sistemas de máquinas virtuales. El que tenía yo era VirtualBox, así que al crear la base vagrant, lo que ocurre es que se guarda un archivo VDMK en el lugar donde mi VirtualBox almacena las VM. En mi caso, esto fue en un directorio tal que “~/VirtualBox VMS/debian-jessie/”, donde encontré el fichero debian-jessie.vdmk que era el que tenía que ampliar. Al parecer, esta funcionalidad sólo está disponibles en discos con formato VDI nativos, no con el VDMK, así que lo primero que tuve que hacer fue convertir el disco a VDI y luego ampliarlo a unos 52GB:

VBoxManage clonehd --format VDI debian-jessie.vmdk debian-jessie.vdi
VBoxManage modifyhd debian-jessie.vdi --resize 50000

A partir de aquí, la operación es la misma que cuando uno hace particiones, aunque yo no lo tenía muy fresco porque hacía años que no me enfrentaba a ello. Lo primero a recordar es que para manejar particiones, los discos tienen que estar desmontados. La idea es arrancar con una ISO como la de GParted y realizar las operaciones desde ese entorno. ¿Cómo hacer esto con una VM de VirtualBox? Pues:

  • añadiendo la ISO como CD al sistema de almacenamiento de la VM


  • configurando el arranque indicando que lo intente como CD primero y luego como disco


  • Et voilà!


Como mi VM no tenía sistema de ventanas, arranqué desde consola luego de aceptar los diversos menús que aparecen e hice las operaciones de edición de tabla de particiones con parted. En mi caso, tenía una partición primaria y una extendida con la SWAP en el disco /dev/sda, así que mi plan fue:

  • borrar la partición extendida
  • reclamar para la partición primaria todo el espacio de disco menos el último giga
  • extender el sistema de ficheros al tamaño total de la partición
  • añadir de nuevo la partición extendida con la SWAP

Que viene a ser lo siguiente:

parted /dev/sda
rm 2
resizepart 1 -1GB
e2fsck -f /dev/sda1
resize2fs -p /dev/sda1

Tuve problemas para crear la SWAP con parted, así que hice este último paso posteriormente con cfdisk ya desde vagrant, que es mucho más sencillo y visual.

Para finalizar, hay que recordar desmarcar el arranque por CD y eliminar la ISO de Gparted  del sistema de almacenamiento de la VM en VirtualBox. Entonces ya podemos arrancar nuestro vagrant de nuevo con normalidad y comprobar  que todo ha ido bien.

vagrant up
vagrant ssh
df -h


Estos días me he dado cuenta de que en 2015 he escrito sin proponérmelo un ensayo sobre la vida en una PYME de desarrollo de software del que me siento muy orgulloso. Está en las 7.400 palabras. Para convertirlo en librito convendría incluirle un glosario como anexo, para suplir la falta de enlaces complementarios. También hacer algo de trabajo para homogeneizar la lectura y eliminar la necesidad de los videos. ¿Algún consejo sobre edición, longitud, maquetación, las gestiones para conseguir el ISBN, etc?

Arquitecturas para la participación

Este post cierra la serie que inicié hace unos meses sobre desarrollo de software en una PYME. En el primer post, escribría sobre cómo seleccionar tecnología; en el segundo, sobre un mecanismo para objetivar el diseño y reducir los costes de producción. En este último escribiré sobre cómo la organización del código que escribes habilita relaciones con otros.

Programar es una comunicación entre personas

«Programs must be written for people to read, and only incidentally for machines to execute»

Esta frase extraída del prólogo del mítico SICP es una de las perlas que, entre los hackers, define el buen hacer de la profesión y que pone sobre la mesa toda una declaración de intenciones por parte de Abelson y Sussman: la programación es un nuevo medio de comunicación y expresión de ideas entre personas. De este enfoque se deriva que lo fundamental a la hora escribir programas de software es hacerlo de tal manera que nuestros limitados cerebros puedan navegar rápidamente entre los múltiples detalles, con sus distintos niveles de complejidad.

Al escribir código, un primer nivel de comunicación se daría entre programadores (con otros o con nosotros mismos dentro de unos meses). La buena o mala comunicación de las ideas a través del código tendría un impacto económico que se observaría en los tiempos necesarios para la adaptación, mantenimiento y aprendizaje de un programa. Entender un programa es un acto intelectual donde entra en juego la experiencia previa, la capacidad de relación de ideas y la compresión lectora, pero también la buena maña del que lo haya escrito para hacerlo de un modo inteligible. Al igual que un ensayo, un programa requiere cohesión interna y ritmo para ser entendible.

Un segundo nivel de comunicación se daría entre programadores y analistas del dominio y/o clientes. Ese tipo de conversaciones modela cómo se comporta el sistema y se transmiten al código en forma de estructuras de datos y algoritmos.  Un programa no es más que la declaración de un proceso que tiene entradas y salidas.

El hecho de que el software refleje estas relaciones sociales es conocido desde hace décadas y cristaliza en una de las más populares leyes de la programación, la ley de Conway:

«Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.»

Es decir, las conversaciones, grupos y jerarquías existentes en el proyecto se trasladarán al código de manera inevitable. La arquitectura reflejará tu estructura de comunicación y poder, determinando el tipo de relaciones que puedes tener con tu entorno. Toda una profecía ciberpunk.

Pero … ¿cómo habilita o dificulta relaciones la arquitectura?

Una PYME pequeña funciona como una comunidad: aunque existen roles y división de responsabilidades (diseñador, programador, administrador de sistemas, analista), hay mucho de pluriespecialismo. Además, por el propio tamaño de empresa, en muchas ocasiones existen proyectos que se realizan con otros equipos. Existen arquitecturas o maneras de modularizar el código que te permiten que esa división del trabajo sea más efectiva. Veamos algunos ejemplos:

Diseño orientado al dominio

La programación es fundamentalmente la transcripción de las conversaciones entre programadores y analistas. Es necesario tener un un lenguaje común y existir entendimiento entre ambos para que la cosa salga bien. Una de las prácticas que más me ha ayudado a organizar el código es el diseño orientado al dominio, es decir: organizar el código en torno a la interacción de las entidades que se definen en la conversación analista-programador. Aunque parezca una obviedad, no lo es, tiene sus trampas y se hace menos de lo que parece. El impacto de esta práctica deriva de cómo facilita las conversaciones y el entendimiento del programa.

Separación de API e interfaz

Esta técnica, conocida ya por los pioneros, ha retomado fuerza en la era de la web ubicua y la arquitectura REST. Con este mecanismo de modularización, el API define el acceso a datos y acciones que permiten usar el sistema. El interfaz es un mero usuario del API. Además de beneficios técnicos, esta frontera tiene beneficios sociales: facilita una división del trabajo en aspectos muy distintos de la aplicación, que requieren conocimientos, técnicas y herramientas diferentes. Esto permite que la colaboración diseñador-programador sea más fluida.

Hay 2 ejemplos que ilustran muy bien mi experiencia. En ciertos proyectos donde creamos formularios para la introducción de datos con una aplicación de escritorio, aplicar este principio nos ha permitido que nuestros analistas (repito: analistas, no programadores ni diseñadores) hayan diseñado por sí mismos los formularios que luego los programadores integran en la aplicación. En otros proyectos, hemos contratado a empresas para que nos ayudasen a crear un API mientras nosotros nos centrábamos en el diseño de la interfaz (y viceversa). Ambas situaciones serían muy complejas de delegar (o casi imposibles) si no hubiésemos hecho un uso intensivo de este principio a la hora de desarrollar el producto.

Creación de plugins o módulos

Otra manera muy evidente de crear espacios para la colaboración es permitir añadir nuevas funcionalidades a tu software mediante la creación de plugins o módulos. Este tipo de arquitectura minimiza la barrera de entrada para que nuevos colaboradores puedan ser productivos muy pronto, ya que no necesitan conocer todo el proyecto antes de incluir una funcionalidad, sino que les basta con conocer sólo lo que necesitan.

En nuestra experiencia colaborando con un proyecto empezamos por el desarrollo de pequeñas extensiones o plugins con funcionalidades limitadas. Pasados unos meses, nos sentimos cómodos y con conocimiento suficientes de ciertas partes internas de la aplicación como para modificarlas y enviar mejoras. Los primeros plugins fueron exploratorios, nos permitieron familiarizarnos con el código y el producto; una vez confiamos, nos lanzamos a cosas mayores. Fue precisamente un aspecto técnico (la creación de plugins) el que nos habilitó para iniciar una relación comercial con el proyecto: de no existir esa posibilidad al principio, se nos hubiese hecho muy difícil como PYME invertir todo el tiempo necesario para entender un proyecto tan grande.

Estos son algunos ejemplos de cómo la arquitectura habilita o impide relaciones, pero existen otros miles de pequeños detalles. La modularización del código es fractal, influye en todas las capas de la aplicación.


El programador es, principalmente, un organizador de ideas y un ensayista. Necesita cierta capacidad lógica para analizar y diseñar un sistema, pero también para organizarlo de manera que habilite buenas conversaciones y una división del trabajo efectiva. Necesita entender a las personas con las que trabaja.

Por ello no me parece casual que Kent Beck, el gran recuperador de ideas de nuestra generación, apuntase que uno de los factores con más impacto a la hora de ser un buen programador es la empatía.