junior-senior-main

El rol de un ingeniero senior

Esta entrada es una traducción humana del artículo de Matt Briggs en el que define los roles de todo ingeniero: junior, intermedio y senior. Me parecieron unas reflexiones brillantes y he pensado que sería buena idea hacerla llegar a la audiencia castellano parlante.

This entry is a human translation of Matt Briggs’ post in which he defines the different roles of an engineer: junior, intermediate and senior. I felt these were very interesting reflections and I thought it could be a good idea to make it reachable to all spanish speaking audience. 


Trabajamos en un sector peculiar. Hay mucha más demanda de desarrolladores de la que puede quedar satisfecha por los nuevos ingenieros que llegan al sector. Este problema ha existido durante años y va a peor conforme pasa el tiempo.

Sufrimos una grave falta de talento para poder cubrir la demanda a pesar de que nuestra industria es muy joven. La mayoría de proyectos de software fracasan y prácticamente todos ellos se pasan de presupuesto. La única guía y referencia que tenemos en este sentido por parte los líderes de pensamientos es algo parecido a esto: “Éstos son los métodos y las prácticas más comunes con las que solucionamos ciertos problemas pero nuestras soluciones con frecuencia no funcionan así que lo único que puedes hacer es intentarlo tú mismo y ver si te funciona”.

La realidad en la que vivimos es en la que un desarrollador senior describe a una persona que simplemente ha estado picando código durante más de 3 años. Estas personas suelen obtener posiciones de liderazgo y, por norma general, las cosas suelen salir como esperarías – bastante mal.

Ésta es mi opinión sobre la terminología que utilizamos en el sector. Clasificar a la gente en 3 cajas es una simplificación excesiva de todo el aprendizaje, el conocimiento y la experiencia obtenidos durante el desempeño de la profesión, pero esto es lo que hay. Si vamos a clasificar a la gente de este modo necesitamos dejar fuera de la ecuación el tiempo ejerciendo la profesión. Una persona con 10 años de experiencia es muy diferente a una persona que ha experimentado el mismo año 10 veces.

Las etapas del crecimiento del desarrollador de software

Como programadores, vivimos en un mundo de complejos sistemas y variables. Es todo un desafío simplemente ejecutar una tarea clara y bien definida, especialmente si no tienes experiencia con las herramientas a tu disposición o el código en el que estás trabajando.

Ésta es la vida del desarrollador junior. Acabas de salir de la escuela y piensas que lo sabes todo. De repente, te enfrentas con el hecho de que lo que has aprendido en la escuela es en realidad una pobre preparación para el tipo de problemas con los que te encuentras. Todo es más complicado y menos puro a nivel teórico. Vives en un reino de compromisos y no puedes dar nada por sentado.

Gestionar esto es todo en lo que puedes concentrarte y es exactamente esto lo que deberías intentar aprender mejor. Precisamente por esto los desarrolladores junior necesitan mucha guía, supervisión y tutelaje o sino pueden llegar a estancarse en esta fase durante mucho, mucho tiempo (recientemente me encontré con un compañero que había estado desarrollando software durante una década a quien personalmente aun considero junior). Podríamos decir que este periodo consiste en adquirir técnicas y tácticas para el día a día.

Un desarrollador junior se concentra en el código, no en el desarrollo y no entiende la diferencia entre ambos. Cuando un programador habla sobre cuanto le gustaría programar más si no fuera por culpa de usuarios entiendo que estamos hablando de un ingeniero junior.

Un buen desarrollador junior puede recibir una tarea previamente conocida y esperar de él que la ejecute rápido y bien.

Un desarrollador intermedio es uno que empieza a ver patrones en el fracaso (normalmente su propio fracaso) y entienden que hace falta más que una gran consecución de tareas para construir algo que funcione y que no se desmorone en cuanto alguien necesite cambiar algo. También han pasado por la experiencia única de explorar algo de lo que estaban orgullosos hace un año para acabar dándose cuenta de que en realidad era pura basura.

Un intermedio es alguien que busca respuestas a como construir cosas de la manera correcta y encontrándolas en base a la experimentación, literatura y discusión con otros programadores. Este nivel consiste en realidad en el aprendizaje de la teoría del desarrollo de software en lugar de la teoría del desarrollo de código (que se aprende en la escuela).

Los sistemas construidos por desarrolladores intermedios sin supervisión fallarán por motivos completamente diferentes a los construidos por juniors. Un junior aglutinará un gran montón de algoritmos que más o menos funcionarán. Un buen intermedio construirá páginas en base a “Patrones de diseño” y “Diseño guiado por el dominio”.  A pesar de que son grandes libros para aprender cómo construir grandes sistemas orientados a objetos, la aplicación directa de la teoría resultará en sistemas con exceso de carga de ingeniería, flexibles de modos que no importan e inflexibles en otros que son esenciales.

Puedes confiar en un intermedio para construir sistemas que funcionen durante mucho más tiempo que un junior pero que resultarán en otra clase completamente diferente de desastre. Lo triste de todo esto es que la gran mayoría, no sólo de seniors, sino de team leads son de hecho desarrolladores intermedios. La mayoría no se dan cuenta de ellos y tienen las mejores intenciones pero simplemente nunca han trabajado con nadie que esté a un nivel superior.

Los ingenieros intermedios son bastante conscientes de su rol en su organización y el valor que aportan. Un buen intermedio entiendo que escribir código es un medio para un fin y no un fin en sí mismo. Sin embargo, aun están enamorados del diseño de las torres de marfil y siguen buscando la manera correcta de desarrollar software.

Un buen ingeniero intermedio necesita menos supervisión. Puede confiarse en que detecten incidencias en el diseño del código y tener una opinión valiosa en las discusiones de diseño. También son los caballos de batalla del equipo de desarrollo. Aun y así es necesario tutelaje adicional y un nivel de supervisión superior.

Un desarrollador está íntimamente familiarizado con su propio fracaso. Han escrito código con falta y exceso de diseño y han visto a ambos fracasar. Son conscientes de las cosas que hacen, evaluando sus éxitos y fallos, enfocando los problemas con honestidad intelectual. Un desarrollador senior ha dejado de perseguir la complejidad que domina al intermedio y está obsesionado con la simplicidad.

Un desarrollador senior ha dejado de clasificar a los desarrolladores en base a su conocimiento y en cambio entiende que hay un amplio espectro de fortalezas y debilidades. Son más conscientes de sus propias fortalezas y debilidades que cualquier otro pueda estarlo jamás y persiguen sacar provecho de sus fortalezas siempre que sea posible.

Un desarrollador senior piensa en términos de contexto a la hora de aplicar la teoría. Entienden que no existe la manera correcta de construir software y que la única manera de construir buen software es adaptando la teoría a las necesidades del cliente, del código, del equipo, de las herramientas y de la organización.

Un desarrollador senior entiende que todo en nuestro campo implica una compensación y buscará lo que ello implica en cuanto a patrones de diseño, librerías, frameworks y procesos.

Un desarrollador senior piensa más allá de él mismo. Es consciente de su organización y el trabajo de sus clientes, cuales son sus valores y lo que es y no es importante para el éxito. Cuando aparezca un problema, el desarrollador senior hará lo posible por asumirlo. La frase éste no es mi trabajo nunca serás utilizada en estos contextos.

Un desarrollador senior entenderá que este trabajo consiste en dar soluciones a problemas, no escribir código. Por ello, un desarrollador senior siempre pensará en lo que está haciendo en los términos de cuanto valor reporta a su organización y los clientes en lugar de cuando esfuerzo le está demandando.

Mientras que un intermedio se arrastrará a través de días de aburrido trabajo, un desarrollador senior se echará un paso atrás y se preguntará cual es la causa de todo ese tedio. Evaluará los costes de arreglar el problema de raíz y o lo arreglará directamente o pondrá la maquinaria en movimiento para que quede arregledo en algún momento.

Un desarrollador senior entiendo que no puedes hacerlo todo por sí mismo y que su desempeño principal es ayudar a hacer mejor a su equipo, en muchas de las mismas facetas en las que aspira a hacerse mejor a nivel personal.

Un desarrollador senior entiende que el liderazgo no tiene que ver con el poder sino en dar poder a los demás. No es en marcar la pauta sino en ayudar a los demás y ser útil.

Si no tienes como mínimo un desarrollador senior en un rol de liderazgo en tu equipo, tu proyecto está condenado al fracaso. Un equipo de grandes ingenieros intermedios te llevará muy lejos pero los días del software que estás construyendo están contados y el resultado final es un producto mal acabado o costosas y arriesgadas modificaciones. Un desarrollador senior es la única persona completamente cualificada para elegir la tecnología y las plataformas, así que no teniendo uno desde el día uno te pasará factura.

Todo esto es una enorme simplificación

La realidad es que nadie encaja en estas 3 cajas a la perfección. Estoy cansado de las clasificaciones basadas en los “años de experiencia”. Los años de experiencia pueden significar algo pero es información prácticamente inútil sin conocer el contexto en el que se produjeron.

Nuestra industria realmente valora a esos virtuosos recién titulados de la facultad. Esa gente es valiosa y necesaria así como las personas con 15 ó 20 años de experiencia en el sector. Necesitamos dejar de contratar en base a estereotipos y empezar a pensar en construir equipos y organizaciones en base al talento. Si todo el mundo en tu equipo piensa igual le estás haciendo un flaco favor a tu producto y a tu empresa.

Un comentario en “El rol de un ingeniero senior”

  1. Pues, si…
    Hace años, me dediqué a la programación. No fué una tarea fácil, ni mucho menos. La creación de aplicaciones en VB, a nivel profesional, no era sencilla, a menudo te pedian cosas que requerian conocimientos profundos del Sistema, requeria mucha concentración, aunque los resultados valian la pena una vez finalizado el encargo.
    Hoy ha cambiado mucho, las aplicaciones Web, poco a poco se impondrán y se dejarán de lado las Aplicaciones Desktop, (es lo que preveo). El precio a pagar, la permanente conexión a la red, que ya es de facto una realidad. Pantallas generosas con el ordenador integrado, ratones y teclados wireless (incluso con carga solar) se irán imponiendo poco a poco.
    Los proyectos informáticos siempre han sido difíciles, digan los que digan, los que hablan y jamás han programado nada.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *