Day in the Life of a Backend Developer

Te has preguntado cómo es un día real de desarrollador backend y lo que encuentras en internet son vídeos con oficinas vacías y cafecito artesanal. La realidad es más desordenada. Hay días buenos de código y días malos de reuniones, y casi nunca son los mismos.

Voy a describirte un día normal de un backend de nivel medio, con dos o tres años de experiencia. No es el día de nadie en particular, pero se parece al de la mayoría.

La mañana: contexto antes que código#

Empiezas abriendo Slack, Teams o lo que use tu empresa. Diez minutos revisando mensajes. Buscas tres cosas: si algo se rompió anoche, si hay despliegues pendientes y si alguien necesita algo de ti.

Luego revisas el tablero. Jira, Linear o una hoja de cálculo, según la empresa. Mueves tus tarjetas, miras qué está bloqueado y decides por dónde atacas hoy.

Después viene la dura realidad: casi ningún día empieza con código limpio. Primero entiendes qué pasó ayer.

El café y el entorno local

Antes de programar, configuras tu entorno. Levantas servicios con Docker Compose o algo similar, te aseguras de que la base de datos local tenga datos de prueba y corres los tests del módulo que vas a tocar. Diez a quince minutos, casi siempre.

Esto no aparece en las descripciones del puesto. Es tiempo real.

Reuniones vs trabajo profundo#

En un equipo sano, tienes una o dos reuniones al día. Daily de quince minutos, quizá un refinamiento los martes, quizá una retrospectiva cada dos semanas. Eso deja tres o cuatro horas de trabajo continuo, que es donde se hace el código.

En un equipo caótico, tienes cuatro reuniones y trozos de veinte minutos entre ellas. Ahí no se programa nada serio. Solo se revisan pull requests y se resuelven dudas.

Mi opinión: si estás evaluando una oferta, pregunta por la cantidad de reuniones. Es el factor que más decide tu productividad y tu nivel de estrés.

La daily, sin adornos

No hablas de lo que hiciste ayer para sonar ocupado. Dices tres cosas y ya. Algo así:

"Ayer terminé el endpoint de cancelación de pedidos y lo desplegué a staging. Hoy voy con la parte de reembolso. Estoy bloqueado en que no tengo acceso al sandbox de la pasarela de pago, ¿alguien me lo puede dar?"

Corto. Concreto. Pidiendo lo que necesitas.

Las herramientas que realmente usas#

Olvida la lista de veinte tecnologías del anuncio de trabajo. En el día a día tocas unas pocas todo el tiempo.

• El editor: VS Code, IntelliJ o Neovim, con extensiones para tu lenguaje.
• Git y la plataforma del repositorio: GitHub, GitLab o Bitbucket.
• El terminal, mucho más de lo que crees.
• Postman, Insomnia o simplemente curl para probar endpoints.
• La consola de logs: Datadog, Grafana, CloudWatch o ELK.
• El cliente de base de datos: DBeaver, TablePlus o psql a secas.
• Docker para levantar servicios locales.
• El chat y el tablero de tareas, que abres más veces de las que quieres.

Si quieres ver cómo encaja tu perfil con lo que piden las ofertas, usa el verificador de compatibilidad con ATS. Te muestra si tu CV pasa el primer filtro automático antes de que lo lea una persona.

El bloque de trabajo profundo#

De diez y media a una, sin reuniones. Este es el tramo bueno. Cierras el chat, te pones auriculares y te metes en una tarea concreta.

Un día normal de trabajo profundo puede ser algo así: implementar la validación de un endpoint, arreglar un bug de concurrencia que solo aparece de vez en cuando, o escribir tests para código que alguien dejó sin cubrir.

La parte que nadie cuenta: la mitad del tiempo no escribes código. Lees código de otros, lees documentación y lees logs. Programar es una actividad de lectura con algo de escritura.

Un ejemplo real de tarea

Digamos que tu ticket dice: "El usuario puede cancelar un pedido dos veces y recibe dos reembolsos".

Primero reproduces el error. Escribes un test que llama a la función de cancelación dos veces seguidas y ves que devuelve dos reembolsos. Luego añades una comprobación de estado: si el pedido ya está cancelado, devuelve un error 409. Vuelves a correr el test, pasa. Actualizas la documentación del endpoint y abres un pull request.

Cuatro horas de trabajo. Quizá veinte líneas de código. Y tiene sentido.

La presión real, sin filtros#

Hay tres fuentes de presión y conviene que las conozcas antes de entrar.

La primera es producción. Si tu servicio se cae a las tres de la tarde, se cae todo lo que depende de él. Hay guardias, on-call, en muchas empresas. Pregunta si las hay y cómo se pagan.

La segunda es la fecha de entrega. Las estimaciones fallan, siempre. Un trabajo de dos días se convierte en diez cuando descubres que el código legacy hace algo raro que nadie documentó.

La tercera es la ambigüedad. Un ticket mal escrito te puede costar más tiempo que el código difícil. Parte de tu trabajo es preguntar hasta que la tarea tenga sentido.

Lo que sorprende a los recién llegados#

Casi nadie empieza construyendo sistemas desde cero. Empiezas manteniendo código que escribió alguien que ya no está en la empresa. Es normal y no es un castigo.

También sorprende la cantidad de comunicación. Correos, mensajes, comentarios en pull requests, revisiones de diseño. Si pensaste que programar era estar solo con los auriculares ocho horas, te llevarás una decepción.

Y hay un tema más: los cambios pequeños dan miedo. Tocar una línea en un servicio que procesa pagos da más nervios que escribir doscientas líneas en un módulo nuevo. La experiencia te enseña a ir con cuidado, no a ir rápido.

El pull request como filtro

Tu trabajo no termina cuando el código funciona. Termina cuando otra persona lo aprueba. Un buen pull request explica qué cambia y por qué, no solo qué hace.

Ejemplo de descripción mala: "Fix cancelación".

Ejemplo mejor: "Evita el doble reembolso al cancelar dos veces. Añado comprobación de estado en el servicio de pedidos y test de regresión. Cierro el ticket PAY-1234."

La segunda versión te ahorra idas y vueltas.

Junior vs senior: cómo cambia el día#

Si eres junior, tu día gira alrededor de tareas acotadas. Te asignan un ticket con un alcance claro, haces el código, pides revisión y aprendes de los comentarios. Pasas mucho tiempo leyendo y preguntando. Es agotador de otra manera.

Si eres senior, tu día tiene más incertidumbre. Diseñas la solución antes de escribir código, revisas el trabajo de otras personas y desbloqueas al equipo cuando alguien se atasca. Escribes menos líneas y decides más cosas.

El salto no es solo técnico. La diferencia está en cómo manejas la ambigüedad y en cuánta responsabilidad tomas sobre el resultado, no solo sobre tu parte.

Para ver qué están pidiendo las empresas según el nivel, echa un vistazo a las ofertas de trabajo en desarrollo backend. Ahí verás cómo varía el rango de responsabilidades entre puestos con nombres parecidos.

Cómo prepararte si estás empezando#

Si quieres llegar con ventaja a tu primer puesto, enfócate en lo siguiente:

• Aprende Git de verdad: ramas, merges, resolver conflictos, rebase básico.
• Practica SQL hasta que las consultas con joins y agregaciones te salgan sin pensar.
• Escribe tests. Aunque sean simples. Es lo que más rápido te da credibilidad.
• Aprende a leer logs y a depurar con el debugger, no solo con console.log.
• Estudia HTTP: métodos, códigos de estado, autenticación, headers.
• Comunica por escrito con claridad. Los mensajes cortos y concretos se agradecen.
• Lee código de proyectos abiertos para acostumbrarte a código que no escribiste tú.

Y cuando prepares tu CV para el primer puesto, usa la herramienta gratuita para comprobar si tu CV pasa el filtro ATS. Te ahorra enviar cien solicitudes que nadie va a leer.

El final del día#

Casi nunca terminas a la hora exacta. Cierras el editor a media tarea, dejas una nota para mañana y apagas. Está bien. El trabajo no se acaba, solo se pausa.

Lo que sí puedes hacer es cerrar bien: deja el código compilando, los tests en verde y una nota clara en el ticket. Tu yo de mañana te lo agradecerá, y tu equipo también.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuánto tiempo de un día real se pasa programando?

Depende del equipo, pero entre tres y cinco horas de trabajo continuo es un buen día. El resto son reuniones, revisiones, mensajes, configuración del entorno y tareas administrativas. Si te dicen que se programa ocho horas seguidas, desconfía.

¿Hay guardias y trabajo nocturnos en backend?

En servicios que están en producción, suele haber guardias. La frecuencia varía mucho: desde una semana cada dos meses hasta rotaciones más exigentes. Pregunta siempre cómo son, cuánto duran y cómo se compensan antes de aceptar una oferta.

¿Qué lenguajes se usan más en el día a día?

Los habituales son Java, Python, Go, JavaScript y TypeScript, C# y Kotlin. El lenguaje importa menos que entender HTTP, bases de datos y cómo se despliega un servicio. Las cifras de uso cambian cada año, así que revisa la fuente oficial más reciente.

¿Es mejor trabajar en una startup o en una empresa grande?

En una startup tocas más partes del sistema y decides más, pero con menos estructura y más caos. En una empresa grande hay más procesos, más especialización y más reuniones. Ninguna es mejor por definición, depende de cómo aprendas tú.

¿Cómo se pasa de junior a senior en backend?

Dejas de esperar tareas claras y empiezas a definirlas. Tomas responsabilidad de extremo a extremo, ayudas a otras personas y reduces la incertidumbre del equipo. Eso se nota en tu trabajo antes que en tu título, y suele tardar varios años.