Ingeniero Backend: Dominá el backend y te volvés el ingeniero sin el que ningún equipo se banca quedarse. El que se gana la confianza, las mejores ofertas y la libertad de trabajar desde donde quiera.

Description

PYTHON: Volvete la habilidad que las empresas siguen pagando cuando la IA escribe el código, el que caza los bugs que corren pero están mal antes de que lleguen a producción

Este libro te entrena para ser el revisor de Python vibe-codeado, no para memorizar el lenguaje. Arranca desde una premisa distinta a la de cualquier otro libro de Python: el agente escribe el código, y tu palanca es entender qué hace ese código en realidad para poder revisarlo con el criterio que el intérprete no tiene. Vas a aprender a qué se liga en realidad un nombre y por qué el aliasing y la mutabilidad causan los bugs que causan, qué verifica y qué no verifica un type hint, qué está haciendo en realidad el event loop detrás de async y await, por qué el global interpreter lock hace que tus threads no sean el paralelismo que creés, qué hacen realmente un ORM y un pool de conexiones, y cómo las piezas se integran en un servicio que corre, y vas a aprender todo eso como lo necesita un revisor: leyendo código real que el agente generaría y decidiendo qué está bien, qué es plausible pero peligroso y qué hay que devolver. La progresión va de revisar un solo objeto y un solo nombre, a revisar un componente como la capa de datos o el pipeline de requests, a revisar cómo encaja todo el sistema y dónde se va a romper bajo carga real. Acá casi no hay ejercicios de sintaxis y sí mucho sobre el modelo de objetos, concurrencia, fallas y las formas específicas en que el Python de un agente sale mal. Para ingenieros que van a vibe-codear en Python de todas formas y quieren ser los que cazan lo que se le escapó al modelo.

AWS: Pasá del ingeniero que despliega nubes al que las aprueba, el que ascienden y pagan más por ver lo que un agente de IA deja pasar

Este libro te entrena para ser el revisor de AWS vibe-codeado, no para memorizar la consola. Arranca desde una premisa distinta a la de cualquier otro libro de AWS: el agente escribe la infraestructura, y tu palanca es entender los servicios lo suficiente como para juzgar la arquitectura, el costo y el blast radius con las tres preguntas que el agente nunca hace. Vas a aprender qué son en realidad los servicios centrales y cuándo cada uno es la herramienta correcta, EC2 y Lambda y las opciones de contenedores para cómputo, S3 y RDS y DynamoDB y ElastiCache y Redshift para almacenamiento y datos, Athena y OpenSearch para analítica y búsqueda, SQS y SNS y SES para desacoplar y mandar correo, y Bedrock para IA, y vas a aprender las bases que deciden si algo de eso es seguro y barato, el least privilege de IAM, la VPC y dónde va cada capa, cómo se arma un endpoint HTTPS de verdad con Route 53 y un certificado y un balanceador, y cómo leer una factura antes de que llegue. Cada capítulo diseña una pieza real de un sistema que funciona, da una estimación de costo ilustrativa y muestra la arquitectura buena-contra-mala que un agente produciría, construyendo desde un solo servicio hasta un diseño completo expresado como infraestructura como código revisable con el CDK. Acá casi no hay clicks en la consola y sí mucho sobre costo, seguridad, datos y las formas específicas en que el cloud de un agente sale mal. Para ingenieros que van a vibe-codear en AWS de todas formas y quieren ser los que cazan el diseño que los iba a filtrar, romper o fundir.

GCP: Leé la nube que armó un agente de IA y volvete el ingeniero al que pagan más y le confían producción, no el que sube una sorpresa de cinco cifras.

Este libro te entrena para ser el revisor de Google Cloud vibe-codeado, no para memorizar la consola. Arranca desde una premisa distinta a la de cualquier otro libro de nube: el agente escribe la infraestructura, y tu palanca es entender qué hace en realidad la plataforma para poder revisarlo con el criterio que la nube no tiene. Vas a aprender qué evalúa en realidad IAM y por qué el mínimo privilegio es todo el juego, qué significan de verdad el plan y el state de Terraform y por qué revisar el plan no es negociable, cómo Cloud Run escala, hace cold start y factura, qué te obliga a manejar la entrega at-least-once de Pub/Sub, cómo elegir entre Cloud SQL, Firestore y un cache Redis según el patrón de acceso, por qué BigQuery factura por byte escaneado, y qué son en realidad los embeddings, un índice vectorial y la memoria de un agente, y vas a aprender todo eso como lo necesita un revisor: leyendo el Terraform, la política de IAM y la config de servicios reales que generaría un agente, con una aplicación de ejemplo diseñada a lo largo de los capítulos y un modelo de costos para cada servicio, decidiendo qué está bien, qué es plausible pero peligroso y qué hay que devolver. La progresión va de revisar un solo recurso y sus permisos, a revisar un servicio y sus capas de datos y de IA, a revisar toda la arquitectura por seguridad, costo y falla bajo carga. Acá casi no hay click por click y sí mucho sobre identidad, redes, costo y las formas específicas en que la nube de un agente sale mal. Para ingenieros que van a vibe-codear en Google Cloud de todas formas y quieren ser los que cazan lo que se le escapó al modelo.

SQL: Volvete la habilidad que las empresas siguen pagando cuando la IA escribe las queries, el que caza el SQL que corre limpio pero devuelve la respuesta equivocada

Este libro te entrena para ser el revisor de SQL vibe-codeado, no para memorizar la sintaxis. Arranca desde una premisa distinta a la de cualquier otro libro de SQL: el agente escribe las queries, y tu palanca es entender qué hace en realidad la base de datos para poder revisarlo con el criterio que el motor no tiene. Vas a aprender por qué una tabla relacional es un conjunto y por qué pensar en conjuntos es todo el juego, el orden en que el motor evalúa de verdad una query, cómo se ejecutan realmente los joins y los índices y cuándo un índice es inútil, la lógica de tres valores que hace del NULL el bug de resultado-silenciosamente-incorrecto más común en SQL, cómo leer un plan de ejecución como la verdad de fondo que la query esconde, y cómo se comportan las transacciones, el aislamiento y las migraciones bajo concurrencia y escala reales, y vas a aprender todo eso como lo necesita un revisor: leyendo queries reales que el agente generaría y decidiendo qué está bien, qué es plausible pero peligroso y qué hay que devolver. La progresión va de revisar una sola query y un solo índice, a revisar un esquema y sus restricciones, a revisar cómo se comporta toda la carga de trabajo bajo presión y dónde se va a romper. Acá casi no hay ejercicios de sintaxis y sí mucho sobre el modelo relacional, la ejecución de queries, la integridad de los datos y las formas específicas en que el SQL de un agente sale mal. Para ingenieros que van a vibe-codear SQL de todas formas y quieren ser los que cazan lo que se le escapó al modelo.

DJANGO: Volvete el revisor que caza el Django que un agente de IA dejó corriendo limpio pero mal, ese en quien tu equipo confía antes de subir a producción.

Este libro te entrena para ser el revisor de Django vibe-codeado, no para memorizar el framework. Arranca desde una premisa distinta a la de cualquier otro libro de Django: el agente escribe el código, y tu palanca es entender qué hace ese código en realidad para poder revisarlo con el criterio que el framework no tiene. Vas a aprender qué hace Django en realidad con un request mientras cruza el stack de middleware, qué hacen de verdad el ORM y un QuerySet y exactamente cuándo una query pega contra la base de datos, qué es una migración y cuáles son peligrosas, cómo Django REST Framework convierte un request en una respuesta serializada, dónde van en realidad la validación y los permisos, y cómo se comportan los settings, las transacciones y las señales bajo carga, y vas a aprender todo eso como lo necesita un revisor: leyendo código real que el agente generaría y decidiendo qué está bien, qué es plausible pero peligroso y qué hay que devolver. La progresión va de revisar un solo modelo y una sola query, a revisar un componente como el serializer o la capa de autenticación, a revisar cómo encaja todo el sistema y dónde se va a romper bajo carga real. Acá casi no hay ejercicios de sintaxis y sí mucho sobre el ORM, la integridad de los datos, la seguridad y las formas específicas en que el Django de un agente sale mal. Para ingenieros que van a vibe-codear en Django de todas formas y quieren ser los que cazan lo que se le escapó al modelo.

PYTEST: Construí una suite de pytest en la que confiás para cambiar el código sin contener la respiración y atrapar tus bugs antes que los usuarios

Esta guía te muestra cómo construir una suite de pytest que se gana su lugar, la que te deja cambiar el código sin contener la respiración. Arranca desde tu primer test como función simple y el bug que atrapa, y después suma las partes que hacen que una suite sea rápida, legible y confiable a escala: cómo estructurar los tests y usar aserciones que se explican solas, cómo los fixtures le dan a cada test un mundo limpio y aislado y cómo darles scope y compartirlos sin acoplar, cómo parametrizar un test sobre muchos casos en vez de copiar y pegar, cómo mockear y parchear las piezas lentas o externas (y cuándo no), cómo medir cobertura sin perseguir el número, y cómo enganchar la suite en CI para que un test en rojo frene un mal merge. El libro no te tira una pared de plugins para memorizar. Te enseña a escribir tests que de verdad aguantan, a leer una falla y rastrearla hasta su causa, y a mantener la suite lo bastante rápida como para que vos y tu equipo de verdad la corran. Para ingenieros que ya saben escribir el Python y ahora quieren una red de seguridad en la que confían debajo.

API REST: Volvete el ingeniero que arma la API que otros equipos usan durante años, el diseño que te vuelve imposible de ignorar

Este libro te enseña a diseñar APIs REST como un contrato del que otros ingenieros dependen, no como una pila de endpoints que cada uno tuvo sentido local. Arranca desde REST como modelo (recursos, no acciones, y lo que eso te da) y construye el criterio de diseño que hace una API predecible: modelar recursos y sus relaciones, usar los métodos HTTP y los status codes por lo que de verdad significan, nombrar y estructurar las URLs para que un desarrollador pueda adivinar el próximo endpoint, y devolver errores que un cliente de verdad pueda manejar. Después cubre las partes que separan un juguete de una API de producción: paginación, filtrado y orden que no se caen con una colección grande, validar la entrada y nunca confiar en el cliente, autenticación y autorización bien hechas (tokens, scopes, y no filtrar datos entre usuarios), idempotencia para que un request reintentado no cobre dos veces, y rate limiting y caché para que la API siga en pie. Los capítulos más difíciles son sobre el contrato en el tiempo: versionar sin romper a todos los clientes, evolucionar una API agregando en vez de cambiando, documentarla para que la gente no tenga que leer tu código, y la disciplina de que un endpoint público es una promesa que tenés que cumplir. Los ejemplos son una API real, mostrada diseñada mal y después bien. Para ingenieros backend que quieren construir una API que otros estén contentos de usar y que no tengan que reescribir en un año.

FASTAPI: Construí el servicio de FastAPI que sigue en pie cuando llega el tráfico de verdad, y volvete el ingeniero al que le confían producción.

Este libro te enseña a construir un servicio de FastAPI como se supone que se construye, para que obtengas la velocidad, la seguridad y las docs automáticas que promete el framework en vez de un servicio que te pelea. Arranca desde qué es de verdad FastAPI (una app ASGI donde los type hints de Python manejan la validación, la serialización y la documentación) y construye desde ahí: las path operations y qué hacen los decoradores, los modelos de Pydantic como el contrato de cada request y response (y por qué un response model separado evita que se filtren los campos de tu base de datos), y los parámetros, bodies y validación hechos de forma declarativa en vez de a mano. Va a fondo en las dos cosas que la gente hace mal: el async y el event loop (cuándo el async de verdad ayuda, por qué una sola llamada bloqueante envenena al worker entero, y cómo correr trabajo síncrono sin congelar el servidor), y la inyección de dependencias (la mejor función de FastAPI para compartir sesiones de base de datos, autenticación y configuración de forma limpia en vez de repetirla en cada ruta). Después construye el servicio real: estructurar una app que crece, hablar con una base de datos sin bloquear, autenticación y autorización con tokens y scopes, background tasks y middleware, manejo de errores que devuelve un contrato limpio, y configuración y secretos hechos una vez. La segunda mitad es producción: testear con el TestClient, las docs OpenAPI autogeneradas y cómo mantenerlas honestas, y desplegar con uvicorn y workers de gunicorn sin perder performance. Los ejemplos son una API real, mostrada construida mal y después bien. Para ingenieros de Python que quieren un servicio de FastAPI rápido de verdad, bien tipado y seguro de sacar a producción.

MICROSERVICIOS: Volvete el arquitecto que parte un sistema para que los equipos entreguen sin pisarse, el criterio de diseño que las empresas pagan como a un senior.

Este libro te enseña a diseñar y operar microservicios que de verdad te compran la independencia que prometen, en vez de un monolito distribuido que tiene todos los costos de los servicios y ninguno de los beneficios. Arranca desde la única pregunta honesta (si de verdad los necesitás, y qué hace mejor un monolito) y la que decide todo lo demás: dónde dibujar los límites de servicio, alrededor de capacidades de negocio y de los ejes del cambio en vez de alrededor de tablas, para que un cambio típico toque un servicio y no siete. Construye la capa de comunicación con cuidado: las llamadas síncronas y sus modos de falla, la mensajería asíncrona y orientada a eventos y por qué desacopla los servicios, y los patrones que los mantienen honestos (timeouts, reintentos con backoff, idempotencia, circuit breakers, y el callejón sin salida de las transacciones distribuidas frente al patrón saga). Encara los datos de frente: una base de datos por servicio, por qué una base de datos compartida reacopla todo, y cómo mantener los datos consistentes entre servicios sin una transacción global. Después se pone operativo, porque ahí se ganan o se pierden los microservicios: cómo un request encuentra un servicio, el API gateway, la observabilidad sobre una llamada que cruza diez servicios (tracing, correlation ids, y los logs en los que vas a vivir), versionar un contrato sin romper a los consumidores, y testear un sistema que no podés correr entero en tu laptop. Cierra con la migración: estrangular un monolito una capacidad a la vez en vez de una reescritura. Los ejemplos son un sistema real, mostrado partido mal y después bien. Para ingenieros que quieren servicios que puedan cambiar de forma independiente, no un monolito desparramado por la red.

COLAS DE MENSAJES: Volvete el ingeniero al que le confían el pipeline que nunca pierde un pago ni lo cobra dos veces, el que duerme tranquilo cuando sube la carga.

Este libro te enseña a construir sistemas asíncronos y orientados a eventos sobre colas y brokers en los que de verdad podés confiar, en vez de unos que pierden trabajo, lo procesan dos veces, o se caen bajo carga. Arranca desde por qué recurrís a una cola (desacoplar, amortiguar un pico, y hacer trabajo lento fuera del camino del request) y el costo que tomás: cambiaste una llamada síncrona simple por un sistema con nuevos modos de falla. Construye primero el modelo central, el producer, el broker, el consumer, y el hecho que explica la mayoría de los bugs: los brokers reales entregan al menos una vez, no exactamente una, así que tu handler tiene que ser idempotente o vas a cobrar dos veces en la reentrega inevitable. Cubre las garantías en términos claros (el orden y por qué es solo por partición o por cola, los acknowledgements y cuándo un mensaje de verdad terminó, la durabilidad y qué sobrevive a una caída del broker) y los patrones que mantienen honesto a un sistema: consumers idempotentes, dead-letter queues para mensajes veneno, reintentos con backoff, y el patrón outbox para publicar un evento y commitear un cambio de base de datos de forma atómica. Pone las herramientas principales con honestidad (Kafka para un log durable y ordenado y streaming de eventos, RabbitMQ para ruteo flexible, SQS para una cola gestionada, Celery para colas de tareas en Python) para que elijas por el trabajo. La segunda mitad es operarlo: backpressure cuando los producers superan a los consumers, monitorear la profundidad de la cola y el lag del consumer antes de que sea una caída, y el procesamiento exactly-once como un efecto que vos diseñás, no un casillero que tildás. Los ejemplos son un pipeline real, mostrado perdiendo y duplicando trabajo y después hecho confiable. Para ingenieros backend que quieren sistemas async que entreguen cada mensaje exactamente una vez en efecto, aunque el broker no lo haga.

DISEÑO DE SISTEMAS: Volvete el ingeniero al que le confían el diseño del sistema, el que sabe qué tradeoff tomar y dónde exactamente se va a romper

Este libro te enseña a diseñar sistemas con el criterio que de verdad necesita un ingeniero senior o un líder, no un catálogo de diagramas para recitar. Arranca desde el único primer paso honesto, conseguir los requisitos reales y los números (cuántos datos, cuántos requests, qué tan rápido, qué tan consistente tiene que ser) porque toda decisión de diseño después de eso es un tradeoff al servicio de esos números, y un diseño sin ellos es decoración. Construye el toolkit central y, más importante, cuándo cada herramienta es correcta y cuándo es un error: escalar para arriba versus para los lados, balanceo de carga, caché y los bugs que esconde, las elecciones de base de datos y por qué la base de datos suele ser el cuello de botella, replicación y sharding y qué te cuestan, y colas y trabajo asíncrono para absorber la carga. Encara los tradeoffs de frente, porque a un senior le pagan por esto: consistencia versus disponibilidad y qué significa CAP de verdad en la práctica, latencia versus throughput, y la verdad de que todo caché y toda réplica compran velocidad con una factura de consistencia. Diseña para la falla como default (redundancia, degradación elegante, timeouts y reintentos, los puntos únicos de falla que tenés que encontrar antes de que te encuentren) y para la observabilidad para que puedas ver el sistema que construiste. La segunda mitad es el oficio del trabajo: estimar la capacidad en el reverso de un sobre, leer un diseño buscando dónde se rompe con diez veces la carga, evolucionar una arquitectura sin una reescritura, y comunicar un diseño para que un equipo pueda construirlo. Los ejemplos son sistemas reales, diseñados por reflejo y después con criterio. Para ingenieros que entran en el rol donde la arquitectura es suya para hacerla bien.

CLAUDE: Dejá de usar Claude Code como un chat que de paso escribe código. Manejalo como el ingeniero agéntico que es, en la terminal, tu editor, el escritorio y el CI, y va a entregarte un día de laburo en una hora sin dejarte un despelote atrás

Esta guía enseña la habilidad duradera detrás de Claude Code: no una lista de features que para el trimestre que viene ya cambiaron, sino cómo manejar una herramienta agéntica de programación para que haga trabajo real en el que podés confiar. Arranca donde está el dolor (el día que te salvó y el día que te quemó) y después recorre los siete movimientos que separan al que opera del que la herramienta pasa por arriba. Vas a configurarla en todos los entornos y saber cuándo ir a la terminal, cuándo a tu editor, cuándo al escritorio y cuándo al navegador. Vas a darle el contexto una vez (un archivo de memoria del proyecto, el repo, un plan acordado antes de que toque el código) para que deje de repreguntar y de adivinar. Vas a manejar una sola tarea como corresponde, leyendo el diff y guiando, para que un buen cambio nunca se vuelva un desparramo malo. Vas a poner los permisos para que vuele en lo seguro y frene en lo peligroso, y decidir qué autoaprobar y qué frenar. Vas a correr trabajo en paralelo (subagentes, varias sesiones, worktrees aislados) sin que las piezas choquen. Vas a extenderla con los conectores, los hooks y los comandos que la hacen encajar en tu stack. Y vas a meterla en el CI para que revise, arregle y responda issues sola mientras no la mirás. Cierra con en quién te convertís cuando todo esto es automático: el ingeniero que entrega más, confía en lo que sale y vale más porque la máquina le multiplica el criterio en vez del despelote. Para el ingeniero que quiere que Claude Code se sienta una palanca, no una tragamonedas.

RESPONSABILIDAD: Volvete el ingeniero al que le confían eso que no puede fallar: te hacés cargo del resultado y no solo de tu ticket, llevás cada problema hasta la causa de fondo y hasta cerrarlo, y no dejás que nada se pierda mientras estás vos a cargo

Este libro trata sobre el único rasgo que decide si te dan el trabajo que importa: la responsabilidad, el hábito de tomar un problema como tuyo y llevarlo hasta un resultado real, no solo hacer tu parte asignada y cruzar los dedos para que el resto salga bien. Arranca desde una verdad incómoda. No tener la culpa no es lo mismo que ser útil, y cerrar tu ticket no es lo mismo que resolver el problema, y toda la industria asciende en silencio por lo segundo mientras le pone nota a los juniors por lo primero. Después te da los hábitos, uno por uno, que separan al ingeniero al que le confían lo importante del que siempre está técnicamente sin culpa. Vas a aprender a decir yo me encargo y referirte al resultado entero, a perseguir una falla hasta su causa real en vez de parchar el síntoma, a arreglar el problema en vez de salir a cazar a quién echarle la culpa, a llevar un tema hasta el final en vez de tirarlo por encima de la pared, a cerrar el círculo para que la gente sepa que de verdad quedó, y a hacerte cargo del seguimiento aburrido y de la grieta que no es trabajo de nadie, incluida la falla que es tuya para arreglar y aprender. Cada hábito viene con un ejercicio que podés hacer esta semana y una imagen clara de cómo se ve cuando está bien, contado a través del arco de un ingeniero que va del que señalaba culpables al que le entregan lo que no puede fallar. Cierra con lo que cambia cuando los problemas dejan de escaparse por las grietas porque son tuyos: te volvés la persona que ascienden, a la que le pagan más, y a la que le confían el trabajo que decide todo. Para el ingeniero cansado de hacer su parte y ver a otro llevarse el crédito por ser dueño del resultado.

OFICIO: Escribí código que sobreviva a su propio segundo año y volvete el ingeniero al que el equipo le confía los sistemas que importan, el criterio que separa a alguien que programa de alguien a quien le pagan por diseñar

Este libro te enseña el oficio que hay debajo del código: cómo escribir software que se mantiene legible, cambiable y confiable mucho después de salir a producción, para que te vuelvas el ingeniero al que el equipo le confía los sistemas que importan. Trabaja una sola base de código en marcha, Tessera, un servicio de pedidos y facturación que arrancó limpio y se pudrió, y la reconstruye hasta devolverle la salud mientras te enseña las movidas que mantienen el código blando: nombres que dicen la verdad, funciones que hacen una sola cosa nombrable, comentarios que no mienten, matar la duplicación que arreglás en cuatro lugares y te comés el quinto, y refactorizar seguro detrás de tests para cambiar la forma sin romper el comportamiento. Se apoya abiertamente en el canon del campo, Clean Code de Robert Martin, The Pragmatic Programmer de Hunt y Thomas, y Refactoring de Martin Fowler, y convierte sus principios en hábitos que aplicás en tu próximo pull request: manejar el acoplamiento para que un cambio deje de tocar cinco archivos, manejar la falla para que no se vuelva un misterio a las 3 de la mañana, y tomar deuda técnica a propósito en vez de que ella te tome a vos. Para el desarrollador cansado de temerle a su propio código que quiere escribir del tipo que otros heredan con gusto.

ENTREVISTAS: Convertí la habilidad que ya tenés en la oferta, y dejá de ver cómo contratan a ingenieros peores que vos solo porque entrevistan mejor

Esta guía trata la entrevista como lo que es, una habilidad aparte que se aprende, y te entrena para convertir la capacidad que ya tenés en ofertas. Sigue a una candidata a través de un loop real y enseña cada etapa: qué mide la entrevista de verdad (no es coding puro), el puñado de patrones detrás de la mayoría de las preguntas de estructuras de datos, cómo pensar en voz alta para que el entrevistador siga tu mente en lugar de adivinarla, cómo correr una ronda de coding desde clarificar el problema hasta nombrar los casos borde, y un framework de system design que encaja en casi cualquier consigna para que dejes de improvisar. Se apoya en los estándares del rubro, Cracking the Coding Interview de Gayle Laakmann McDowell y System Design Interview de Alex Xu, y suma lo que ellos saltean: estimación a ojo sin pánico, respuestas de comportamiento que aterrizan sin sonar recitadas, el take-home que te lleva a la ronda siguiente, entrevistar cruzando una pantalla y una frontera, y negociar la oferta sin perderla. Para el ingeniero fuerte cansado de que lo pasen por arriba en la entrevista y que quiere el puesto, el nivel y el sueldo que su habilidad ya se ganó.