Repasemos eso desde la perspectiva de un empleador.
La primera semana o dos.
Alguien sin habilidades prácticas y experiencia comprobada se une a su equipo. Los saluda, los muestra, los presenta al equipo y los deja acomodarse en su escritorio.
Compartes el acceso a tu VPN, los agregas en Dropbox o Drive, les das la documentación del primer proyecto en el que trabajarán. Organice una breve reunión con los otros desarrolladores si lo desea, está bien.
Dejas que instalen su stack técnico y esperas que comiencen a solucionar errores y problemas durante los primeros días, y espero que lo hagan desde allí.
Esto fallará miserablemente.
El desarrollador nuevo (muy probablemente) carece de:
- Habilidades técnicas.
- Conocimiento de la mejor pila técnica que necesitan usar (o lo que sea que la compañía use).
- Experiencia con GitHub / Bitbucket, integración continua, scripts de implementación, pruebas unitarias.
- Sin exposición a un proyecto grande (o incluso existente).
- Falta de familiaridad con los conceptos de un gran producto: arquitectura, infraestructura, fundamentos.
- No hay experiencia práctica en el software de refinación con compatibilidad con versiones anteriores.
- Experiencia limitada en probar el problema de numerosas maneras, sabiendo lo que puede fallar en el extremo técnico (casos extremos o regresiones).
Lo que probablemente sucederá es la falta de progreso o una serie de parches que rompan casi todo.
Luego vienen las habilidades de comunicación y gestión.
No estoy hablando de “liderar un equipo”, por supuesto.
Pero mientras trabaja en errores (o incluso durante la revisión de la documentación), un desarrollador está a punto de:
- Estime ciertas características o priorice el trabajo atrasado.
- Haga preguntas específicas que aclaren las necesidades del negocio y el contexto de la tarea.
- Construya un modelo mental del problema en su cabeza.
- Prepare un parche que cumpla con el resto de la base del código (estándares de codificación, cobertura de código esperada).
- Reasigne adecuadamente la tarea con un comentario apropiado que explique la solución y la documente.
- Documentar el comportamiento en otro lugar: en una documentación real o en un repositorio de pedidos pendientes de PM.
- Busque los enfoques existentes que conducen a la reutilización del código y la aplicación efectiva de las estrategias existentes para resolver un problema conocido.
Aquí viene el problema con comportamientos inesperados, tareas poco claras y comunicación ineficiente.
Los jóvenes requieren tutoría proactiva.
La cuestión es que el estudiante de primer año carece de habilidades técnicas, conocimientos de informática (en la práctica), experiencia real en el trabajo en proyectos existentes, habilidades de comunicación, habilidades de trabajo en equipo y otras cosas descritas anteriormente.
Eso termina en un gran conjunto de actividades en las que se debe trabajar simultáneamente. Cada uno puede tomar meses hasta que consiga una persona productiva a bordo.
Algunos se aceleran más rápido, otros no. Una compañía puede invertir más de un año en incorporación y capacitación hasta que obtenga resultados razonables en tareas bastante triviales.
Agregue un año de salario a la ecuación.
Y luego agregue el tiempo semanal de todos los miembros del equipo involucrados en el proceso de tutoría. El mentor debe manejar tres cosas:
- Hacen su propio trabajo a tiempo completo.
- Ayuda, entrena, educa, orienta, apoya al principiante.
- Arregla el desorden después de lo que no les fue asignado en primer lugar.
Muchos de mis amigos que contratan a su primer empleado junior como fundadores tecnológicos dicen que trabajan 2 turnos, ya que les toma el doble de tiempo manejar su carga de trabajo y una nueva persona (y su trabajo).
Los jóvenes pueden mirar alrededor bastante pronto.
HackerLife compartió una investigación [1] en la que se analizó la duración promedio de los ingenieros de software en San Francisco:
![](http://q.miximages.com/9500/Software Developers/main-qimg-6d087683ae8d5fe80b0078386394cf47.png)
No es improbable que pase de 3 a 5 años o más en las empresas líderes a nivel mundial. Pero eso generalmente se aplica a ingenieros experimentados que buscan un trabajo sólido a tiempo completo que les permita hacer lo que aman mientras cuidan de su vida (familia, amigos, viajes).
Esto explica la tenencia en pequeñas empresas (1,5 años) , combinada con la falta de otras ventajas y, a menudo, un salario más bajo (o un paquete de bonificación).
Pero si usted es una empresa pequeña o mediana, que capacita a un junior durante un año y se va en unos meses, ¿cómo se reflejaría eso en el negocio, la moral del equipo y su progreso continuo?
Contratar un desarrollador junior requiere un salto de fe . Lo que ayuda es la experiencia en pasantías, trabajar en proyectos de mascotas, colaborar con otros desarrolladores en conciertos paralelos, unirse a una comunidad de código abierto y otras indicaciones de que el desarrollador ha gastado el tiempo y el esfuerzo que reducirían la curva de aprendizaje y aumentarían las posibilidades de una efectividad asociación por un período de tiempo más largo.
Notas al pie
[1] Tenencia de ingenieros de software en San Francisco