Lo que separa a un junior de un senior
No es la cantidad de código que saben de memoria. No es la velocidad. Es cómo responden cuando se topan con algo que no conocen. Los seniors se topan con cosas desconocidas a diario. La diferencia está en el proceso.
- ✗ Intenta arreglar antes de leer el error completo
- ✗ Busca en Google: "css not working"
- ✗ Pide ayuda tras 5 minutos de frustración
- ✗ Copia Stack Overflow sin entender qué hace
- ✗ Cuando funciona, no pregunta por qué funciona
- ✗ Trabaja horas en el mismo bloqueo sin parar
- ✗ Siente que no saber algo = no sirve para esto
- ✓ Lee el error completo y la línea exacta donde ocurre
- ✓ Busca: "css grid gap not working safari 17"
- ✓ Dedica 20 min activos antes de pedir ayuda
- ✓ Lee el código copiado y lo entiende antes de usarlo
- ✓ Cuando funciona, quiere entender exactamente por qué
- ✓ Toma pausas deliberadas cuando lleva 45 min bloqueado
- ✓ Normaliza no saber: la documentación existe para eso
Debugging: un proceso, no magia
Debugging no es adivinar. Es un método sistemático. Los desarrolladores experimentados siguen pasos aunque no lo hagan conscientemente. Aquí el proceso explícito.
Lee el error completo
No el primer texto. El mensaje completo, la línea exacta, el stack trace. El 60% de los errores se resuelven en este paso. El mensaje te dice exactamente qué está mal y dónde.
Reproduce el error de forma consistente
Antes de tocar nada: asegúrate de poder reproducir el error cada vez. Si no puedes reproducirlo de forma consistente, no puedes arreglarlo de forma consistente.
Aisla el problema
Comenta código hasta que el error desaparezca. El último bloque que comentaste es el culpable. Crea el caso más simple posible que reproduzca el problema.
Formula una hipótesis y pruébala
No cambies múltiples cosas a la vez. Cambia una cosa, prueba, observa el resultado. Si cambias tres cosas y se arregla, no sabes cuál lo arregló.
Documenta la solución
Un comentario en el código, un commit descriptivo, o una nota personal. La próxima vez que veas este error (y la verás), habrás ahorrado horas.
Escenario: el botón de enviar no hace nada
- Abrir DevTools → Console: ¿Dice "Cannot read properties of null"? → El querySelector falló
- Reproducir: pasa siempre al cargar la página, no solo al hacer clic
- Aislar:
console.log(document.querySelector('#enviar'))devuelve null - Hipótesis: el script corre antes de que el DOM exista. Mover script al final del body.
- Fix confirmado. Commit: "fix: move script to end of body — fixes null querySelector"
Las DevTools: tu laboratorio
Las DevTools del navegador son la herramienta más poderosa. La mayoría de novatos las usa solo para console.log. Hay mucho más.
- Clic derecho en cualquier elemento → Inspect para abrirlo en Elements
- Doble clic en el HTML para editarlo en tiempo real
- Panel Styles: ve qué reglas CSS aplican y cuáles están sobreescritas (tachadas)
- Panel Computed: el valor FINAL de cada propiedad CSS
- Force element state: :hover, :focus, :active para debuggear sin mouse
- Modo responsive: ícono de dispositivo para simular iPhone, iPad, etc.
- Filtra por Fetch/XHR para ver solo las llamadas a APIs
- Clic en una petición: Headers (qué enviaste), Response (qué recibiste)
- Status 200=OK · 404=no encontrado · 401=sin auth · 500=error servidor
- Throttling: simula 3G o Slow 3G para probar con conexión lenta
- Disable cache mientras desarrollas para ver siempre los cambios
- Clic en el número de línea → breakpoint: el código para justo ahí
- Step over (F10): ejecuta la siguiente línea sin entrar en funciones
- Step into (F11): entra en la función de la línea actual
- Watch: observa el valor de cualquier variable en tiempo real
- Escribe
debugger;en tu código → breakpoint automático desde JS
Buscar bien es una habilidad técnica
La diferencia entre una búsqueda que resuelve en 30 segundos y una que tarda 2 horas está en la especificidad. Saber qué buscar y cómo buscar es tan importante como saber código.
- Tecnología + descripción exacta del comportamiento
- Nombre del error exacto si lo hay (copia la primera línea)
- Año o versión si el comportamiento pudo cambiar recientemente
- Sitio específico cuando sabes dónde buscar:
site:stackoverflow.com
MDN Web Docs
Para: qué hace un método/propiedad, parámetros, compatibilidad de navegadores. Siempre empezar aquí.
Stack Overflow
Para: errores específicos que otros tuvieron. Verifica la fecha: soluciones de 2016 pueden estar desactualizadas.
GitHub Issues
Para: bugs del framework o librería en sí. Si React, Next.js o Vite no funciona "como debería".
La anatomía de una buena pregunta
El pseudocódigo: programar en español primero
Los desarrolladores más rápidos son los que más planifican antes de escribir código. 10 minutos de planificación ahorran 2 horas de refactoring. El pseudocódigo es el puente entre el problema y la solución.
Antes de una línea de código: ¿Qué debe hacer exactamente? ¿Cuándo? ¿Qué inputs? ¿Qué outputs? ¿Edge cases?
Escribe los pasos en lenguaje natural. Sin preocuparte por sintaxis.
Ahora sí: traducir el pseudocódigo a JavaScript. Cada paso ya lo tienes claro.
El síndrome del impostor es universal
El 70% de los profesionales exitosos lo experimentan. No es exclusivo de principiantes. La diferencia es que los seniors saben que es normal y siguen adelante de todas formas.
No saber ≠ no servir
Desarrolladores seniors con 10 años buscan en Google cómo hacer un loop. Nadie sabe todo de memoria. El trabajo es saber CÓMO encontrar lo que no sabes.
El impostor es señal de progreso
Sientes impostor syndrome porque estás creciendo más rápido de lo que tu autoconcepto puede actualizar. Si todo te pareciera fácil, no estarías aprendiendo.
Los errores son datos, no veredictos
Un error no dice nada sobre tu capacidad. Dice que tu hipótesis era incorrecta. Actualiza la hipótesis y sigue. Es exactamente cómo funciona la ciencia.
La comparación es injusta
Ves los portfolios y commits de otros, no sus frustraciones, sus horas de bloqueo, sus sesiones de debugging a medianoche. Compárate solo con quien eras el mes pasado.
Los hábitos que marcan la diferencia
Pequeños rituales diarios que, compuestos durante semanas, crean desarrolladores excelentes.
Lee el error antes de buscar
30 segundos leyendo el error valen más que 30 minutos buscando aleatoriamente.
console.log defensivo
Cuando algo no funciona, pon console.log antes de cada paso para ver exactamente dónde se rompe el flujo.
Commits pequeños y frecuentes
Cada vez que algo funciona: commit. No esperes a "terminar la feature". Si algo se rompe, vuelves en 10 segundos.
Lee código ajeno
Inspecciona el código fuente de webs que admiras. Lee PRs de proyectos open source. Leer código de calidad enseña más que muchos tutoriales.
El pomodoro técnico
25 minutos de foco intenso, 5 de descanso. Si llevas más de 25 minutos bloqueado en lo mismo, el descanso no es opcional.
Documenta mientras construyes
No al final. Mientras construyes. Un comentario de una línea cuando haces algo no obvio ahorra horas a tu yo del futuro.
Lee la documentación oficial
Tutoriales de YouTube son un punto de entrada. MDN, docs de React, docs de TypeScript: ahí está el conocimiento real y actualizado.
Ejercicio: encuentra y arregla los bugs
No escribirás código nuevo. Recibirás tres fragmentos de código roto. Usa el proceso de debugging para identificar el problema, formular una hipótesis y arreglarlo.
El botón no responde al clic
Se configuró un event listener pero el botón nunca dispara el evento.
¿Qué selecciona .enviar vs #enviar? ¿Qué devuelve querySelector cuando no encuentra nada?
La función siempre devuelve undefined
calcularDescuento() se llama correctamente pero el resultado siempre es undefined.
Una función en JavaScript sin return explícito devuelve undefined por defecto.
El fetch no muestra los datos
Se hace la petición a la API pero el DOM nunca se actualiza.
fetch() devuelve una Promise. Sin await o continuando la cadena .then(), los datos no están disponibles de forma síncrona.