“¿Qué necesidad hay de hacer que las herramientas de los desarrolladores sean más usables?”, podrán pensar algunos; “Al fin y al cabo, se supone que esos usuarios son expertos en entender y usar la tecnología, ¿no?”. Craso error.

Los psicólogos no dejan de insistir en que los recursos cognitivos son muy escasos (sí, incluso los de los miembros de esa especie que vive pegada a un teclado). Dicho de otro modo: entender un problema y tomar decisiones requiere un esfuerzo muy importante y usa recursos que se agotan rápidamente. Así que si consumimos esos recursos en un problema determinado, tendremos menos disponibles para otras tareas.

Por eso Kathy Sierra insistía en que los desarrolladores necesitamos automatizar todas las tareas que sea posible para poder centrar los esfuerzos en el trabajo realmente creativo.

Por cierto, si no conocéis el trabajo de Kathy Sierra, solo os puedo decir que escribió algunos de los mejores textos sobre UX incluso antes de que empezáramos a llamarlo UX.

¿No os parece que desarrollar una aplicación es ya lo suficientemente complicado como para tener que dedicar una parte importante del tiempo (¡y esfuerzo cognitivo!) a entender por qué npm no hace más que encontrar vulnerabilidades, o qué comando tengo que usar en Git para no perder el trabajo de los últimos dos días?

Programadores que se las apañan

Como ya explicaba Steve Krugg en su popularísimo libro No me hagas pensar, los usuarios no se aprenden los detalles de cómo funcionan las aplicaciones o las webs que utilizan, sino que van a dedicar el esfuerzo mínimo (otra vez: porque los recursos cognitivos son escasos) para obtener el resultado que desean; simplemente “se las apañan”.

¿Alguna vez habéis visto a alguien introducir una URL en el cuadro de búsqueda de Google para después hacer click en el resultado, en vez de poner directamente la url en la dirección del navegador? Da igual que estén usando la interfaz de una manera que no es la óptima ni la que estaba planeada en un principio: si aprendo que así funciona, lo seguiré haciendo así porque no necesito más.

Ese efecto, perfectamente aceptable para un usuario típico, es peligroso para un programador. Si dedica sus recursos cognitivos a entender y usar sus herramientas, a la hora de programar “se las apañará”, lo que se traduce en que hará el esfuerzo mínimo para que la aplicación funcione. Y no hace falta decir que eso es una receta segura para un software de poca calidad y lleno de errores.

Abstracciones con goteras

Tengo la impresión de que cada vez son más autores los que se están manifestando en ese sentido; aparte de la ya mencionada Kathy Sierra, este otro artículo crítico con Git da, en mi opinión, con uno de los problemas clave con este tipo de herramientas. Concretamente, en el punto 5. Abstracción con goteras (perdón por la traducción):

Git no tiene tanto una abstracción con goteras como una falta de abstracción. No hay prácticamente ninguna distinción entre los detalles de implementación y la interfaz de usuario. Es comprensible que un usuario avanzado necesite conocer algo sobre cómo las funcionalidades están implementadas para captar las diferencias sutiles entre diferentes comandos. Pero incluso los principiantes se enfrentan rápidamente a horrendos detalles internos.

Touché.

Y lo mismo podría decirse de otros recursos usados por los desarrolladores. Por ejemplo, los frameworks JavaScript: en teoría no es necesario conocer sus detalles de implementación para poder usarlos, lo que debería simplificar el trabajo del programador que los usa. Sin embargo mi experiencia es que, una vez que uno se aparta de los ejemplos más triviales, se ve enfrentado a lidiar con sus detalles internos para cosas tan básicas como la comunicación entre componentes o el mantenimiento del estado.

Otro artículo en un sentido similar: Guido Van Rossum, el creador de Python, decía hace no mucho en una entrevista:

Hay un montón de tareas de programación que son sencillas en Python. Para alguien que no es todavía programador, que quiere convertirse en programador, para esa gente Python es particularmente fácil de entender.
[…]
Escribimos código principalmente para comunicarnos con otros programadores y, en menor medida, para imponer tus deseos al ordenador.

Así que volvamos a decirlo: programar ya es un trabajo lo suficientemente complejo como para que usar sus recursos también lo sean. Por eso los desarrolladores deberíamos hacer el esfuerzo de abandonar el esnobismo (¿o será masoquismo?) de usar herramientas que nadie parece entender completamente, y aceptar que no existe ninguna deshonra en crear y usar otras más fáciles de usar.