Lo que voy a escribir hoy en este post para 9punto5 es un tema controversial. Varios concuerdan y a la vez muchos están en desacuerdo con esta definición. Pero a pesar de estas diferencias es un hecho que una amplia cantidad de empresas utilizan la distinción entre niveles de “seniority” al momento de buscar talento.

Esta definición ha ido mutando aún más a través de los años, donde la tecnología y acceso a la información se ha vuelto esencial para adquirir conocimiento. Ya no es necesario estudiar años una carrera, para llamarte informático o “developer”.

Youtube, Twitter y LinkedIn son las nuevas universidades. Por solo 10 dólares americanos puedes estudiar en Udemy, y salir 5 horas después con conocimientos de una persona, que vive al otro lado del planeta.

Por un poco más de dinero, puedes comprar apps y software pre-hecho para posteriormente ajustarlo a tus necesidades. Github es el universo del open source donde puedes elegir el código para incluirlo en tu nuevo proyecto.

Estudié 6 años una carrera para hacerme llamar “Ingeniero Civil Informático”. En ese momento, decían que era la carrera del futuro y cuando comencé a ejercer, pensé que mis conocimientos iban en sintonía con la realidad de ser desarrollador.

Estudiar 6 años una carrera, en el año 2020, puede sonar iluso. Carreras basadas fuertemente en lo académico, con hasta 4 ramos consecutivos de matemática y física avanzada, programación y/o modelos de software se podrían considerar obsoletos en esta nueva década.

Las cosas han cambiado drásticamente en términos de que debe hacer un desarrollador de software. Ya no basta con solo saber un lenguaje de programación, haber participado en mínimo 5 proyectos, o tener “bonus points” por tener experiencia y saber de uno o varios sistemas “legacy”.

Si empezaste tu carrera en el mundo del software y la tecnología, alrededor de esta fecha, verás que existen ciertas expectativas aparte de las técnicas. Diversidad, tolerancia e interculturalidad, son algunas como ejemplo.

Yendo al tema en cuestión de “seniority”, en mi experiencia, existen al menos 5 niveles de desarrollador, que además se complementan con más dimensiones como el tipo de liderazgo, capacidad de coordinar procesos y su conexión con la comunidad.

No creo simplemente en un título como “Senior Software Engineer”. Si lo vemos más a fondo, un dev se mide en muchas más capacidades y puede ir y volver en distintos caminos.

La lista que describiré a continuación no es un camino secuencial con un fin. Es un constante ir y venir entre tecnologías, liderazgo, multiples tipos de proyectos, descubrir intereses y generar impacto social. Yo alguna vez me he llamado “Senior Backend en PHP” para un año después convertirme en un “Junior React Native”.

Junior Dev

Vamos al más simple de explicar. Un “junior dev” es una persona con nula o muy poca experiencia desarrollando. La mayoría del tiempo debe ser guiado o guiada para conocer procesos e implementar buenas prácticas. Su código necesita de constante revisión y su habilidad de comunicación es muy limitada.

Acá es bueno detenerse para hablar de la comunicación. Es una habilidad imprescindible que nadie enseña. Ya hubiera querido en “la U” que me hubiesen enseñado a escribir y escuchar mejor (¿les suena esta habilidad para el trabajo remoto?). Un “junior” con esta habilidad desarrollada tiene mucha cancha avanzada para tener éxito en un grupo o proyecto.

Mid-Senior o Intermediate Dev

Podríamos decir que el “Intermediate” es el dev que ya tiene 2 o 3 años de experiencia y que puede tomar tareas más complejas. Domina muy bien un “stack” (en fácil llámese “stack” a un lenguaje, tecnología, o conjunto de las anteriores). Es posible además, que pueda ayudar a aprender a un “junior”.

Del punto de vista del código, tiene las habilidades para realizar comentarios a un “pull request” y explicar algunas funciones e incluso ciertos patrones de arquitectura.

En base a mis proyectos del pasado, el “Intermediate” es el que copia/pega código de StackOverflow y algunas veces se queda corto con la explicación de que hace ese código. O sea, no existe una capacidad madura de discernir porque estoy añadiendo más líneas y/o como impactan a otras áreas del mismo software.

En resumen, ¿cuáles a mi parecer son las habilidades esenciales a empezar a aprender en este nivel? Tres principalmente.

• Responsabilidad y/o ownership. Te gradúas de “Intermediate” cuando eres el principal responsable de una parte de un proyecto y eres capaz de ejecutar ciertas tareas sin la necesidad de una dirección clara. Algunas veces incluso, ambigua.
• La capacidad de manejo de emociones en un proyecto. Frustración, ansiedad, enojo deben ser contrastadas con paciencia y humildad.
• Opinión madura en al menos un área de código fuente. Puede ser arquitectura, estilos, patrones, entre otras.

Senior Dev

Ahora me meto en territorio complicado. ¿Qué nos hace ser seniors en software?

Por favor, no pienses que es solamente ser experto y literato en un lenguaje o framework. No pienses que es “codear” problemas complejos que nadie más los puede hacer, o que alguien necesita logros increíbles para pertenecer a tu equipo de desarrollo.

Si bien podemos concordar que un senior puede tomar decisiones en un equipo, elegir “el stack”, levantar ambientes de desarrollo, realizar un “deploy”, y últimamente dar la visión de como debe ser el desarrollo de un proyecto, también en este nivel se pueden notar bifurcaciones o distintos estilos en la carrera de un desarrollador.

¿A qué me refiero con eso? Que hay algunos devs que se convierten en líderes de equipo, y otros en “tech leads” . La diferencia es que los primeros ahondan en “soft skills” y los últimos en “hard skills”. Los dos caminos son válidos y necesarios.

Independiente del camino, existen ciertas habilidades del futuro que nadie me contó, y a las cuales debí haberle puesto más atención para ser “Senior” (escribí esto en mi blog hace un tiempo).

• “Olvidar” lo que has aprendido. Después de 5–7 años de desarrollo, olvídate de todo lo que aprendiste. Es fácil a esta altura tener verdades, estilos y hábitos que son difíciles de cambiar. Para mi, esto decanta en que un senior siempre debe tener una actitud de curiosidad y cuestionamiento hacia lo que hace.
• Comunicarse de forma simple. A menos que trabajes solo, deberás comunicarte con más personas. Un “Senior” debe “encender” la comunicación . Sentirse cómodo con la ambigüedad y encontrar el balance entre lo simple y lo complejo. En este punto, clarificar que la comunicación también implica escuchar a los demás, no solo ser escuchado.
• Crear un estilo de liderazgo centrado y descentralizado. Dejar que otros opinen y que fallen. Y como si esto fuera poco, dejar las expectativas y buenas prácticas claras.

Tech Lead

Un “Tech Lead” es un “Senior” con bonus en manejo de proyectos y entendimiento de reglas de negocio. Vas a llegar a un momento donde deberás entender porque un “feature” la dejaste en el “backlog” y estás codeando un “fix” que a nadie le importa.

En este tipo de cargo, existen ciertas consideraciones que debes diariamente, y que por ello tu tiempo se vuelve más demandado. Un “Tech Lead” pasa más tiempo conversando, comunicándose, en reuniones y generando documentación, en vez de programar.

¿Otras diferencias esenciales con el “Senior”?

• Es el principal ejemplo (no el único) a seguir en un equipo. No solo técnicamente, si no también en términos de responsabilidad y ownership.
• Como mencioné al inicio de esta sección, es capaz de entender información y procesos de distintos dominos (diseño, UX, negocio y marketing). Al entender esto, es capaz de traducirlo a su dominio y cómo impacta en el desarrollo de software.
• Crea un estándar profesional de buenas prácticas y procesos en un proyecto. Y en los casos más extremos, incluso para una empresa.

Engineering Manager

Este rol puede ser llamado “CTO” también y no necesariamente es una evolución directa del “Tech Lead”. Por ejemplo, si te vas a un startup y eres el único empleado, ya eres el “CTO”. Y eso hace que desarrolles habilidades de “manager” más rápido. O de “Senior” también podrías tener bastante camino recorrido para manejar un proyecto desde el punto de vista de un gerente o “manager”.

Pero vamos a los ejemplos concretos.

Yo veo a un manager en el ámbito del software como un diseñador de procesos, directo colaborador de la cultura de una empresa y principal motivador de los procesos de ingeniería o de desarrollo. Dígase estos como: contratación, políticas de mantenimiento de código, procesos de automatización y deployment de software, entre otras muchas más.

Este manager también debe ser capaz de entender motivación y deseos de su equipo. Cuales son las fortalezas y debilidades de cada miembro para así estructurar equipos que sean existosos. Esta característica dista de lo que otros puedan pensar. Por ejemplo, el “CTO” algunas veces es visto (en el ámbito “startup” principalmente) como la única persona que hace tecnología. Codea, lanza nuevas features y continua en ese loop.

Si bien eso es posible y mantenible en el corto plazo, un manager debe si o si tener “soft skills”, manejo de emociones, mucha paciencia y humildad. Sin por supuesto, dejar de lado lo técnico.

En este punto, el código fuente pasa a segundo plano y ya no es necesario revisar línea por línea. Un manager efectivo debería aspirar, a por ejemplo, crear un proceso automatizado de “pull request” que evalúe el código y le da una primera impresión sin tener que ir línea por línea.

Por último, un manager se interesa por la calidad del software. Esto lo he visto configurado de distintas maneras. Puede ser un departamento de QA, procesos de DevOps e implementación de pruebas automatizadas para estar siempre midiendo como el software se está portando.

Tener liderazgo sin ser jefe

Por último, esto ya es tema para otro post, pero de forma breve se puede agregar, que aunque esto no se ve mucho en Chile o Latinoamérica, existen empresas que valoran tener personas muy competentes que profundizan sus conocimientos y los difunden en la organización y el ecosistema, que pueden desarrollar su carrera sin necesariamente llegar a ser “managers”.

Puedes tener mucha relevancia en la compañía, tener mucha influencia y liderazgo sin ser jefe. Algo de esto mencionó Felipe Hoffa, quien trabaja en Google, al final de esta entrevista.

Agradecimientos

Muchas gracias a Jonathan Gonzalez y Fabián por los aportes a este post.

Sigamos la conversación

En Twitter: @nerdfromchile / @9punto5_