Llevo 35 años entre teclados y ordenadores. Muchos años. Un cúmulo de experiencias y miles de horas pensando, resolviendo, aplicando predicciones, controlando errores… bien, esa es la vida del programador. En estas últimas décadas todo ha cambiado, no se si a mejor, pero ha cambiado, y mucho. Cuando empecé a programar en serio, usando el lenguaje COBOL, tenías tiempo para aprender un lenguaje hasta los apéndices de su manual. Tenías la posibilidad de dominarlo, de convertirte en experto. La próxima versión no aparecería hasta 5 o más años después. Aún así, algunas veces nos perdíamos en la espesura y los mensajes de error crípticos. Y pasó el tiempo, hasta llegar a Internet, la WWW, el mobile… un cúmulo de plataformas nuevas, distintas, con lenguajes y paradigmas diferentes a todo lo anterior. La nube se nos apoderó. De todos. Hoy día es difícil encontrar una aplicación «de escritorio» en lugar de su contrapartida en versión web. En suma, la cantidad de lenguajes, plataformas, arquitecturas y conceptos que manejamos los profesionales del sector es, cuando menos, abrumador.
Me atrevo a postular que hoy día nadie puede alzarse con la etiqueta de «experto» en nada relacionado con la programación. Es imposible. Nadie puede dominar ni un solo lenguaje antes de que aparezca una nueva versión, que con suerte deja obsoleta la anterior o peor, antes de que sea sustituído por un nuevo lenguaje «más rapido», «más fácil», «más seguro»… Así pues todos llegamos a ser mediocres, en mayor o menor grado, pero mediocres. No hay tiempo físico disponible para leerse tomos de mil páginas y, aún menos, asimilarlos para poder aplicarlos. Así son las ciencias de la computación hoy día. Tienes que poder tratar con muchas opciones a la vez, intentar jugar bien con ellas, que combinen lo suficiente como para que el resultado sea, al menos, decente.
El Agilismo parece la solución final, la panacea. Y muchos quizás no sepan que el Agile Manifesto tiene más de 20 años de antigüedad… (publicado en 2001, lo tienes más abajo). Ahora es cuando hay que aplicarlo si o si, a ultranza y sin pensar en otra cosa, y recuerdo que la programación paralela casi me cuesta el puesto de trabajo por allá los inicios de los 2000. Bien, está bien que se quiera poner orden en algo tan caótico como la programación, más cuando ésta se realiza en equipo y cada cual tiene sus criterios y sus formas de hacer las cosas, sus manías y sus genialidades. Pero el Agilismo nos deja encima de la mesa una colección de términos y siglas, tales como DDD, TDD, SOLID, buenas prácticas, programación extrema, programación paralela, etc. que, cuando veo una oferta de trabajo y las contempla todas como requisitos fundamentales, además de media docena de lenguajes de programación, unos cuantos frameworks, tres o cuatro sistema de bases de datos y un largo etcétera de cosas más, me pregunto quién redacta esas ofertas y en qué está pensando, o mejor, en quién piensa que puede haber abarcado tal cantidad de tecnología aplicada en un periodo de tiempo razonablemente corto.
Nadie.
Tal como he dicho, la mediocridad nos impide ser expertos en conceptos tales como el Domain-Driven Design, las Unit Tests, los principios SOLID, las buenas prácticas de tal o cual lenguaje, la administración del sistema operativo, la conectividad con sabe nadie qué redes, colas, bases de datos y sistemas alienígenas remotos, y además, dominar cinco o seis lenguajes de programación hasta la excelencia última. Y no sigo añadiendo más cosas, porque la idea está clara, ¿cierto?
Dejando a un lado que alguien pueda conseguir una puntuación de 10 sobre 10 en todo lo anterior (excepciones las hay en todo, cómo no), ¿no sería mejor intentar ponderar cada uno de estos conocimientos según su impacto en el puesto de trabajo, y en el trabajo en sí, para valorar a un candidato de una forma más equitativa y precisa?
Pongo por caso que saber programar con un lenguaje orientado a objetos tiene más valor que con un lenguaje que no lo está. O que es más valorable un lenguaje de programación de aplicaciones que uno orientado a scripts (aunque eso dependa del puesto de trabajo). ¿Es mejor saber usar WordPress o Joomla? ¿Y administrarlos? ¿Y programar plugins para los mismos? Ah, plugins. ¿Qué es eso? No voy a seguir añadiendo palabrotas y siglas… pero así es como las ofertas de trabajo aparecen. «Se requiere PHP, Java, C#, .NET, SQL, TDD, DDD, SOLID, SCRUM…..»… ¿en serio? Muchas de esas listas incluso son contradictorias… y vuelvo a lo anterior: darle un peso, una puntuación a cada palabra, a cada requisito, a cada aptitud, y entonces quizás los filtros sean más precisos y cumplir 3 de 8 aptitudes, según nuestros perfiles, no sea tan malo, ni cumplir 9 de 10 sea tan bueno.
Hace algún tiempo un usuario de un canal de chat sobre programación, en general, preguntaba dónde podía encontrar un libro, un tutorial, una guía sobre cómo programar, así en general. Buena pregunta. Porque al fin y al cabo programar no es más que plasmar un proceso que, en primera instancia, hay que pensar. Y eso nunca se pide como requisito, saber pensar y resolver un problema, convertirlo en uno o más procesos, y luego plasmar esos procesos en programación. Esa compentencia parece darse por sentada, como si todos los programadores pensaran de la misma forma, con la misma velocidad y precisión, con la misma elegancia y solución para un mismo problema o situación.
Si has llegado hasta aquí y eres recruiter, habrás visto que no es sencillo valorar a un profesional a base de listas de términos. Hay mucho más detrás de cada uno de ellos, y más allá, hay una persona que aplica todos esos conocimientos, tenga muchos o pocos o distintos, para enfrentar cada problemática a su manera, con la mayor eficacia y eficiencia posibles.
Estoy pensando en dejar la programación y pasar a reclutar personal IT. En serio. Muy en serio.
Principios del Manifiesto Ágil
Seguimos estos principios:
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.
Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al
cliente.
Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.
Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.
Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
El software funcionando es la medida principal de
progreso.
Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.
La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
