De entre los valores de DECIDE, hay uno al que damos especial importancia, pese a que no nos hemos molestado mucho en definirlo con precisión: la excelencia. Lo cierto es que, a simple vista, podría parecer que no es necesario definir esta palabra pero, mirando en el Diccionario de la Real Academia, podemos leer esta definición:
«Superior calidad o bondad que hace digno de singular aprecio y estimación algo».
Definitivamente, es necesario concretar un poco más. Con esta definición, ninguna persona de DECIDE podría saber qué se espera exactamente de ella cuando le decimos que la excelencia es un valor para la compañía.
Por esto, y por otras cosas, me he decido a escribir un post sobre lo que considero excelencia en el ámbito del Desarrollo del Software, y lo que quiero pedir cuando pido que este valor sea la piedra angular de nuestra compañía. Va a ser este un post muy sentido, y es más que posible que me deje llevar por los sentimientos en más de una ocasión.
Para mí, la excelencia, en lo que se refiere al desarrollo del software, puede concretarse en los siguientes aspectos, que desarrollaré más adelante un poco más:
- Maestría / Conocimiento
- Pasión / Orgullo
- Honestidad / Humildad
Y creo que es un buen momento para exponer mi más absoluto rechazo y desprecio al concepto habitual (al menos en España) del ‘programador’, como persona que no tiene que entender nada y sólo tiene que leer un diseño (escrito por un ‘diseñador’) que le han entregado y transformar esto en líneas de código.
Y aunque peque aquí de temperamental, me atrevo a decir que este concepto es en sí una estafa: es imposible desarrollar un software de calidad de esta manera. Si el ‘diseñador’ fuese mínimamente competente, le costaría menos desarrollar el software diseñado que entregárselo y explicárselo a un programador. Además, el arquetipo de ‘programador’ que cuadra con este esquema es el de un becario recién licenciado que no ha programado en su vida. Es decir, lo máximo a lo que se puede aspirar con un esquema así es a un software mediocre diseñado por mediocres y programado por mediocres. Ya está. Lo he dicho.
Para mí, el único perfil válido es el del desarrollador, y no el del programador (es una cuestión de palabras, pero este concepto queda bastante bien definido en este artículo, que me hizo llegar ya hace años Juan Javier Domínguez, Director del área de Investigación Operativa en DECIDE). Y un desarrollador de verdad debería tener la excelencia como una de sus principales cualidades.
Maestría / Conocimiento
Una de las patas que soportan la excelencia en general, y en el mundo del software en particular, es el conocimiento. El software es una disciplina del conocimiento realmente vasta, no sólo por la cantidad y variedad de distintos paradigmas y lenguajes de programación que existen, sino también por las distintas metodologías, patrones de diseño, frameworks, entornos de desarrollo, buenas prácticas, … En fin, dominarlos todos es imposible (¿o no?), pero tampoco es necesario hacerlo para ser un desarrollador excelente. Ahora bien, lo que sí es necesario es, al menos dominar los que se utilizan:
Lenguajes de Programación
Para ser un desarrollador excelente, tienes que dominar los lenguajes de programación que utilizas. Y no nos olvidemos de que dominar un lenguaje no consiste sólo en dominar su sintaxis. Esto es la parte más fácil, de hecho. Para dominar un lenguaje tienes que tener al menos nociones básicas sobre su entorno de ejecución y su compilador (en caso de tenerlo). Además, será necesario conocer las librerías más populares escritas para este lenguaje, así como las buenas prácticas definidas para el mismo. Habrá que conocer también las herramientas más populares para garantizar la calidad del código. Y a esto, sumarle muchas horas de trabajo. No nos olvidemos de que el desarrollo del software es una artesanía, y que, por lo tanto, no se aprende en los libros, sino con la experiencia.
Contextos Metodológicos
También es imprescindible, para alcanzar la excelencia como desarrollador, conocer el detalle del contexto metodológico en el que se trabaja. Aquí no quiero hacer una apología de ningún contexto metodológico en particular, aunque es bien sabido por cuáles me decanto. Pero creo que un buen desarrollador debe de saber adaptarse al contexto metodológico en el que se encuentre, ya sea una metodología en cascada o iterativa, o bien nos encontremos en un entorno a-metodológico o ágil.
Un buen desarrollador tiene que aportar valor en cualquier contexto, si bien es cierto que lo tiene más fácil en unos que en otros. Y para ello tiene que conocer en detalle todos los artefactos que se utilizan en su contexto metodológico, de cara a ser capaz de comprender el proyecto en un sentido amplio.
Patrones de Diseño, Frameworks, librerías
Un buen desarrollador debe de conocer en profundidad los patrones de diseño que utiliza. Opino que no es necesario conocer todos los patrones de diseño en profundidad. Creo que es importante tener una idea de lo que cada uno hace, de modo que se tenga una mínima intuición de cuándo será necesario utilizarlos. Pero lo que sí que es cierto es que, a la hora de decidir utilizar uno de ellos, es imprescindible entenderlo y conocerlo en profundidad.
Con respecto a los frameworks y librerías, creo que un buen desarrollador, antes de utilizar cualquier librería o framework, tendría que haber hecho lo mismo de forma manual. Hay que eliminar el concepto de ‘magia’ del software. El software no tiene vida propia, todo lo que hace está escrito en líneas de código, y si vas a apoyarte en alguna librería o framework para simplificarte la vida (cosa que recomiendo), antes tienes que entender en profundidad lo que hace esta librería y, si es posible, cómo lo hace. Todo para intentar eliminar el factor ‘magia’ del software, y evitar decir frases como «me da excepción» o «me dice que… «. ¿Cómo que una excepción? ¿qué excepción? ¿dónde se produce?. En cuanto se empieza a no entender, todo se convierte en magia. La actitud de todo buen desarrollador tiene que ser la de entender lo que está pasando, y esto se consigue entendiendo en profundidad todas las partes que componen tu software.
Entornos de Desarrollo
¿Quién puede decir que es un buen artesano si no es un experto en la utilización de sus herramientas de trabajo? Lo mismo ocurre con el software: no se puede ser un buen desarrollador si no se domina(n) la(s) herramienta(s) de desarrollo. Cada vez que veo a un desarrollador con el ratón para arriba y para abajo, navegando por los menús para encontrar lo que quiere hacer, en una herramienta que usa ocho horas al día durante todos los días de la semana, se me ponen los pelos de punta.
Uno de los factores esenciales de la productividad en el desarrollo del software es la selección y el manejo de las herramientas de apoyo. Así programes con vi, emacs, Eclipse, MS Visual Studio o el Notepad, si quieres ser un buen desarrollador, tienes que dominar tu herramienta. Una vez has buscado en un menú tres veces una misma cosa, ¿por qué no te aprendes el atajo (shortcut)? Uno de los mejores desarrolladores que he conocido, @alvarogonzalez, pasaba ratos estudiando los atajos de Eclipse. Se los sabía todos. Y además, en las entrevistas que hacía, uno de los aspectos que más observaba era el número de ellos que utilizaba el entrevistado. Y estoy de acuerdo con su criterio: un desarrollador excelente tiene que dominar las herramientas que utiliza. Sean las que sean.
Pasión / Orgullo
El desarrollo del software es divertido. Nada menos. Es posible pasarse (muchas) horas disfrutando desarrollando software. Días incluso. Los buenos desarrolladores disfrutan con su trabajo. Les gusta programar. De pequeños todos jugábamos con piezas de Lego (o Tente, en mi caso) e intentábamos hacer construcciones, siempre limitados por la cantidad y forma de las piezas que teníamos y hasta dónde llegara nuestra imaginación. En el mundo del software, la primera limitación no existe. Con un portátil más o menos moderno podemos construir prácticamente cualquier cosa. Podemos dar rienda suelta a nuestra imaginación, y hacer cosas de las que sentirnos orgullosos. El desarrollo del software puede llegar a ser algo apasionante.
Y sentir esta pasión, este orgullo por el producto de tu trabajo, es necesario para ser un desarrollador excelente. Creo que el código que una persona escribe es un reflejo de sí mismo, y de las ganas que está poniendo en su trabajo. Coincide que me estoy leyendo actualmente la Biografía de Steve Jobs de Walter Isaacson. Y, de entre las muchas cosas que me han llamado la atención, está una de las enseñanzas que su padre adoptivo, Paul Jobs, le transmitió: Cuando fabricaba un mueble, ponía madera de la misma calidad en la parte del frente como en la de atrás. Decía que había que poner el mismo cuidado tanto en las partes que se ven como en las que no se ven. Esta enseñanza la aplicó Seteve Jobs durante toda su vida, y tiene una aplicación idéntica a la excelencia en el desarrollo del software: Hay que cuidar tanto las partes que no se ven como las que se ven. Hay que hacer el software de modo que nos sintamos orgullosos del mismo, tanto por fuera como por dentro. Un desarrollador excelente disfruta enseñando las ‘tripas’ de su software, mostrando las técnicas que ha utilizado, y la manera en la que ha resuelto las complejidades. Un buen desarrollador se siente orgulloso de su trabajo y, como mínimo, no es consciente de nada que merezca la pena mejorar.
No puedes ser un carpintero excelente si no te apasiona la carpintería. Del mismo modo no puedes ser un desarrollador excelente si no te apasiona la programación. Así de simple. Es esta pasión la que te llevará a aprender todos los días, la que te despertará la curiosidad por cada novedad, en definitiva, que te empujará a ser cada vez mejor.
Honestidad / Humildad
Un desarrollador, para ser excelente, tiene que mejorar cada día. No hay un lugar llamado ‘excelencia’ en el que un desarrollador se pueda acomodar una vez ha llegado. La excelencia es un camino, no un lugar. El mundo del software evoluciona constantemente, y es necesario aprender cada día cosas nuevas para mantenerse en esta zona de la ‘excelencia’.
Pero para aprender, para mejorar cada día, es necesario ser humilde. El que piensa que lo sabe todo, no aprende más. Es necesario ser consciente de tu ignorancia para sentir la motivación de aprender más. Y para esto es útil una buena dosis de humildad. Cuanto más sabes, más consciente eres de lo que te queda por aprender.
Por otra parte, otro factor importante del desarrollador excelente es la honestidad: No se puede saber de todo, y no debería de ser un problema reconocer que no se sabe de algo. Ser un desarrollador excelente implica valorar el conocimiento y la experiencia, tanto el tuyo como el de los demás.Y por eso hay que saber cuándo se sabe, y por lo tanto se puede aportar conocimiento, y cuando no se sabe, y conviene más escuchar y aprender.
Si somos apasionados, tenemos conocimiento y, de hecho, valoramos el conocimiento y la experiencia, tenemos que ser capaces de reconocer cuándo no sabemos, tenemos que saber poner en valor el conocimiento de los demás tanto como el nuestro. Si nos ‘molesta’ cuando alguien sin el conocimiento suficiente opina con vehemencia sobre temas que están en nuestra área de conocimiento, no hagamos lo mismo a los demás.
Y dicho esto, ¿en DECIDE somos excelentes?
Pues la respuesta es que no, pero lo intentamos. Intentamos ser cada día mejores. Intentamos poner en valor los principios mencionados en este post, e intentamos que las personas que componen DECIDE sean excelentes en acto o potencia. Tengo el firme convencimiento de que todas las personas que trabajan en DECIDE serán, antes o después, desarrolladores excelentes, y sé que muchos de ellos ya lo son.
Probablemente nunca podré decir que DECIDE es excelente, pero sí que puedo decir que DECIDE es cada día mejor que lo que era el día anterior, y también que ponemos un especial cuidado en la calidad de todo el software que producimos. También puedo decir que en DECIDE se potencia y valora la excelencia por encima de todas las cosas.
Con esto, ¿llegaremos algún día a ser excelentes? Quizás no, pero como he dicho anteriormente, la excelencia no es un estado, sino un camino, y de lo que sí estoy seguro es de que ese es el camino que intentamos seguir en DECIDE.
