Acompañar a alguien que recién empieza
La primera vez que te toca acompañar a alguien junior, el instinto es resolverle los problemas rápido para que no sufra. Es exactamente lo contrario de lo que produce autonomía: la ayuda que sirve es la que deja el problema del lado de quien aprende.
Alguien recién llegado te escribe: «no me anda esto». Sabés la respuesta en cinco segundos. Contestarla es lo más rápido, lo más amable en apariencia, y es lo que garantiza que la semana que viene te vuelva a escribir por algo parecido.
Acompañar bien no es resolver más rápido: es ir devolviendo el problema con un poco más de información cada vez, hasta que deje de volver. Y eso es más lento hoy, a propósito.
La escalera de la ayuda
Ante la misma pregunta hay varias respuestas posibles, y conviene elegir a conciencia en qué escalón responder:
| Escalón | Qué decís | Qué aprende | Cuándo usarlo |
|---|---|---|---|
| Dar la respuesta | «Es porque falta la variable X» | Ese caso puntual | Hay urgencia real, o ya lo intentó bastante |
| Dar la pista | «Fijate en la configuración del entorno» | Dónde buscar la próxima vez | Caso típico |
| Dar el método | «¿Cómo harías para saber qué configuración está tomando?» | Una forma de investigar que sirve para muchos casos | Cuando hay tiempo: es el que más rinde |
| Devolver la pregunta | «¿Qué probaste y qué descartaste?» | A estructurar el problema solo | Cuando la pregunta llegó sin ningún intento |
Antes de seguir, predecí
Las primeras semanas
Lo que más define la experiencia de alguien nuevo no es la calidad de la explicación técnica: es cuánto tarda en hacer algo real y en saber a quién preguntarle.
Lo que conviene asegurar
- Que entregue algo a producción en la primera semana, aunque sea un cambio mínimo. Recorrer el camino completo —escribir, revisar, desplegar, verificar— enseña más del sistema que cualquier documento, y saca de encima la ansiedad de no haber aportado nada.
- Que sepa a quién preguntarle qué. Un nombre por área. Sin eso, todas las preguntas van a caer en vos o, peor, en nadie.
- Que tenga permiso explícito para preguntar. Decilo con palabras: «preguntame cualquier cosa, sobre todo si hace más de una hora que estás con lo mismo». El permiso implícito no existe para alguien que recién llega.
- Que sepa qué se espera de esta etapa. Nadie espera velocidad en el primer mes: si no se dice, la persona lo asume y se apura.
- Un momento fijo por semana, corto, que no dependa de que se anime a pedirlo.
Corregir sin desinflar
Las revisiones de código son el canal principal de corrección con alguien junior, y son también donde más fácil se desinfla a alguien sin querer.
| Comentario que desinfla | Comentario que enseña | |
|---|---|---|
| Forma | «Esto está mal» | «Esto se va a romper si la lista viene vacía; conviene validar antes» |
| Preferencia vs. problema | Todo con el mismo peso | «Menor, tomalo o dejalo» / «Esto sí hay que cambiarlo antes de mergear» |
| Cantidad | Treinta comentarios en la primera revisión | Los cinco que más importan, el resto en una charla |
| Lo que está bien | No se menciona | «Buen manejo del caso borde acá» |
Elegir el escalón
Escenario · 1 decisión como mínimo
«No me anda esto» — y vos sabés la respuesta en cinco segundos
Alguien que entró hace tres semanas te escribe: «no me anda el entorno local, tira error de conexión a la base». Vos sabés que le falta una variable de entorno. Es martes a la mañana y no hay ninguna urgencia. ¿Qué contestás?
Le anda en dos minutos. El jueves te escribe porque falta otra variable, y el martes siguiente porque el servicio de correo no arranca.
DesenlaceCada respuesta fue correcta y ninguna enseñó dónde mirar. Dar la respuesta está bien cuando hay urgencia real o cuando la persona ya lo intentó bastante; como reflejo, produce exactamente esta secuencia.
Vuelve a los veinte minutos: encontró el archivo de configuración, lo comparó con el de ejemplo y resolvió. ¿Cerrás ahí?
Dos semanas después aparece un problema parecido y vuelve a preguntar.
DesenlaceResolvió una vez sin saber que había resuelto algo repetible. Media hora de trabajo se pierde si nadie le pone nombre.
Te contesta: «no sé, ¿mirar el código?». ¿Qué hacés?
Pasa una hora. Sigue trabado y ya no vuelve a escribirte.
DesenlaceEso es lo más caro que puede pasar: dejó de preguntar. Sostener el escalón alto cuando la persona no tiene un próximo paso deja de ser acompañamiento y pasa a ser una prueba, y nadie pide ayuda dos veces después de eso.
Le decís que lo que hizo —comparar el archivo real contra el de ejemplo— es lo primero que conviene probar ante cualquier problema de configuración. ¿Y con lo que faltaba en el proyecto?
Un mes después entra otra persona y se traba con lo mismo.
DesenlaceEl pozo seguía ahí. Y quien mejor lo puede tapar es justamente quien acaba de caerse, porque todavía se acuerda de qué le faltaba.
Manda un pull request de tres líneas: la variable en el .env.example y una línea en el README.
DesenlaceAprendió un método, dejó el proyecto mejor y mandó su primer cambio en la primera semana. Los tres resultados salieron de haber contestado con una pregunta en vez de con la respuesta, y de haber tardado veinte minutos más que si se la dabas.
La escalera se sube cuando hay tiempo y se baja cuando la persona se queda sin próximo paso.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica