miércoles, 17 de diciembre de 2014

El buen programador

A mí, programar me gusta. No considero que sea mi trabajo ideal, porque hay cosas que me gustan más, pero me gusta. De hecho, en el trabajo de programador hay tres vertientes. Una me apasiona, otra me encanta y la tercera la detesto. En general, no me considero un gran programador.

En primer lugar, me apasiona conocer las necesidades del usuario, entender sus problemas y diseñar soluciones óptimas para él. Resulta apasionante conjugar las necesidades del usuario con una buena arquitectura de código y negociar con la parte más técnica de la empresa las soluciones que se necesitan. Realmente, esta tarea no es puramente del programador, sino, según la organización de la empresa, del jefe de proyecto, el project owner o el business analyst, que es la función en la que yo más encajo.

En segundo lugar, me encanta el desarrollo de arquitecturas buenas y algoritmos que solucionan problemas. Es como jugar a un rompecabezas apasionante. El diseño de soluciones técnicas es fascinante, sobre todo cuando las condiciones que se exigen son muchas o complejas. Eso hace la labor aún más interesante. Además, en general no se me da mal, lo que siempre lleva a una mayor satisfacción personal.

¿Y qué es lo que detesto? Pues tirar código absurdo. Escribir para nada. Teclear cientos o miles de líneas cuando, como suele pasar en mi lugar de trabajo, hay un 90% de probabilidades de que no se usen jamás. A veces, cuando lo que haces es aplicar una solución a un problema, te motiva porque estás pensando en ver la solución en marcha. Pero cuando las cosas pasan a ser tonterías sin ningún estímulo intelectual, simplemente no puedo con ellas. Así que, más bien, no detesto tirar código: detesto tirarlo en mi empresa.

En la empresa en que trabajo, como digo, esta tarea se come la mayor parte del tiempo, lo que hace que mi productividad descienda rápidamente. Además, como me gusta el código modular y fácil de mantener, suelo dedicar algo de tiempo extra a conseguir que los proyectos estén bien hechos, sobre todo porque luego hay que cambiar muchas cosas y cuesta el doble o triple de lo que costó el desarrollo inicial. Aquí eso no se estila. Somos los reyes del quick & dirty: si luego cambian, ¡pues ya lo veremos entonces! Y luego nos ganamos fama de lentos ante marketing, o tenemos que decir que "no" a todo lo que piden porque ni habíamos pensado que pudieran pedir lo que siempre piden. Así pues, ante mi jefe pronto me gané la fama de lento y, curiosamente, su juicio ante eso es que no soy un buen programador. Nunca me ha gustado ese juicio. Nunca me ha gustado el quick & dirty. Nunca he encajado con la cultura de esta empresa.

El otro día, nuestro nuevo jefe de operaciones apareció por la cocina y dijo algo similar: "si un programador hace las cosas rápido, es bueno. Si no, pues... no". Es la cultura de la empresa. Y yo me pregunto, ¿qué es un buen programador? ¿Realmente es alguien que implementa una solución rápido?

Entendámonos: cualquiera que haga un trabajo, si es capaz de hacer el mismo trabajo el doble de rápido es mejor. Por narices. A igualdad en todo lo demás, si en una cosa se es mejor, pues se es mejor en términos globales. Lo que pasa es que eso no suele suceder. Cuando digo que en la empresa hablan de rápido me refiero a que, cuando lo dicen, se refieren a que la velocidad es el parámetro, prácticamente único, por el que se rigen. Si tu código no hay quien lo entienda, da igual. Si no se puede mantener, da igual. Si el usuario tiene que hacer ocho clics para una tarea que se le podría apañar con uno, ya ni te cuento. Aquí he tenido que escuchar una frase mítica, que fue algo así como: "A mí la usabilidad me parece una tontería, al final se trata de si lo pueden hacer o no". ¡¡¡¡Pero qué @#$%&!!!! Da igual si es fácil o difícil, si soporte tiene que usar una hoja de papel para apuntar el ID de un usuario para luego buscarlo en otra pantalla... Da igual.

Una nota antes de empezar: no escribo esto para justificar ni argumentar contra la opinión de mi jefe sobre si soy o no buen programador, pese a que no estoy de acuerdo con él.

Así pues, ¿qué es ser buen programador?

Jens "Jeb" Bergensten, desarrollador de Minecraft, dice que "un buen programador es alguien que busca información y a quien gusta el pensamiento crítico". Tras buscar por la web posts sobre el tema y coger al azar seis de ellos, me he encontrado con que cinco mencionan la "búsqueda de información" que Jeb comenta, y los seis hablan de "pensamiento crítico", citándolo como tal o de forma similar. Así pues, ya tenemos dos características. Sobre la velocidad, se menciona en dos posts, aunque uno no habla de rapidez, sino de "atenerse a las fechas".

Me resulta curioso que tres de los posts hablan de la capacidad del programador para comunicarse con el resto. Creo que cualquiera necesita eso, sea programador o no, pero lo que realmente me llama la atención es que de los tres, dos lo describen como "capacidad para enseñar". Esto, en mi opinión, seguramente se debe a que, dada la nula formación que tiene la gente en programación, la comunicación de los departamentos técnicos con el resto suele considerarse del tipo "deja que te explique, porque no tienes ni idea". Mi experiencia como business analyst es que lo habitual es que eso ocurra en ambas direcciones: los demás departamentos también suelen pensar que los programadores son gente cuadriculada que no entiende ni jota de sus asuntos y a quienes, por tanto, hay que explicarles lo básico porque no tienen ni idea. Eso, en parte, es lo que más me apasiona del papel de business analyst. Es como ser un traductor, pero a lo bestia: no solo traduces, que es algo relativamente automatizable, sino que eres capaz de ver los problemas desde dos puntos de vista diferentes, entenderlos y encontrar soluciones. Imaginen una pieza de madera con forma de cuña. Un departamento la ve desde un lado y percibe un triángulo, mientras el otro la ve de frente y percibe claramente un rectángulo. Y tú ves la cuña. Y eres capaz de diseñar soluciones específicas basándote en lo que ves, y de negociarlas para que ambos queden plenamente satisfechos. Es maravilloso, porque entras en un conflicto y sales con una solución que nadie era capaz de percibir y que deja contento a todo el mundo. Y eso es fascinante.

Si hay un project owner o un business analyst, el programador creo que necesita las dotes de comunicación habituales en cualquier profesional. Solo requiere de esas habilidades hasta el punto de mencionarlas en un listado de características del buen programador cuando no existe ninguna de esas figuras y ha de hacerlo el propio programador.

Tres posts mencionan también la estructura del código, y los seis mencionan los errores y su gestión. Cinco mencionan la pasión por la programación (supongo que cualquiera ha de ser un apasionado de su trabajo), dos hablan de crearse sus propias herramientas y otros dos de búsqueda de la perfección.

Mi lista

He aquí una lista de características. Para mí, un buen programador es alguien que tiene suficiente de cada uno de los elementos de la lista, sin primar ninguno sobre los demás y, además, en alguno de ellos destaca especialmente. ¿En cuál? Pues supongo que en el que más se adapte a la cultura de su empresa o el que más útil resulte para el proyecto en que esté trabajando. Habrá programadores en los que prime la velocidad y otros en los que destaque la limpieza de código.

Pasión
Esta es común a todos los demás trabajos que existen en nuestro universo.
Velocidad
Esta también es común a todos los demás trabajos que existen en nuestro universo.
Dotes comunicativas
Esta también es común a todos los demás trabajos que existen en nuestro universo. Lo básico, no hace falta más: como en cualquier otro curro, no exageremos. Y no se trata de enseñar, sino de dejar que te enseñen para conocer las necesidades de tu cliente.
Buena estructura de código
Un código bien estructurado es fácil de mantener y comprender. Y si está comentado, mejor. Y si está documentado, vamos... un altar para el señor.
Capacidad para crear buenos algoritmos
La algoritmia es la base de la buena programación. Hay gente que habla de patrones de código (algo así como recetas para resolver problemas-tipo). Por contra, hay quienes piensan que quien programa con patrones es mal programador. Creo que los patrones es interesante conocerlos, pero quien programa conforme a ellos es porque no suele ser capaz de adaptarlos y generar soluciones más eficientes.
Gusto por aprender
Este mundo avanza muy rápido, y siempre están saliendo nuevas herramientas que es bueno conocer. Además, es bueno tener curiosidad por las necesidades de los usuarios.
Voluntad de hacer herramientas útiles
Solo cuando un programador asume que su herramienta puede ser útil, y tanto más cuanto mejor entienda los problemas de los demás, estará dispuesto a trabajar más para hacer ciertas cosas. Implementar funcionalidades que mejoran la vida de los usuarios normalmente implica más trabajo para el programador. Por eso debe encontrar motivación en la felicidad del usuario y la utilidad de la herramienta.

Y nada más. No creo que mucho más que añadir. Lo de la gestión de errores es algo que, pienso, va con la vocación. Es como decir que un buen albañil necesita ser capaz de poner ladrillos. A ver... Eso no es necesario para ser un BUEN albañil: es necesario para ser albañil.

¿Qué otras características añadiríais vosotros?

miércoles, 3 de diciembre de 2014

Redes sobre los videojuegos

Este blog vio la luz hace unos meses con la publicación de un post sobre videojuegos, sus beneficios y los prejuicios que pesan sobre ellos y sobre quienes los juegan. Hoy, en Facebook, el programa Redes, de Eduardo Punset, recuerda un programa emitido en octubre de 2012 sobre los estudios de la doctora Bavelier sobre los que llama 'videojuegos de acción, como Call of Duty'. Aquí tenéis el vídeo: