What to Prepare Before a First Consultation
Llegar a una primera consulta sobre tu código sin nada preparado es más común de lo que parece. El desarrollador que te va a ayudar necesita contexto, no adivinanzas. Esta guía reúne lo que conviene tener a mano para que la sesión rinda desde el primer minuto.
El repositorio y el estado real del proyecto
Antes de pedir ayuda, asegúrate de que el repositorio esté limpio y con un README que explique cómo se ejecuta el proyecto. Nada frena más una consulta que perder veinte minutos intentando levantar un entorno que solo funciona en tu máquina. Si usas variables de entorno, incluye un archivo de ejemplo con los valores ficticios.
También conviene anotar la versión exacta de las dependencias principales: Node, Python, el framework que uses y la base de datos. Muchos problemas que parecen de lógica son en realidad incompatibilidades de versiones que se resuelven en dos líneas cuando se ven los números.
El problema concreto, no el síntoma
Describe qué esperabas que ocurriera y qué ocurrió en su lugar. Incluye el mensaje de error completo, no solo la primera línea. Si el error aparece solo en producción, explica qué diferencia hay con tu entorno local: variables, permisos, caché, puertos.
Un buen ejercicio es escribir el problema en un párrafo antes de la consulta. Si no puedes explicarlo en tres frases, probablemente todavía no has identificado la causa raíz. Esa redacción previa te ayuda a ti y le ahorra tiempo a quien te asesora.
Ejemplos mínimos y datos de prueba
Si el fallo depende de un conjunto de datos concreto, prepáralo en un archivo pequeño y reproducible. No hace falta que sea el dataset completo de producción; con diez registros que reproduzcan el caso suele bastar. Lo mismo aplica para peticiones a una API: ten a mano un curl o un ejemplo en Postman que falle de forma consistente.
En proyectos de testing, adjunta el test que falla y el que pasa. Esa comparación suele revelar qué supuesto estás haciendo mal. Si el problema es de rendimiento, incluye el tiempo de respuesta medido y el volumen de datos implicado.
Decisiones que ya tomaste
Explica por qué elegiste esa arquitectura, ese patrón o esa librería. No para justificarte, sino para que quien te ayude entienda las restricciones que ya aceptaste. A veces la solución más limpia implica cambiar una decisión anterior, y eso es más fácil de discutir si está sobre la mesa desde el principio.
Si trabajas con un equipo, indica qué partes del código son tuyas y cuáles heredaste. También es útil saber si hay una fecha límite o si el código va a producción pronto, porque eso cambia el tipo de recomendación que tiene sentido aplicar.
Preguntas que quieres responder
Lleva una lista de dos o tres preguntas concretas. No hace falta que sean técnicas: pueden ser sobre estructura, mantenibilidad o cómo explicar esta decisión en una entrevista. Una consulta bien aprovechada no solo resuelve el error inmediato, también te deja criterio para la próxima vez.
Si el tiempo lo permite, pide que te muestren el razonamiento, no solo la corrección. Entender por qué una solución funciona en tu caso concreto y no en otro es lo que convierte una consulta puntual en aprendizaje real.