Tinselcity

Hace un rato, mientras me deslizaba sin demasiado interés por encima de un artículo mediocre, me he encontrado una vez más con una idea que se repite una y otra vez entre un amplio grupo de programadores. En este caso lo decía de esta forma:

Good programmers write good code and bad programmers write bad code, no matter the programming paradigm. However, the programming paradigm should constrain bad programmers from doing too much damage. Of course, this is not you since you already are reading this article and putting in the effort to learn. Bad programmers never have the time to learn, they only keep pressing buttons on the keyboard like crazy. Whether you like it or not, you will be working with bad programmers, some who will be really, really bad.

El autor firma como “senior engineer” y dice que “guía equipos hacia el código seguro” (luego en un comentario confiesa que por lo menos esto último no es cierto, pero ese es otro tema; lo que sigue no es personal de ningún modo y ni siquiera voy a enlazar al artículo original porque es irrelevante).

Vaya por delante que lo que sigue, como dice el título, no es más que mi reflexión personal. Como tal, seguramente está demasiado influida por los problemas de mi cabeza y por mi actual estado de ánimo. Así que conviene tomarlo todo con cierta precaución :)

Buenos, malos y estúpidos, una breve reflexión sobre lo que significa ser "desarrollador senior"

Llevo ya un tiempo viendo cómo ciertos grupos del sector se dedican, consciente o inconscientemente pero de forma continua e insistente, a devaluar y despreciar la importancia que tiene la experiencia. Son, principalmente, dos grupos: principiantes, y quienes trabajan en el mercado del empleo (reclutadores, anunciantes, contratantes, body-shoppers, etc). En el caso de los programadores principiantes no es que esté justificado, pero sí es comprensible. No es malintencionado, se trata solo de intentar defender su propia validez en la industria. Personalmente creo que hay argumentos mejores para hacerlo, pero somos humanos y es fácil creer que la forma de defender lo propio es atacando lo ajeno. En el caso del segundo grupo… casi prefiero no hablar, pero en demasiados casos se hace con la intención específica de reducir costes a base de devaluar “conceptos caros”1), como la experiencia o la calidad. Llamadlo “malintencionado” o no, pero personalmente no puedo estar de acuerdo.

Experiencia

En mi opinión, la experiencia es algo apreciable y con gran valor. Eso sí, hay que saber establecer cuánta experiencia se tiene y en qué.

Un error muy común es el de medir la experiencia en años, sin más. Y, obviamente, este es un argumento que usan quienes intentan quitarle valor a la experiencia. Sí, por supuesto que no se puede medir la experiencia en años y que 20 años haciendo la misma cosa y haciéndola mal no tiene apenas ningún valor. Pero incluso así, la experiencia sigue siendo cuantificable en cierta medida. Es triste ver, por ejemplo, currículos que mencionan experiencia en media docena de lenguajes de programación, otra media docena de plataformas, media docena más de frameworks, y otras tantas tecnologías, y después resulta que la persona ha trabajado 2 años con el mismo lenguaje, plataforma, librería, tecnología, pero cuenta como experiencia cosas como hacer un ejercicio en la carrera, seguir un tutorial en video, o simplemente “conocerlo” de forma más o menos genérica. Sí, todos sabemos lo que es inflar un currículo y que, a veces, parece inevitable. El problema real es que muchos realmente creen o terminan creyendo que eso de verdad cuenta como experiencia y que presentarlo como tal es tan válido para ellos como para quien tiene realmente experiencia profesional con esa misma tecnología, lenguaje o plataforma, y la conoce a fondo. Así que aunque no podamos cuantificar la experiencia en años, sí que podemos, en cierta medida, cuantificarla y cualificarla.

También existe el problema de establecer cómo es esa experiencia. O por decirlo de otra manera en qué se tiene experiencia. Entre dos personas que han trabajado con Spring, por ejemplo, durante periodos similares y en proyectos con alcances parecidos, la diferencia puede seguir siendo enorme. He conocido personas que han trabajado diez años con Spring y aún no lo conocen en absoluto; se limitan a seguir una chuleta que se han hecho con comentarios como “y aquí pones el mismo nombre que aquí” o “hay que poner esto aquí porque si no no va” y no salen de ahí. Otras tienen un conocimiento relativamente superficial pero mucho más amplio; conocen y comprenden diferentes conceptos y, aunque no hayan llegado a profundizar más -por falta de necesidad, o por el motivo que sea-, tienen una visión mucho más extensa de todo lo que ofrece Spring. Otros aún alcanzan un conocimiento mucho más detallado y profundo; a lo mejor no conocen todo Spring, pero hay partes que conocen de forma muy detallada. Por tanto, no se trata solo de establecer que alguien tiene “experiencia con Spring” sino cómo es esa experiencia o en qué realmente se tiene experiencia.

El valor de las personas

Buenos y malos. Obviamente, nosotros los buenos y ellos los malos. Los otros son malos. Peores que nosotros. Y encima no tienen salvación posible. Los malos programadores no saben, no se preocupan por saber, nunca van a aprender y la única forma de tratar con ellos es limitar el daño que pueden hacer.

Esto es lo que expresa el párrafo del artículo. Y esto mismo, de forma más o menos clara, con palabras más o menos rebuscadas, más o menos abierta o conscientemente, es la idea que otros muchos repiten.

A veces me llega a sorprender ver la cantidad de gente que se siente con capacidad y autoridad suficiente para presentarse públicamente como mentor o guía para otros2). Me sorprende sobre todo en comparación con la cantidad de gente que cree necesitar esa guía. Está bien creer en nuestra capacidad, está bien querer ayudar, todo eso está bien. Pero a la vez, un poco más de humildad, de humildad de la de verdad, no estaría mal.

Porque esa falta de humildad demasiadas veces -por no decir casi siempre- se transforma en un menosprecio directo a los demás.

Y este, precisamente este, es en mi opinión uno de los primeros detalles que caracterizan a alguien que puede considerarse senior:

Alguien con experiencia real, alguien senior, sabe separar exquisitamente a la persona de su código.

Un programador senior sabe que él/ella mismo/a sigue escribiendo a veces -con una frecuencia indeterminada- código que podría considerarse “malo”. Sabe que los demás también. Y sabe, por encima de todo eso, que producir en un momento dado código que es “malo”… o “mediocre”, o “ni fu ni fa”, o “no óptimo”… no quiere decir que la persona sea “mala”. Y por encima de todo eso, que no se valora a una persona de la misma forma que se puede valorar un estúpido trozo de código.

Y a la vez que sabe esto sobre las personas, sabe también una cosa sobre el código: que existen diferentes formas de valorar lo apropiada que es una cierta solución y que incluso más allá de esa valoración, existen circunstancias y factores que explican por qué ese código se escribió así. Esto no quiere decir que acepte cualquier código como “igual de bueno”. En absoluto, alguien senior entiende -con más o menos detalle- si un cierto código es mejor o peor. Lo que quiere decir es que, incluso viendo un código que considere “malo”, es capaz de entender por qué, en un cierto momento y circunstancia, ese código se escribió así.

Títulos y etiquetas

Por otro lado, llegado a este punto, pienso en lo poco que realmente me importan los títulos y las etiquetas… cuando son usadas como argumento.

Los títulos y las etiquetas demasiadas veces sirven solo para reflejar la carencia de contenido real. Más aún cuanto más sonoro y rimbombante sea. Otras muchas veces, el uso de estos títulos no se debe a esta carencia, sino a eso que comentaba antes: que nos creemos mejores que los demás, que creemos que eso es importante y que debemos hacer ver lo importantes que somos.

Esto quizá sea poco más que una mera anécdota sin valor estadístico, pero los mejores desarrolladores y con mejor experiencia que conozco tienden a describirse de manera más bien sencilla y es habitual que se quiten importancia. Quizá llegaría a decir que ese estereotipo del programador en una oficina oscura y escondida es cierto de un modo metafórico: Los mejores programadores que he conocido tienden realmente a esconderse de la luz… de la luz de los focos y la atención de los demás. Lo que buscan es hacer un buen trabajo y…

Multiplicar a los demás

…colaborar.

Hoy en día es muy poco frecuente trabajar en solitario. No es imposible, pero es poco frecuente. En cuanto un proyecto tiene cierto alcance, se hace inevitable tener que trabajar en equipo.

Y aquí es donde aparece otra de las confusiones habituales. Demasiadas veces se ve el papel del programador senior como alguien que lidera al frente del equipo, muchas veces con títulos como Jefe de Equipo, Arquitecto o similares. Se espera que la persona que ocupa un puesto así sea alguien que tiene más experiencia y que se dedica a decir a otros lo que deben hacer y cómo deben hacerlo.

Pero eso no es un programador senior y lo que hace no es colaborar. Ni siquiera es un líder. Eso es un jefe.

A un programador senior generalmente lo encontrarás en un puesto en el que quizá tenga cierta responsabilidad o autoridad técnica. Pero otras muchas veces no será así, y otras tantas no será de forma oficial o reconocida. Lo que es más habitual es que lo encuentres en una posición muy cercana a la de cualquier otro programador y que, seguramente sin que le veas, se dedique no a decir a otros qué o cómo deben hacer, sino a ayudarles a entender cómo funcionan las cosas. Porque…

Un programador senior sabe que aunque importa que las cosas se hagan de la forma correcta, importa mucho más que se entienda cómo funcionan las cosas y qué implica hacerlas de una forma o de otra.

Y no sólo esto. Si no que sabe que lo importante no es que él mismo lo sepa, sino que todo el equipo lo sepa. Porque tienen muy claro que su capacidad produciendo código es la que es y si se limitan a eso, lo único que pueden conseguir es sumar al progreso del proyecto. Pero saben también que si consiguen mejorar la capacidad de otros además de la suya, lo que estarán haciendo es multiplicar ese progreso.

Más allá de senior

Pero como decía el título es lo de menos. Como mucho es un reconocimiento que otros te dan.

Cuando encuentres a alguien que de verdad tiene la experiencia, que de verdad es senior, lo más probable es que le encuentres3) ayudando a otros a entender y a mejorar simplemente porque saben que eso, a la larga, nos ayuda a todos, más allá de ese proyecto actual.

Pero quizá lo más llamativo, la clave de todo, es que no les verás despreciando a otros por no saber algo. No les verás descartando a alguien -por ejemplo en una entrevista- porque no sabe. O tratando un proyecto como algo exclusivamente suyo y diciendo a los demás que hagan todo como él dice. Les verás, enseñando, explicando y en ocasiones, sí, corrigiendo.

Ah, en fin, debo ir a dar de comer a una gata o algo así… Ya seguiré otro día -o más bien no- con estas reflexiones tan poco productivas.

1)
Mucho se podría decir sobre si realmente son caros o no, pero voy a intentar centrarme en el tema actual
2)
Más aún cuando luego van por ahí proclamando “Ay, ay, cuánto síndrome del impostor tengo!”
3)
aunque quizá necesites prestar un poco de atención extra