Preguntar de forma que te respondan
«No me anda» obliga a la otra persona a hacer tu trabajo de investigación antes de poder ayudarte. Una pregunta con contexto, intento y resultado esperado se responde en dos minutos, y además te hace quedar mejor que no preguntar.
Hay una asimetría que conviene entender temprano: preguntar mal no ahorra tiempo, lo mueve. Una pregunta vaga le traslada a otra persona el trabajo de averiguar qué estás haciendo, qué esperabas y qué pasó. Esa persona hace tres repreguntas, vos contestás, y recién ahí empieza la ayuda.
La misma pregunta, escrita con tres datos más, se responde en dos minutos. Escribirla te cuesta cinco. Es una de las mejores inversiones de tiempo que hay en este trabajo.
Las cinco partes de una buena pregunta
Lo que tiene que estar
- Qué querés lograr. No el paso en el que estás trabado: el objetivo. Muchas veces la respuesta correcta es «para eso no uses eso».
- Qué hiciste. El comando, el código o el paso exacto. Sin esto, la otra persona tiene que adivinar tu punto de partida.
- Qué esperabas que pasara.
- Qué pasó. El error completo, copiado y pegado, no descrito de memoria ni recortado.
- Qué probaste. Evita que te sugieran lo que ya descartaste y muestra que no estás tirando el problema por encima del hombro.
| Pregunta que genera tres repreguntas | Pregunta que se responde | |
|---|---|---|
| Cómo empieza | «No me anda el deploy» | «Estoy intentando desplegar la rama de la funcionalidad X al entorno de pruebas» |
| El error | «Tira error» | «Falla en el paso de build con: Error: Cannot find module '@app/shared'» |
| El intento | — | «Ya borré node_modules y reinstalé, y en local compila bien» |
| El pedido | «¿Alguien me ayuda?» | «¿El entorno de pruebas necesita algún paso extra para los paquetes internos?» |
Los diez minutos antes de preguntar
No se trata de no preguntar: se trata de que la pregunta llegue con lo que ya averiguaste.
Antes de escribir
- Leé el error completo, en voz alta si hace falta. Una proporción sorprendente de errores dice exactamente qué falta.
- Buscá el mensaje exacto en el repositorio y en internet. Si aparece en el propio código del proyecto, ahí está la respuesta.
- Fijate si funcionó alguna vez. Si antes andaba, la pregunta es qué cambió: tu rama, una dependencia, una variable de entorno.
- Probá reducirlo. El caso más chico que reproduce el problema suele revelar la causa antes de que termines de armarlo.
- Escribí la pregunta. Muchas veces la respuesta aparece a mitad de escribirla, y eso también cuenta como haberla hecho bien.
Antes de seguir, predecí
Dónde y a quién preguntar
| Dónde | Cuándo conviene | Qué tiene de bueno |
|---|---|---|
| Canal público del equipo | Por defecto, casi siempre | Cualquiera puede responder y queda registrado para el que venga después |
| Mensaje privado | Cuando es sobre algo puntual de esa persona, o es sensible | Directo, pero se pierde para el resto |
| Reunión diaria | Cuando afecta al plan del día | Muchas cabezas a la vez |
| Llamada | Cuando hubo tres idas y vueltas escritas sin avanzar | Diez minutos que reemplazan una hora de mensajes |
La misma pregunta, dos veces
La pregunta vaga: «no me anda el login en local, ¿a alguien le pasó?». Se escribe en diez segundos.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica