The Pragmatic Programmer: el clásico de oficio, capítulo por capítulo

The Pragmatic Programmer (Andrew Hunt y David Thomas, 1999; edición del 20.º aniversario en 2019) sigue siendo recomendación obligada veinte años después por una razón sencilla: no habla de ningún lenguaje ni framework, habla de una actitud. Es un manual de oficio —setenta consejos, los famosos tips— sobre cómo pensar mientras programas. Esta es la guía completa de sus ideas, organizada como el libro, con la lente de quien construye software para vivir.

Una filosofía pragmática

El libro arranca por la cabeza, no por el teclado. Un programador pragmático asume la responsabilidad de su trabajo: ante un problema, ofrece opciones en lugar de excusas (“provide options, don’t make lame excuses”). No dice “no se puede”; dice “podemos hacer A o B, con estos costos”.

La metáfora más citada del libro es la de las ventanas rotas. En un edificio, una sola ventana rota que nadie arregla manda una señal: aquí no importa el cuidado. Pronto hay más. En código pasa igual: un atajo sucio tolerado le dice al resto del equipo que la calidad no importa, y la decadencia se acelera.

No vivas con ventanas rotas.

El resto de la filosofía completa el carácter: sé un catalizador del cambio (la fábula de la “sopa de piedra”: a veces es más fácil empezar algo pequeño y dejar que los demás se sumen que pedir permiso para todo); cuida la rana hervida (los desastres rara vez llegan de golpe; llegan grado a grado mientras nadie mira el conjunto); persigue software lo bastante bueno (la calidad es una decisión negociada con el usuario, no un absoluto); e invierte en tu portafolio de conocimiento como en uno financiero: con regularidad, diversificando y asumiendo algo de riesgo. La tecnología cambia; el hábito de aprender es lo que te mantiene vigente.

El enfoque: DRY, ortogonalidad y reversibilidad

Aquí están los tres pilares técnicos del libro.

DRY — Don’t Repeat Yourself. Probablemente el principio más famoso que salió de este libro, y el más malentendido:

Cada porción de conocimiento debe tener una representación única, inequívoca y autoritativa dentro del sistema.

DRY no es “no copies y pegues código”. Es sobre conocimiento: una regla de negocio, un formato, una validación, no deberían vivir en tres sitios que se desincronizan en cuanto cambie uno. Dos trozos de código idénticos por casualidad no violan DRY; dos representaciones del mismo hecho sí.

Lo desarrollamos junto a sus matices —y al peligro de aplicarlo de más— en DRY, YAGNI y la regla del Boy Scout.

Ortogonalidad. Diseña componentes independientes: que cambiar uno no obligue a tocar otro. Si mover una pieza rompe tres cosas aparentemente no relacionadas, tu diseño está acoplado. La ortogonalidad reduce el riesgo, facilita las pruebas y permite reutilizar.

Reversibilidad. No hay decisiones finales. El error es comprometerse con una base de datos, un proveedor o una arquitectura como si fuera para siempre. Diseña para poder cambiar de opinión: esconde las decisiones tras abstracciones para que el día que tengas que dar marcha atrás, sea un cambio local y no una reescritura.

Y para arrancar proyectos, el libro propone las balas trazadoras (tracer bullets): en vez de construir el sistema entero a oscuras, dispara primero un esqueleto delgado que atraviese todas las capas de punta a punta y funcione. Luego itera con feedback real, afinando la puntería.

Cuidado con confundirlas con prototipos: el prototipo es desechable (aprendes y lo tiras); la bala trazadora es código real que se queda y crece.

Las herramientas básicas

Un buen artesano domina sus herramientas. Los consejos aquí envejecieron sorprendentemente bien:

• El poder del texto plano. Guarda el conocimiento en formatos legibles y perdurables, no atrapados en binarios propietarios. El texto plano sobrevive a las herramientas que lo crearon.
• Usa control de versiones. Siempre. Para todo, incluso para proyectos de una persona. (En 2026 suena obvio; el libro lo predicaba cuando no lo era.)
• Domina tu editor y tu shell. Las cosas que haces cien veces al día merecen que las hagas rápido y sin pensar.
• Depuración sin drama. Dos tips de oro: arregla el problema, no la culpa (no pierdas energía en de quién fue, resuélvelo) y “select no está roto”: cuando jures que el bug es de la librería, el sistema operativo o el compilador, casi siempre es tuyo. Empieza por ahí. Y cuando te atasques, explica el código en voz alta: el rubber duck debugging salió justo de aquí.

Paranoia pragmática

No puedes escribir software perfecto, así que programa como si todos —incluido tú— fueran a equivocarse.

• Diseño por contrato. Define con precisión qué espera y qué garantiza cada función (precondiciones y postcondiciones). El contrato hace explícito de quién es la culpa cuando algo falla.
• Falla pronto (crash early). Un programa muerto suele hacer mucho menos daño que uno tullido que sigue corriendo con datos corruptos. Es mejor que reviente en el punto exacto del error que descubrir, tres capas y veinte minutos después, un fallo misterioso imposible de rastrear.

• Aserciones. Si algo “nunca puede pasar”, una aserción lo grita en el momento en que pasa. Y termina lo que empiezas: quien abre un recurso (archivo, conexión, transacción) es responsable de cerrarlo.

Doblarse o romperse

Software que no se puede cambiar es software muerto. El libro junta aquí las ideas para mantenerlo flexible:

• Desacopla y respeta la Ley de Demeter (“no hables con extraños”): un objeto debería hablar solo con sus vecinos inmediatos, no encadenar a.b().c().d(). Cada eslabón de esa cadena es una dependencia oculta que te ata.
• Composición sobre herencia. El libro habla del “impuesto de la herencia”: las jerarquías profundas acoplan y se vuelven rígidas. Componer piezas pequeñas suele envejecer mejor.
• Configura, no incrustes. Lo que cambia entre entornos o clientes va en configuración, no clavado en el código.

Mientras programas

El corazón práctico del libro:

• No programes por coincidencia. Si tu código “funciona” pero no sabes por qué, no funciona: tienes una bomba de tiempo. Programa deliberadamente, entendiendo cada pieza. (El primo cercano del cargo cult: copiar lo que parece funcionar sin entenderlo.)
• Refactoriza pronto y seguido. El refactor no es un proyecto que pides permiso para hacer una vez al año; es como la jardinería, constante. Cuando veas código que pide mejora y tengas las pruebas para hacerlo seguro, hazlo ya.
• Prueba tu software, o lo harán tus usuarios. Una idea preciosa del libro: una prueba es el primer usuario de tu código. Escribir el test te obliga a usar tu propia API y a sentir si es incómoda antes de que la sufra alguien más.
• Nombra bien. Los nombres cargan intención; un mal nombre miente. Y cuando un nombre deje de encajar, renómbralo — no lo arrastres.

Antes del proyecto y equipos pragmáticos

El libro cierra subiendo de la línea de código al proyecto:

• No “recolectes” requisitos: excávalos. Los requisitos no están esperando ordenados para que los recojas; se aprenden. El trabajo es ayudar a la gente a entender lo que de verdad quiere, no transcribir lo que pide.
• Encuentra la caja, no pienses “fuera de la caja”. Ante un problema “imposible”, la solución suele estar en identificar las restricciones reales (y descartar las imaginarias), no en ignorarlas.
• Equipos pragmáticos. Todo lo individual escala al equipo: nada de ventanas rotas colectivas, comunicación clara, y un kit de arranque no negociable — control de versiones, pruebas y automatización desde el día uno.
• Los cocos no bastan. Una advertencia explícita contra el cargo cult: adoptar los rituales de los equipos exitosos (sus stand-ups, sus herramientas) sin entender qué los hacía funcionar.
• Firma tu trabajo. Los artesanos firmaban sus obras. Siéntete dueño de lo que entregas y ponle tu nombre con orgullo. El cuidado se nota.

Por qué sigue vigente

Veinte años después, los ejemplos del libro envejecieron pero las ideas no, porque atacan lo que no cambia: la tentación de tomar atajos, de copiar sin entender, de tratar el código como algo desechable. Es el mismo criterio que recorre los principios de Uncle Bob y la simplicidad de KISS: hacer las cosas con oficio no es lentitud, es lo que hace que el software siga vivo dentro de cinco años.

Para nosotros esto no es teoría de librería. Es la diferencia entre software a medida que aguanta y código que hay que tirar en dos años. Si quieres que quien construya el tuyo trabaje con este criterio, hablémoslo.

Referencias

• Andrew Hunt & David Thomas — The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999) y The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition (2019). Editorial del autor: pragprog.com.
• La lista completa de los 70 tips circula como “Pragmatic Programmer Quick Reference”.
• Robert C. Martin — Clean Code (principios hermanos: ventanas rotas, regla del Boy Scout).
• Ward Cunningham — deuda técnica (relacionado con las ventanas rotas).