Loading posts...
Loading posts...
Buenas a todos. Este artículo nace a partir de una conversación que tuve con un amigo mío, gran ingeniero de software, que fue mi mentor cuando recién comencé a escribir un poco de código. Yo ya estoy formalmente en la industria más de 9 años, mi amigo lleva mucho más, y hace tiempo que no conversábamos.
Aprovechamos de ponernos al día un poco en lo que estaba haciendo cada uno, y fuimos divagando, hablando de generalidades. El auge de la IA, la baja demanda de devs juniors, etc.
Opinando muy al aire sobre mi postura acerca de varios temas, me surgió la idea de compartir mis pensamientos con ustedes como lectores, sobre algo que me quedó dando vueltas en la cabeza luego de la conversación: ¿Qué significa ser un desarrollador senior?
Si vienes buscando que te diga un axioma, nah, eso jamás. Nunca me he confiado en alguien que me diga "esto es así". Me da igual que tenga argumentos sólidos. Creo que en la ciencia como tal, dar por verdad un hecho sin cuestionarlo es un error.
Ahora bien, no me confundan con un conspiranoico, no. Tengo un poco de dignidad jajaja. Pero sí creo que cuestionar las cosas te hace aprender realmente y tomar una postura sólida. Esto que digo es aplicable a todo en la vida, e incluso puede ser algo que vaya más a lo filosófico.
En fin, acá estamos para cuestionar qué es ser un senior y eso es lo que haremos.
Aclaración: Yo no me voy a meter con ninguna industria/rubro/oficio que no conozco. Si estás acá, es porque quieres leer una opinión de alguien que trabaja en la industria IT, específicamente desarrollo de software. Así que todo lo que leerás a continuación está enfocado en este rubro.
La definición del diccionario de la RAE es la siguiente:
Superior en categoría y experiencia a quienes desempeñan la misma profesión o cargo.
Desde la base, tiene mucho sentido. La pregunta acá entonces se transforma en: ¿Cómo mido si soy superior en categoría y experiencia a otros desarrolladores?
Siempre que queremos medir algo, necesitamos un patrón de referencia. En este caso, el patrón de referencia son otros profesionales del mismo rubro.
¿Con quién nos medimos entonces? ¿Con todos los desarrolladores del mundo? ¿Con los que trabajan en mi país? ¿Con los que trabajan en mi empresa? ¿Con los que trabajan en mi equipo? ¿Con gurús de redes sociales?
La respuesta no es sencilla y depende mucho de tu entorno. Si estás en un mal clima laboral, quizás no es sano para ti medirte con tus colegas, considerando que probablemente exista un sesgo. Esto aplica a la inversa igualmente: si estás en un equipo que te hace sentir muy cómodo y apoyado, quizás medirte con ellos te haga sentir que eres mejor de lo que realmente eres.
Dudo mucho que alguien no haya caído en este sesgo. Básicamente, el efecto Dunning-Kruger es un sesgo cognitivo que hace que las personas con baja habilidad en una tarea sobreestimen su habilidad, mientras que las personas con alta habilidad tienden a subestimar su competencia.
¿Cuándo es fácil que caigamos en eso?
Cuando sentimos que aprendimos algo nuevo, pero no desde la base misma. Por ejemplo, estuviste 1 año aprendiendo un path específico de frontend: aprendiste React, TypeScript, Next.js, TailwindCSS, etc. Hiciste proyectos personales, quizás un par de proyectos freelance, y te sientes muy cómodo con esas tecnologías. Fue un año intenso, muchos proyectos, muchas ideas, mucho código escrito.
La dopamina es inmediata. Te sientes bien porque en 1 año logras destacar, incluso frente a tus pares que llevan más tiempo que tú. Atribuyes tu éxito a algo propiamente tuyo y probablemente tienes un poco de razón.
Al sobrestimar tus habilidades e impresionar a algunas personas, recibes un ascenso, te sientes reconocido. Es acá donde se comienza a desmoronar la realidad.
Aprovechan que eres bueno en lo que haces y te asignan algo que nunca habías hecho en tu path de aprendizaje. Te proponen (por ejemplo) que diseñes una solución desde cero. Claro, no le tomas el peso a lo que significa hacer algo desde cero: creas un repositorio, tomas lo que sabes, ordenas un poquito las ideas y comienzas a escribir código.
Una vez que te toca mostrar tu diseño, te das cuenta de que en realidad no diseñaste nada.
Esto golpea fuerte, pero también, si lo tomas del lado amable, este golpe de realidad realmente te hizo subir un nivel. Cuando te das cuenta de que no sabes nada, comienzas a aprender de verdad.
En tus primeros años de experiencia, tu trabajo será más o menos simple. Te darán un requerimiento, lo revisas, haces consultas (y espero que hagas consultas), ejecutas, te toma tiempo pero lo logras.
Esto responde a la premisa del qué, peeeero a medias. Digamos que este "qué" es más desde la perspectiva operativa. Pero el qué real puede ser un poco más profundo.
Realmente el qué responde a la necesidad del negocio, y más aún, a resolver una necesidad que responde a una inversión de tiempo y dinero.
Esto no es evidente a simple vista. De hecho, es probable que incluso con bastante experiencia en tu cuerpo, nunca te haya tocado sentarte con un cliente para entender QUÉ es lo que realmente necesita.
Esta pregunta está muy ligada a la primera, pero tiene matices diferentes. El por qué responde a la justificación de la necesidad del negocio.
Entender el por qué te permite comprender el contexto en el que se desarrolla el proyecto. Te ayuda a entender las prioridades, los riesgos y las oportunidades.
¡RIESGOS! Un muy buen punto. ¿Sabes medir un riesgo? ¿Sabes mitigar el riesgo? ¿Sabes comunicar un riesgo? Te puedo asegurar que una persona que se considera senior debe saber atender riesgos.
Cuando haces frente a riesgos, puedes priorizar, planificar, comunicar, y lo más importante (en mi opinión): DELEGAR.
Sí, un senior debe saber delegar. No puedes hacerlo todo tú solo, y si lo haces, probablemente estés haciendo mal tu trabajo.
Aunque no lo parezca, el cómo tiende a ser lo más sencillo de un proceso. Por lo general está ligado a la implementación técnica del requerimiento en cuestión.
Acá puedes estar cuestionando este punto, pero en base a lo que he observado a mi alrededor, cuando sientes que implementar una solución es lo más difícil, es muy probable que no te haya tocado enfrentar un problema real de negocio. En síntesis, si para tu día a día el cómo es lo más difícil, es probable que no estés haciendo el trabajo de un senior.
Un senior debe entender qué entrega y qué no entrega valor. Definir el valor de algo es el conjunto de las preguntas anteriores. Martin Fowler es conocido por su aporte a la industria desde una arista más comunicacional. Podemos dedicar un artículo hablando un poco sobre él. Pero encontré un par de puntos interesantes que quiero compartir con ustedes (voy a parafrasear):
El valor de una característica no está en su complejidad técnica, sino en su capacidad para resolver un problema real del usuario.
La arquitectura resuelve lo importante, la arquitectura mitiga riesgos, no es un fin en sí misma.
¿Entiendes el contexto del negocio en el cual trabajas? Si honestamente tu respuesta es no, probablemente te falta un poco para ser un senior.
Una persona senior no toma tareas, se hace responsable de ellas. Normalmente un senior tiene que enfrentar muchísimas situaciones en donde falla, es él mismo quien debe hacerse cargo de esos fracasos.
Cuando a ti te asignan cualquier trabajo y tú aceptas, tú eres responsable de ese trabajo. Acá muchas veces colocamos de excusa: "la persona X no terminó lo que debía hacer, por lo tanto, no pude avanzar con mi parte".
¿Qué hiciste tú para mitigar ese riesgo? ¿Le preguntaste a la persona X si necesitaba ayuda? ¿Le ofreciste tu apoyo? ¿Le diste un deadline claro? ¿Le comunicaste al equipo que dependías de esa tarea para avanzar con la tuya? ¿Levantaste la mano advirtiendo tu situación?
Es difícil a veces aceptar que, incluso cuando tienes algo que depende de otra persona, sigues siendo tú el responsable.
Uncle Bob lo dice muy claro en su libro "The Clean Coder":
Un profesional asume la responsabilidad total de su trabajo, incluyendo los errores y fracasos. No busca excusas ni culpa a otros por sus propios errores.
Y bueno, es un libro del cual me gustaría hablar en un tiempo más, porque la verdad, tengo una suerte de amor-odio con su relato.
Un senior sabe cuándo decir que no. No es un tema de ego ni de soberbia, es un tema de responsabilidad.
De hecho, también Uncle Bob lo menciona en el mismo libro:
Decir 'no' es una habilidad esencial para un profesional. Significa reconocer los límites de su capacidad y proteger la calidad de su trabajo.
De hecho, no recuerdo las palabras exactas, pero era algo así como "Si no sabes decir que no, entonces NO ERES UN PROFESIONAL".
Ouch, golpe al ego. La crítica a la profesionalidad es fuerte. No comulgo con muchas de las cosas que plantea Uncle Bob, pero será tema para otro artículo.
Si nos ponemos más del lado de "Policía bueno", decir que no tiene que ir acompañado de una contrapropuesta. Cuando dices que no, es porque tienes algo más en mente. Decir no sin más te vuelve incompetente en lo que solicitaron.
Ahora bien, hay un timing para decir que no. Cuando te solicitan algo, tu respuesta debería estar más acorde a:
Dame un momento para analizar bien lo que necesitas, te contacto cuando tenga una propuesta en mente.
En este punto es clave cuestionar lo que te piden y analizar el valor real de lo que te están solicitando (estamos haciendo conexiones ¡Bien!).
Decir que no es experiencia pura. El saber cómo decir que no, a quién le dices que no, y cuándo decir que no, es lo que te hace senior.
Para dar un cierre a este punto, quiero que te quedes con algo en mente:
Decir que NO es un acto de profunda responsabilidad.
La humildad es algo transversal a cualquier tipo de profesión u oficio. Créeme que la persona que expresa cuando no sabe algo, pero llega en un tiempo razonable con la respuesta a lo que desconoce, es mucho más valiosa que la persona que pretende saberlo todo.
Acá entra lo de Dunning-Kruger nuevamente. La humildad te permite reconocer tus limitaciones y buscar ayuda cuando la necesitas.
Creer que un senior lo sabe todo es terrible. Como se dice acá en mi país: Es un disparo a las patas.
Te vas a jubilar sin saber muchísimas cosas. Cuando tengas claro esto, estarás un paso más cerca de ser un senior.
Hemos mencionado varias veces la comunicación en este artículo, y es que es fundamental. Un senior debe saber comunicar sus ideas, sus problemas, sus soluciones. Pero más allá de eso, un senior debe saber escuchar.
Un senior debe estar interiorizado con su entorno de trabajo: escuchar dolencias, entender problemas personales, ofrecer ayuda. Una persona que se mantiene al margen en lo humano con su equipo que lo rodea, difícilmente puede ser un buen senior.
Creer que el trabajo de la sanidad del equipo responde a cargos como "People Manager", "Project Manager" o "Scrum Master" es un error. Todos somos responsables del bienestar del equipo, y un senior debe liderar con el ejemplo.
Tú, sí, tú, eres responsable del bienestar de tu equipo. Tu actitud debe siempre estar enfocada en el bienestar colectivo. Si tratas de aplicar esto en tu día a día, estarás un paso más cerca de ser un senior.
Un senior, por definición, debe ser un mentor. Para mí no hay discusión en esto. Un senior debe tener el deseo de transmitir lo que sabe. Transmitir tus conocimientos provoca muchos impactos positivos, y aunque no lo creas, enseñar a tu equipo entrega muchísimo valor al negocio.
Ahora, si vas a enseñar, hazlo bien. No es cuestión de sentarte con alguien y decirle "Mira, esto es así porque sí". Enseñar es guiar el aprendizaje, orientar a buscar respuestas, fomentar la curiosidad, situar en contextos legibles y reales.
¿Quieres enseñar Python a un practicante? Pregunta antes qué es lo que sabe, qué ha hecho, sus gustos, sus intereses. No todos aprenden igual, no todos tienen las mismas motivaciones. Un senior debe saber adaptar su enseñanza a la persona que tiene enfrente.
Si quieres ser senior, comienza a enseñar, y mientras enseñas, ¡aprende tú también!
Esto ya es una opinión personal: no existe una doble implicancia entre la edad y el seniority. Una persona mayor no necesariamente es senior. Pero un senior, muy probablemente, es alguien mayor.
Y acá dejo la crítica abierta. Cuando lees ofertas laborales buscando seniors y luego revisas la descripción del empleo y te topas con algo como esto:
Se busca desarrollador senior con 5 años de experiencia en React, TypeScript, Next.js, TailwindCSS, GraphQL, Docker, Kubernetes, AWS, CI/CD, Microfrontends, Module Federation, WebAssembly y Machine Learning (y todo el churro de tecnologías que se le ocurra al redactor de turno).
¿Están buscando a un senior realmente?
Me tomaré la libertad de hablar por mí mismo. Yo no estoy ni cerca de serlo. En el contexto de dominio de tecnologías y en base a la descripción de una oferta laboral genérica, probablemente sí lo "soy". Pero una oferta laboral que busque perfiles de personas donde la descripción del empleo aborda los puntos que hemos conversado en este artículo, es imposible que yo califique para ese puesto.
¿Y tú? ¿Eres un senior? Tómate un tiempo para reflexionar un poco sobre tu etapa profesional.
Lo más importante de todo, crecer realmente, es partir siendo honesto contigo mismo.
Te invito a dejar tus comentarios donde sea que leas este artículo, me encantaría conocer tu opinión al respecto.
¡Nos vemos!