El desarrollo backend tiene errores técnicos costosos (un bug puede borrar datos o exponer información sensible) y errores de carrera que frenan el progreso durante meses. Esta guía cubre los más comunes en ambas categorías.
Errores técnicos que se ven demasiado en código backend junior
Error 1: Contraseñas en texto plano (o mal hasheadas)
El error más grave de seguridad y sorprendentemente frecuente en proyectos de portafolio. Nunca guardes contraseñas sin hashear. Usa bcrypt o Argon2; no MD5 ni SHA-1 (son inseguros para contraseñas).
// Mal
user.password = "mipassword123"
// Bien (con bcrypt)
user.password = await bcrypt.hash("mipassword123", 12)Si un evaluador abre tu repositorio y ve contraseñas sin hashear, el proceso termina ahí.
Error 2: Credenciales y secretos en el código fuente
Variables de entorno, API keys, conexiones de base de datos no pertenecen al código. Pertenecen a archivos .env que están en .gitignore.
Subir credenciales a GitHub es un error que ocurre con frecuencia y tiene consecuencias reales: bots escanean GitHub continuamente buscando API keys activas y las usan para generar cargos en servicios cloud.
La regla: si es un secreto, va en variable de entorno. Siempre.
Error 3: No validar los datos de entrada
Todo lo que llega del cliente (headers, body, params, query) debe validarse antes de procesarse. Un input no validado es una puerta de entrada a inyecciones SQL, crashes, o comportamientos inesperados.
Librerías de validación: Zod (Node.js), Pydantic (Python), Joi (Node.js). El tiempo de agregar validación es mucho menor que el tiempo de debuggear los bugs que genera no tenerla.
Error 4: Manejo de errores inconsistente
Una API que devuelve un stack trace completo en producción expone información interna del sistema. Una API que devuelve errores genéricos sin logging interno no te deja debuggear nada.
El balance: logging detallado internamente, respuestas de error genéricas al cliente, con códigos HTTP correctos (400 para error del cliente, 500 para error del servidor, no todo 200 o todo 500).
Error 5: N+1 queries en base de datos
Un error de performance clásico: hacer una query por cada item de una lista en lugar de traer todos los datos en una sola consulta.
Ejemplo problemático con un ORM:
// Esto hace 1 query para traer posts + 1 query por cada post para traer el autor = N+1 queries
const posts = await Post.findAll()
for (const post of posts) {
post.author = await User.findByPk(post.authorId)
}
// Correcto: 1 sola query con JOIN
const posts = await Post.findAll({ include: [User] })Con bases de datos grandes, la diferencia entre N+1 y una sola query puede ser de segundos a milisegundos.
Errores de carrera que frenan el progreso
Error 6: Nunca desplegar nada en producción
Saber hacer funcionar una API en local es solo la mitad. La otra mitad es saber desplegarla, configurar variables de entorno en un servidor real, manejar HTTPS, monitorear errores.
Un dev que no ha desplegado nada en producción real tiene un punto ciego enorme que se nota en entrevistas y proyectos.
Error 7: Ignorar la seguridad hasta “cuando sea necesario”
La seguridad no se puede agregar después de manera fácil; se tiene que diseñar desde el principio. Inputs validados, contraseñas hasheadas, secretos en variables de entorno, HTTP-only cookies: estas no son “mejoras avanzadas”. Son el mínimo desde el primer proyecto.
Error 8: No aprender SQL de verdad
Muchos devs backend aprenden solo a usar ORMs (Sequelize, Prisma, SQLAlchemy) sin entender el SQL que generan. Cuando los queries son lentos o los resultados son incorrectos, no saben por qué ni cómo arreglarlo.
Aprender SQL directo (sin ORM) aunque sea durante las primeras semanas construye una base que paga durante toda la carrera.
Error 9: Cambiar de stack antes de llegar a profundidad real
Node.js por 2 meses, luego Python por 1 mes, luego Go porque “está de moda”. Resultado: superficie en tres tecnologías, profundidad en ninguna.
Elegir un stack y llevarlo a un nivel real (incluidas partes incómodas como testing, deploy, optimización) es más valioso que conocer superficialmente muchas tecnologías.
Error 10: No leer el código de otros
El propio código enseña lo que ya sabes. El código de otros enseña lo que no sabes que no sabes. Leer repositorios open source bien mantenidos, revisar PRs en proyectos públicos, participar en code reviews: todo esto acelera el crecimiento de manera que ningún tutorial puede replicar.
Resumen rápido
| Error | Categoría | Consecuencia | Solución |
|---|---|---|---|
| Contraseñas sin hashear | Técnico/Seguridad | Filtración de datos | bcrypt/Argon2 siempre |
| Credenciales en código | Técnico/Seguridad | Cargos no autorizados | Variables de entorno + .gitignore |
| Sin validación de inputs | Técnico | Bugs y vulnerabilidades | Zod/Pydantic en cada endpoint |
| N+1 queries | Técnico/Performance | Lentitud en producción | Entender cómo funciona el ORM |
| Sin deploy en producción | Carrera | Punto ciego en entrevistas | Railway/Render desde el primer proyecto |
| Cambio frecuente de stack | Carrera | Ningún lenguaje a profundidad | Comprometerse con uno 6-12 meses |
¿Tienes alguno de estos errores en tu código o carrera actual? En el foro de Nomadaz la comunidad de devs backend puede darte orientación específica para tu situación. Mejor detectarlo ahora que en una entrevista o con datos de un cliente real en juego.