Discutiendo las diferencias entre programador Junior, Mid, Senior y Arquitecto de Software

Una de mis motivaciones para escribir este post es que he visto dos tendencias tanto al contratar personas como al ser contratado por personas, la existencia de barreras artificiales, expectativas irreales por parte de desarrolladores y contratistas sin claridad en las responsabilidades, los niveles clasicos suelen ser:

• Junior Developer
• Mid/Regular Developer
• Senior Developer
• Software Architect

La infografia es gracias a Academik.

Como muchas cosas en el área de TI, los criterios suelen ser subjetivos y heredados desde Estados Unidos, no están estandarizados en la industria, pero se pueden observar ciertas características y tendencias en cada nivel/oferta laboral.

En esta «clasificación» presento mis conclusiones luego de participar como interesado en plazas laborales, así como auxiliar a equipos de desarrollo y reclutamiento a contratar candidatos.

Junior Developer

Uno de los criterios primarios para identificar a un Junior Developer es su experiencia, o para ser más precisos, la falta de experiencia. Lo cual no es necesariamente malo

Características generales:

• Un desarrollador recién egresado o aun estudiando en la Universidad/bootcamp/curso técnico de programación
• Desde 0 a un máximo de 3 años de experiencia (ideal 1 año)
• Suele tener experiencia en un lenguaje de programación, plataformas actuales aunque no necesariamente establecidas

Responsabilidades y roles ideales:

• Se espera que la persona que haya sido contratada como Junior no tenga «mucha idea» de conceptos avanzados en su técnologia
• Sus principales labores suelen ser dar mantenimiento a un sistema existente con lineamientos claros de arquitectura
• Se espera que un desarrollador Junior eventualmente pueda ir tomando responsabilidades conforme avanza en su formación personal y profesional

Principales debilidades y consejos:

• Suelen saber mucho superficialmente y poco a fondo. Aunque en TI nunca es bueno «casarse con una tecnología», si es bueno ser especialista en algo.
• Aprender antes frameworks que lenguajes. Mi consejo en este caso siempre es aprender un lenguaje a fondo para entender mejor los conceptos fundamentales, mi listado siempre ha sido:
  • Aprender un lenguaje de tipado estático, idealmente Java
  • Aprender un lenguaje de típado dinámico, idealmente JavaScript
  • Aprender un lenguaje scripting, idealmente Bash.
• «No saben que no saben». Algo conocido como el efecto Dunning Krugger. Mucho de esto se debe a la falta de enfrentamiento a proyectos reales y la única forma de acelerarlo es participar más en proyectos, participar en Open Source y rodearse de gente con más experiencia que pueda compartir sus conocimientos. Mientras más interacciones se tienen con el gremio/entorno es mejor para formarse una perspectiva amplia.
• No les importa tanto el negocio. Aunque no todos nacimos para ser Project Managers, una receta para ser mal desarrollador es que no importe la generación de valor para el cliente.
• No les importa tanto la arquitectura. Una de las tendencias modernas es que las herramientas suelen ser más fáciles y a la mayoría de developer Junior no les importa la arquitectura, la cual generalmente no es importante para entregar soluciones rápido pero es importante para que el código sea mantenible y escalable.

Mid developer

Uno de los criterios primarios para identificar a alguien como el Mid-developer es la experiencia en una plataforma, generalmente a un Mid developer se le pueden delegar tareas y reducir la supervisión e incluso trabajar en posiciones freelance.

Características generales

• Un desarrollador que ya tuvo un contacto con educación en desarrollo de software en cualquiera de sus formas
• Una persona que ya entendió que el ser autodidacta en el medio es super importante
• Desde 1 a 5 años de experiencia

Responsabilidades y roles ideales

• Se espera que la persona contratada como mid developer tenga familiaridad con herramientas universales en el desarrollo de software como sistemas de control de versiones, linea de comandos básica y un lenguaje de programación
• Se espera que una persona contratada como Mid developer pueda utilizar jerga común en el área de sistemas
• También se espera que sea un developer al cual se le pueden asignar tareas con componentes de investigación, desarrollo y sentido de responsabilidad
• Se espera que sea un desarrollador con formación completa respecto a una plataforma

Principales debilidades y consejos:

• Les es dificil migrar entre frameworks. Una característica «evolucionada» de ser un Junior developer en el dilema practicidad vs. fundamentación teórica, es la capacidad de evolucionar con el tiempo. Mi consejo es el mismo que para los Jr. Developers.
• Sobreutilización de patrones. Aunque parezca una paradoja, una de las diferencias claras entre un developer Mid y un Sr. es saber cuando utilizar correctamente las herramientas/patrones/abstracciones, esto básicamente viene con la experiencia.
• Les es fácil ser dogmáticos con la técnologia. Una vez se ha invertido una considerable cantidad de tiempo en la técnologia, es dificil aceptar que las soluciones van cambiando y lo que solía ser lo ideal, puede que ya no sea lo ideal.
• No les importa tanto ayudar a otros desarrolladores en su equipo. Y esto previene muchas veces el avanzar en su carrera como desarrollador, el tomar responsabilidad de sus tareas y también del proyecto.

Senior developer

Uno de los criterios primarios para identificar a alguien como senior developer es su capacidad de trabajar en equipo, liderar equipos de desarrollo desde el punto de vista tecnologico y toma de decisiones.

Características generales

• Un desarrollador que conoce a fondo varias plataformas (lenguaje, bibliotecas, entornos de ejecución)
• Un desarrollador que cuenta con varios tipos de experiencia en proyectos exitosos pero sobre todo fracasados
• Un desarrollador que se prepara y actualiza constantemente mediante certificaciones, cursos cortos, MOOCs, conferencias, libros, grupos de usuarios, etc.
• De 5 años de experiencia en adelante

Responsabilidades y roles ideales

• Se espera que la persona contratada como Senior developer tenga conocimiento avanzado en dos una plataforma y conozca dos o más plataformas para distinguir entre fortalezas y debilidades (gracias por el feedback en este criterio, parece ser un consenso común)
• Se espera que un senior developer pueda participar en procesos revisión de código por pares (peer review)
• Es un developer al cual se le pueden asignar tareas complejas, software de alto desempeño, software crítico y tolerante a fallos
• Se espera que sea un developer que eventualmente pueda participar como líder de desarrollo (lead developer) ayudando a los demás miembros de su equipo con su experiencia

Principales debilidades y consejos:

• Les es aun más fácil ser dogmáticos con la técnologia. Una vez que se es Senior no es dificil obtener trabajo en la técnologia de preferencia. Esto no es bueno ni malo pero en plataformas poco establecidas -e.g. Clojure- puede ser algo que le afecté en el futuro.
• El ego. Un developer senior real no tiene problemas en reconocer que todos somos Junior en algo, un developer senior reciente suele tener mucho ego. Mi único consejo es la humildad y menos azucar. Esto a la larga suele jugar a nivel organizacional para volverse arquitecto de software.

Arquitecto de software

La linea entre un desarrollador Senior y un arquitecto de software suele ser muy delgada ya que ambos son profesionales con experiencia bajo el cinturón. Generalmente va más relacionada a la orientación de las tareas que cada uno realiza. En el caso de arquitecto, sus tareas van más enfocadas a investigación y desarrollo vs producción de software.

Debo decir que muchas veces el rol de arquitecto de software se confunde con el de gestor de proyectos pero esto depende en mayor o menor medida de las políticas de cada empresa.

Características generales

• Un desarrollador que conoce a fondo varias plataformas (lenguaje, bibliotecas, entornos de ejecución)
• Un desarrollador que cuenta con varios tipos de experiencia en proyectos exitosos pero sobre todo fracasados
• Un desarrollador que se prepara y actualiza constantemente mediante certificaciones, cursos cortos, MOOCs, conferencias, libros, grupos de usuarios, etc.
• De 5 años de experiencia en adelante

Responsabilidades y roles ideales

• Se espera que la persona contratada como arquitecto de software tenga conocimiento avanzado dos una plataforma y conozca dos o más plataformas para distinguir entre fortalezas y debilidades (gracias por el feedback en este criterio, parece ser un consenso común)
• Se espera que un arquitecto de software pueda tomar decisiones desde los puntos de vista técnicos, económicos y humanos en relación a la tecnológia a ser utilizada.
• Es un developer que ya cometió demasiados errores y aprendió de ellos.
• Se espera que sea un arquitecto de software defina lineamientos, políticas de calidad, de contratación de personal, tecnologías y proyecte la evolución de un sistema.
• Se espera que un arquitecto de software pueda cargar con la responsabilidad del éxito o fracaso de sus lineamientos en proyectos de software

Principales debilidades y consejos:

• Al alcanzar cierta edad es extremadamente fácil aburrirse de programar. Pero pienso que programar (incluso POCs) es la única forma real de evaluar las fortalezas de cada plataforma.
• Un arquitecto real cobra caro. Y el no tener un arquitecto real puede ser incluso más caro dependiendo las características del proyecto.
• El ego. Un arquitecto real no tiene problemas en reconocer que todos somos Junior en algo, un arquitecto reciente suele tener mucho ego. Mi único consejo es la humildad y menos azucar.
• Una de las cosas más difíciles para un arquitecto es desarrollar la empatía. Esto es fundamental para entender las necesidades de compañeros de trabajo, clientes y mi único consejo es salir más.