Desarrollador backend

CRUD, validación, serialización, llamar a un servicio desde otro, y las pruebas de todo ello.

Transacciones, idempotencia, reintentos, orden — decidir qué no puede ser verdad nunca y asegurarse de que nunca lo es.

Diseñar qué se guarda, y migrarlo después sin parar el servicio ni perder nada.

Autorización, fronteras entre inquilinos, qué se escapa en un mensaje de error, y qué expone un endpoint interno si alguien lo encuentra.

Planes de consulta, caché, la factura, y la petición que se puso lenta porque cambió algo aguas arriba.

Guardia: decidir bajo presión de tiempo qué revertir, qué degradar y qué contarle a la gente mientras todavía está roto.

Una estimación interna de Amazon sobre la propia ingeniería de Amazon, publicada por la empresa que vende la herramienta — quien hace el trabajo, quien lo mide y quien lo vende son la misma parte, lo que se dice aquí porque no puede comprobarse desde fuera. La empresa publica además su método: el tiempo ahorrado se estimó a partir del número de dependencias Java migradas, suponiendo un día o más de tiempo de desarrollador por dependencia hecha a mano. Fíjate en qué es la migración: una subida de versión de lenguaje tiene un compilador y una batería de pruebas existente como árbitro, así que el éxito se comprueba a máquina en cada paso — la forma más favorable posible para esta clase de automatización y no un resultado general sobre el trabajo de backend. Y fíjate en qué se afirma y qué no: 4.500 años es trabajo no hecho, más de mil desarrolladores, sin que se diga en ninguna parte que alguno se fuera o que se eliminara un puesto.

Una empresa lo ha puesto en producción. Puede mover la línea de base, ponderado por la escala y por cuánto se parece ese entorno al tuyo.

La mitad visible de este trabajo — endpoints y fontanería — es la mitad expuesta, y es lo que te habrían contratado para hacer. Las partes que aguantan van de qué no puede pasar nunca, y eso se aprende estando presente cuando algo sí pasó. Acércate a un turno de guardia antes de lo que resulta cómodo.

Tu posición es más fuerte que la de la página de frontend en la tarea más expuesta, y la razón no es que el trabajo sea más difícil — es que equivocarse sale caro y no se ve, así que la responsabilidad está concentrada. Vigila el modo de fallo que eso crea: revisar cambios generados en sistemas donde un error es silencioso durante meses.

Quedarte y reforzarte

Ir a donde un error sale caro

Pagos, contabilidad, identidad, cualquier cosa con un regulador — dominios donde un cambio sin vigilancia no está permitido, así que la revisión y la responsabilidad están financiadas y no dadas por supuestas.

Rehacer el puesto

Ser dueño de la frontera que los agentes pueden cruzar

Alguien tiene que decidir qué puede tocar un cambio automatizado en un servicio donde un error es silencioso. En la mayoría de los equipos a nadie se le ha dado eso, y por eso aparece en las revisiones de incidentes en vez de en las descripciones de puesto.

Movimiento lateral

Pasar a trabajo de datos o de plataforma

El razonamiento sobre coherencia, fallos y coste se transfiere directamente, y los dos son sitios donde el mismo criterio se aplica a una superficie más amplia.

Las partes se mueven a velocidades distintas, así que un solo número escondería lo que necesitas. Escribir endpoints es ya en gran medida trabajo de máquina. Decidir qué no puede pasar nunca cuando llegan dos peticiones a la vez, o qué se le permite revelar a un mensaje de error, no se ha movido, porque son posiciones de las que se responde y no de teclear. Una señal que puedes comprobar: cuando algo se rompió el trimestre pasado, ¿la parte difícil fue encontrarlo o decidir qué hacer con ello?

En su tarea más visible está menos expuesto, y la razón conviene entenderla en vez de tomarla como consuelo: la corrección en backend a menudo es invisible y sale cara si falla, así que más parte del trabajo es responsabilidad. Es una diferencia estructural, no un orden de dificultad, y puede cambiar — la mitad de endpoints de este trabajo está expuesta exactamente en los mismos términos que la mitad de frontend.

Para las entrevistas, eso todavía no ha cambiado. Para el trabajo, la división honesta es que recordar un algoritmo importa menos que antes, mientras que razonar sobre fallos importa más — saber qué le hace un reintento a un sistema que ya va apurado es la misma destreza que intentan medir las preguntas de diseño de sistemas, aplicada a algo real. Apréndela de tus propios incidentes y no de una lista.

Ya puede redactar uno, y esa no es la restricción. La restricción es que alguien tiene que garantizar qué no puede hacer nunca, migrar sus datos años más tarde sin perder nada, y estar despierto cuando falle. Son posiciones de responsabilidad, y la responsabilidad no se ha abaratado — en los dominios regulados se ha vuelto más explícitamente obligatoria.