El ingeniero Markus Eliasson narra cómo una falsa alarma de producción en Midsummer le provocó una intensa sensación de culpa y reflexiona a partir de ahí sobre por qué los desarrolladores deberían evitar entregar software que les genere remordimiento. Describe esa culpa como ondas que se propagan cuando algo falla en producción y pueden afectar al trabajo, los ingresos o los clientes de los usuarios. Relata además una experiencia profesional especialmente dura: una release a gran escala que dejó fuera de servicio los puntos de venta de mil tiendas y le obligó a trabajar toda la noche con un colega para revertir los cambios, sin tests automatizados y sin tener claro cuál era la causa raíz.
A partir de esa vivencia, Eliasson propone lo que denomina «desarrollo impulsado por la culpa», un enfoque que se apoya en cuatro pilares: Pensar antes de escribir código, Tipos, Tests y Telemetría. Recomienda compartir las soluciones con un compañero o redactar un documento de diseño para recibir feedback temprano sobre el porqué, la implementación técnica y la compatibilidad. Defiende los lenguajes de tipado estático porque permiten eliminar estados imposibles en tiempo de compilación, frente a la dinámica de duck typing de Python o Clojure, donde la validación llega en tiempo de ejecución y depende de la disciplina del programador. Subraya además el valor de los value objects y las invariantes de tipo para representar conceptos del dominio con mayor seguridad. El conjunto es una guía práctica para entregar software más robusto y, sobre todo, para dormir más tranquilo.