Los errores que cometen los desarrolladores junior
Entregar código que funciona es el nivel básico. No es el objetivo.
Una vez revisé un pull request que tardé 45 minutos en entender. La lógica era correcta. Las pruebas pasaban. Pero el código estaba escrito como si solo el autor fuera a leerlo alguna vez.
Cuando le di feedback, el desarrollador dijo: "Pero funciona".
Tenía razón. Funcionaba. Ese era exactamente el problema.
Los desarrolladores junior suelen centrarse en las habilidades técnicas. Pero las verdaderas carencias suelen estar en los hábitos y la mentalidad.
Aquí están los errores sutiles que te frenan:
Escribir para ti mismo en lugar de para otros El código se lee mucho más a menudo de lo que se escribe. Una función que escribas hoy podría ser tocada por tres personas diferentes a lo largo de dos años. Si un extraño no puede entender tu código en 30 segundos, has fallado.
Copiar código sin entenderlo Usar Stack Overflow está bien. Copiar un patrón de regex sin saber cómo funciona es peligroso. Creas una caja negra en tu base de código. No podrás depurarla cuando falle.
Añadir complejidad innecesaria Los juniors suelen equiparar la complejidad con la habilidad. Aplican patrones de diseño a tareas sencillas. La abstracción innecesaria hace que el código sea más difícil de depurar y más difícil de cambiar. Solo añade abstracción cuando sientas el dolor de su ausencia.
Ignorar los mensajes de error Los mensajes de error son documentación gratuita. No saltes a Google en el momento en que veas un stack trace. Lee el mensaje completo. A menudo te dice exactamente qué línea falló y por qué.
Pedir ayuda demasiado pronto o demasiado tarde No pases tres horas atascado en un problema de 10 minutos. Eso es ineficiente. Pero no le escribas a un senior solo con una captura de pantalla y sin contexto. Usa la regla de los 20 minutos: pasa 20 minutos intentando resolverlo. Documenta lo que intentaste. Luego pide ayuda con esa documentación.
Reconstruir lo que ya existe Antes de escribir una nueva utilidad, busca en la base de código. Es probable que tu equipo ya haya resuelto ese problema.
Mensajes de commit deficientes Un mensaje de commit como "fix bug" no le dice nada a tu equipo. Explica qué cambió y por qué. Trata el historial de Git como documentación.
Tratar los requisitos como leyes Los requisitos a menudo omiten casos de borde. No te limites a implementar lo que se te pide. Pregunta qué sucede cuando las cosas salen mal.
Detenerse en el botón "Merged" La responsabilidad no termina cuando se fusiona tu PR. Sigue tu funcionalidad hasta QA. Obsérvala en producción. Lee los informes de errores.
La mayor brecha es la responsabilidad. Los desarrolladores senior no solo escriben código. Resuelven problemas sin crear otros nuevos.
Deja de optimizar para "terminado". Empieza a optimizar para "bueno".