Reseña: 'The Pragmatic Programmer' en 2025
Un clásico de 1999 que aguanta mejor que muchos libros de tecnología publicados este año. Por qué sigue siendo lectura obligatoria y qué ha envejecido mal.
The Pragmatic Programmer fue publicado en 1999 por Andrew Hunt y David Thomas. Han pasado 26 años. En términos de tecnología, eso es una eternidad. Ruby no existía. Python tenía 8 años y era un lenguaje de nicho. JavaScript era para hacer rollovers en imágenes. Y sin embargo, abrí la edición de 2019 (el 20 aniversario, bastante revisada) y encontré consejos más aplicables que en la mayoría de libros publicados el año pasado.
Eso merece exploración.
Qué ha envejecido bien (mucho)
El núcleo del libro son principios que trascienden tecnologías específicas. El más famoso: DRY (Don’t Repeat Yourself). No es sobre código, es sobre conocimiento. Cada pieza de conocimiento debe tener una representación única, inequívoca y autoritativa en un sistema. Violar DRY produce sistemas que divergen silenciosamente. Sigue siendo verdad.
Ortogonalidad es quizás el concepto más infrautilizado del libro. Dos cosas son ortogonales si cambiar una no afecta a la otra. Un sistema ortogonal es más fácil de mantener, testear y extender. El nombre es rarísimo pero el concepto es fundamental y lo veo violado constantemente en código profesional.
Tracer bullets (balas trazadoras) — la idea de construir rápido end-to-end aunque sea con funcionalidad mínima, para validar que todas las capas conectan correctamente, sigue siendo superior a construir cada capa perfectamente en aislamiento. Esto es básicamente lo que llamamos ahora MVP o walking skeleton, pero mejor explicado.
El catálogo de consejos más útiles (mi selección)
Si tuviera que priorizar los consejos del libro para alguien que empieza:
// Utilidad percibida por consejo (valoración personal 1-10)
Broken windows theory aplicada al código: no dejes código malo sin arreglar aunque no toque la tarea que estás haciendo. La degradación del código es acumulativa y la permisividad inicial normaliza el deterioro. Lo he visto pasar en cada equipo en el que he trabajado.
Qué ha envejecido peor
La sección de herramientas de texto plano ha envejecido de forma interesante. El consejo de “usa text files para todo porque duran forever” es correcto en espíritu pero en 2025 hay mejores herramientas que plain text para muchas cosas. La obsesión con vi/emacs como editores universales se siente anacrónica.
El capítulo de testing está anticuado. El libro predice TDD pero no lo explica bien, y el ecosistema de testing ha madurado tanto desde 1999 que necesitarías otro libro entero.
La parte de arquitectura es superficial para los estándares actuales. En 1999 no había microservicios, Kubernetes ni cloud computing. Falta mucho contexto que hoy es básico.
Conclusión: ¿lo recomiendo?
Sí, con matices. Si llevas menos de 5 años programando, léelo entero. Te dará un vocabulario y un framework mental que la mayoría de recursos online no te dan.
Si llevas más tiempo, re-léelo. Te sorprenderá cuántos de los problemas que ves en tu trabajo diario están descritos en sus páginas, y cuántos de los consejos que “ya sabes” no estás aplicando.
Lo que no es: un libro sobre tecnologías específicas. No te enseña React, ni Docker, ni nada concreto. Te enseña a pensar sobre software, y eso tiene una vida útil mucho más larga.
Puntuación: 8.5/10. Media un punto de menos por el envejecimiento de algunas partes técnicas. Sigue siendo lectura obligatoria.