TinselCity

Para quien no lo conozca, David Bonilla es… bueno, no sé, a veces diría que es un personaje de la farándula del software. Hace tiempo fue desarrollador, luego ha montado algunos proyectos, y ha trabajado como C?O en alguna empresa, y da charlas, y tiene una “newsletter” semanal sobre… algo, y monta su propia conferencia para gente selecta, y recientemente está metiéndose a trabajar en el mundo de la selección y contratación de desarrolladores.

Clasificando a las personas

Si alguien lee de vez en cuando las tonterías de mi Twitter, verá un buen número de comentarios sobre ofertas que encuentro o recibo, sobre llamadas que me hacen, y sobre entrevistas que tengo. Es un tema que me divierte, me aburre, me sorprende, me fascina, me enfurece, me frustra… Muchos de esos comentarios giran alrededor de gente que no sabe lo que quiere o que no sabe lo que dice. También les ocurre a los propios desarrolladores, claro. Un error frecuente para ambos es el de pretender clasificar a las personas de forma demasiado estricta y específica.

Las taxonomías son para entomólogos

Creo que basta leer la torpe descripción de ahí arriba de “qué” es David, para comprender inmediatamente que clasificar a las personas a base de ponerles una etiquetita en su currículo puede ser bastante complicado.

En meses recientes, dado su actual interés por el asunto, David ha hablado de algunas de estas definiciones. Recuerdo ver por ahí unos tuits en que discutía sobre qué etiqueta(s) asignar a algunos “desarrolladores de front”. Hace no mucho, hablaba de “Juniors y Seniors” sin definir qué significaban para él y metiendo unos ridículos y absurdos números inventados. Ahora habla de “DevOps” pero lo que me interesa es que empieza diciendo:

Como he comentado en otras ocasiones, uno de los principales problemas que estoy encontrado al intentar aproximarme al mundo del recruiting con una perspectiva ingenieril es la inexistencia de una taxonomía común.

Se descubre el pastel. Al menos aparentemente1), David ha caído en el profundo pozo de la clasificación de las personas que, como decía, suele ser uno de los errores más problemáticos de la gente que trabaja en RRHH y selección de personal. Y parece haber caído hasta el fondo, intentando no ya definir algunos términos sino buscando definir una taxonomía completa. Y no solo intenta definir términos, también definir cómo se aplican esos términos. ¿Es “DevOps” un rol? Y por tanto definirá un puesto. ¿O es una habilidad? Y entonces matizará un perfil. ¿O es una técnica? ¿O una metodología? ¿O una actitud? ¿O…?

Inheritance, composition, interfaces, traits...

Son numerosas las discusiones entre “programadores” sobre cuándo y cómo usar herencia, o si se debe favorecer la composición. O cuándo definir interfaces, o porqué los traits son más interesantes2).

A los “programadores” les gusta discutir estas cosas, así en general. Es una discusión fundamentalmente técnica, centrada en entidades que existen directamente en el ámbito de la programación, cosas que hemos inventado nosotros para programar mejor3). Y aún así es difícil. No todo el mundo se pone de acuerdo en todos los detalles, en todos los casos, en todas las sutilezas. Extraer conclusiones que se puedan destilar a solo unas pocas palabras es complicado. Siempre hay excepciones, detalles implícitos, matices. En un trabajo que tuve, algunos compañeros a veces invertían literalmente horas en discusión para intentar establecer nombres y organizaciones adecuadas para los conceptos que manejaban. En ocasiones tenían que aceptar dejar algunas cosas sin aclarar para poder avanzar.

Y aún así, una conclusión bastante extendida es que crear una taxonomía precisa, flexible y correcta, es muy difícil. Ya, no he dicho “imposible” solo “muy difícil” con el “muy” en negrita, pero no en negrita y mayúsculas. Eso, probablemente es uno o dos escalones por debajo de “imposible”, ¿no? Pero, ojo, son muy difíciles así en general. Es decir, el caso típico es muy difícil. Algunos casos son un poco menos difíciles y otros casos son mucho más difíciles.

Cuando se habla de biología, sale siempre el ornitorrinco. Y demasiadas veces pensamos que es un caso, que es la excepción. Pero ni es el único, ni es el problema más importante. Basta revisar un poco la historia para comprender el alcance de la enorme complejidad de crear una taxonomía válida y cómo sigue habiendo modificaciones, arreglos, discusiones incluso hoy en día. Llevamos casi 300 años y todavía hoy se siguen proponiendo modificaciones y arreglos en los grupos básicos fundamentales.

Código. Personas.

Y por otro lado tenemos esa idea que va por ahí rondando todas las cabezas. Ojo, que programar no es necesariamente/exclusivamente/principalmente/etc escribir código sino que tiene mucho de “tratar con personas”. También se dicen otras cosas, claro, pero esta deja claro que “tratar con personas” es diferente a tratar con código.

Sé positivamente que no soy el único4) que ha pasado por diversos intentos de definir en mi currículo qué “título” ponerme. Y eso que cuando lo haces sobre ti mismo juegas con una gran ventaja: Manejas tanto el sujeto -tú mismo- como la definición -lo que tú entiendes por el término-. Pero incluso con esa ventaja, muchos nos vemos con dudas. ¿Cómo resumirnos en un único término? ¿Será este más adecuado que aquel? ¿Se entenderá mejor? ¿Me llamarán con ofertas que se parezcan más a lo que quiero ser y hacer?

Mientras tanto, la gente que maneja ofertas y selecciona “programadores” (así en genérico), insiste en hacer un gran esfuerzo para poner etiquetas en la gente. Me dicen con frecuencia “¿Te definirías frontend o backend?”, o “Buscamos un desarrollador React”, “¿Aquí eras lead programmer?” o el clásico “Estamos buscando a alguien junior5). O el otro día, que me llamó una selectora de esas que le da igual todo mientras digas que sí a las palabras clave que tiene apuntadas y me decía que tenía una oferta para un “arquitecto”. Tras una breve discusión intentando aclarar qué es lo que buscaba, me tuvo que explicar que para ellos senior significaba unos 3-5 años de experiencia y que cuando decían “arquitecto” solo querían decir que tenía más experiencia que un senior.

En fin, yo lo entiendo. De verdad. No lo digo por decir. Entiendo que tratar con personas es complicado. Cada uno tiene su historia, sus matices, sus detalles. Manejar cada perfil en toda (o casi toda) su magnitud y detalle es muy complicado. Lo sé. Y la tarea de encontrar un buen empleado / un buen trabajo que encaje con lo buscado es también muy complicada y todo lo que podamos hacer para hacerla más fácil será bueno.

Pero entiendo también que simplificar demasiado hace perder precisión y cambia el modelo. Y esto lo entiendo también como ingeniero. Cuando simplificas un modelo o un análisis, siempre eres consciente que lo haces a cambio de introducir un cierto error, una cierta pérdida de precisión. Pero no solo debes analizar si ese error es asumible, sino que también debes analizar si con esa simplificación el modelo sigue siendo válido o si ha dejado de serlo. Porque no tiene ningún sentido simplificar un modelo para que sea más fácil de manejar si eso hace que el modelo deje de representar la realidad del problema que queremos solucionar. Un modelo simple pero irreal no nos servirá para solucionar problemas reales, no ya por errores de aproximación, sino porque hemos simplificado tanto que el modelo ya no es aplicable, ya no concuerda con la realidad.

En este caso, tratar de crear una taxonomía para clasificar las habilidades, experiencias, capacidades, valores de los “programadores”, es tratar de crear un modelo que no representa la realidad correctamente. Y no solo por la pérdida de precisión a la hora de representar a las personas, no. También porque tampoco tenemos una definición común y estable para muchos de los términos implicados, y porque muchos de esos términos nos los vamos inventando sobre la marcha.

"καὶ σὺ, τέκνον"

Tampoco es que sea esto la puñalada de Bruto, no, pero de algún modo… No sé, después de años de ver estas cosas en nuestra industria, de ser tratado como carne con etiquetas de calidad arbitrarias, me produce cierta tristeza ver que alguien, que supuestamente debería conocer mejor la profesión y a los profesionales, caiga de boca incluso antes de empezar en los mismos errores.

Diría que incluso me preocupa6) porque en este caso es alguien que tiene una posición con una influencia perceptible en ciertos círculos de la industria. A unos les gustará y a otros no, pero es difícil discutir que su voz tiene un alcance mayor que el de otras voces. Y temo que esa influencia, ahora hablando sobre etiquetar a la gente de una forma u otra, en otras ocasiones hablando sobre qué salarios son “esperables” o no, etc, no es una influencia demasiado positiva.

Oh, en fin…

1)
Por ahora habrá que otorgarle el beneficio de la duda
2)
o no
3)
Para un cierto valor de “mejor”
4)
Sería ridículo por mi parte pensar otra cosa, claro
5)
para decir, “queremos pagar una mierda” o similar
6)
Todo lo que me pueden preocupar ahora las cosas, que es prácticamente nada dado que ya he asumido que estoy más fuera de la profesión que dentro.