Recuerdo con mucho aprecio una anécdota del dueño de alguna empresa donde trabaje. Me contaba que, en uno de sus tantos viajes, alguien con quien estaba charlando definió a los desarrolladores como “La última clase proletaria”, haciéndome notar el elefante rosa en la habitación. Esto me llevó a analizar y comparar nuestra industria de IT con otras industrias así como con la vida misma, pues todos comenzamos nuestra vida siendo pequeños y con el tiempo vamos creciendo hasta volvernos adultos.
La palabra seniority viene del Medieval Latin seniōritās y entre otras traducciones la más acertada para el tema que quiero acotar es: “el estatus obtenido como resultado de cierto tiempo de servicio”. Hasta hace unos pocos años e incluso en algunas compañías hoy en día se sigue midiendo el seniority basado en dicha definición, pero en mi experiencia esto ya hace tiempo que no indica el verdadero “seniority”.
Tengo la dicha de conocer y tener muy buena relación con personas que trabajan en distintos equipos de HHRR en la industria de IT; al conversar sobre este tema se puede ver como cada empresa tiene una definición diferente. Algunos hacen una mezcla entre la cantidad de años y las habilidades, otros directamente tratan de medir de acuerdo a estándares de calidad y conocimiento técnico, otros toman en consideración la cantidad herramientas utilizadas e incluso existen algunos en esta industria que solo toman la cantidad de años por herramienta (de aca derivan muchos chistes de exigencias absurdas en años de uso de X herramienta que solo tiene meses de haber sido publicada). El último ejemplo nos deja entonces casos en los cuales se obtiene un seniority por herramienta y probablemente otro general.
Esto en mi mente siempre ha hecho ruido; empecemos por el principio: ¿cómo es posible que mis capacidades y la de mis colegas se definan por cantidad de horas frente al teclado, cuando ya muchos cuentan con pregrados e incluso postgrados?. Por suerte, esto viene cayendo por su propio peso.
Existe en el ecosistema IT un sinfín de herramientas y librerías de las cuales algunas seguramente son más que conocidas, unas olvidadas y otras cayendo en el olvido; cada una de estas ha venido a este mundo a resolver un problema puntual pero ¿que pasa si en mi experiencia no tuve un problema como ese?. Quizás pude solucionar sin esa herramienta, o tal vez me gustó tanto un lenguaje que no tuve la necesidad de aprender otro. Esto ciertamente acota nuestro alcance pero ¿nos reduce las capacidades de resolver un problema? Yo creo que no, pues los lenguajes y herramientas de programación por muy diferentes que puedan aparentar (sintaxis, paradigmas, procesos, entre otras diferencias), siguen teniendo la misma base.
Cada profesional recorre su propio camino, esto va dejando diferentes aprendizajes, no podemos negar que las capacidades particulares son importantes y nuestra historia tiene valor si la sabemos aprovechar, no somos un compendio de habilidades aisladas como muchos quieren hacernos ver. Nuestro conocimiento es muchas veces extrapolable o en el peor de los casos facilita el aprendizaje nuevo. Me parece un poco incongruente que muchas veces se rechacen profesionales por no tener suficiente experiencia en X o Y herramienta en particular, cuando lo más complejo ya lo maneja (además de que IT es una carrera que nos impulsa a mantenernos estudiando, y no representa un reto mayor aprender una herramienta nueva).
Creo que la demanda tan alta de profesionales (y la baja disponibilidad) en la industria ha llevado a muchas compañías a buscar estándares aproximados, para así definir e ir midiendo al ojo porciento y acertar con eso que están necesitando. La vorágine de esta industria no nos permite ver los matices en esa variedad de profesionales con valiosos aportes en diferentes ámbitos del desarrollo de software; es más fácil que un cuadrado encaje donde estaba otro cuadrado. Pero si al contrario logramos detenernos a ver que tenemos y que nos hace falta podría generarse una dinámica diferente y mucho más enriquecedora.
Me siento más a gusto si pienso en el seniority tomando en cuenta las capacidades desarrolladas a lo largo de cada experiencia, pues considero que el tiempo no es del todo verosímil en esta carrera; sí creo que la capacidad de diseñar y crear soluciones es una pieza imprescindible para un desarrollador avanzado. Para los que están en un nivel intermedio, pienso que es primordial tener sólidos conocimientos sobre el desarrollo de software no solo sobre una herramienta en particular. En mi opinión el inicio de esta industria suele ser por uno de dos caminos: conociendo una herramienta en particular con poca teoría en desarrollo de software o por el contrario con buena teoría pero sin buena base en una herramienta.
Me cuesta mucho trabajo encasillarme y muchas veces me resulta un poco sorprendente cómo muchos se auto definen con uno u otro seniority (claramente algunos los pavonean más que otros) pero lo que realmente me impacta es la verticalidad con la que se pretende tomar esto, como si fuese una especie de rango militar teniendo más o menos razón en tus intervenciones de acuerdo al nivel que te han asignado.
Somos personas con fortalezas y debilidades, no debemos auto imponernos una etiqueta que “defina” nuestro conocimiento, pues podemos y debemos sentirnos a gusto con nuestras capacidades, creo que ponerlas dentro de una caja no es el camino correcto.
Top comments (0)