There's a classic programming text called *"How To Write Unmaintainable Code"*, written by Roedy Green in the 90s. The premise is brilliant: using sharp irony, he teaches how to write code so chaotic that only the original author can maintain it. The goal, he claims, was to guarantee lifetime employment. But read in reverse, the text is one of the best practical guides to software best practices ever written. Here's what it actually teaches, beneath the sarcasm: **On naming variables and functions** He suggests using names without vowels, random abbreviations, and variables that differ by just one character, like `swimmer` and `swimner`. The real message: a good name is one you read once and immediately understand. Clarity isn't a luxury, it's respect for whoever comes after you, and that person is often yourself, six months later. **On comments** The ironic tip is to comment the obvious (`/* adds 1 to i */`) and never document what actually matters: the overall purpose of a method, the units of measure for variables, edge cases. A good comment doesn't describe the *what*. It describes the *why*. **On code duplication** He recommends copy, paste, and modify instead of creating reusable modules. It saves time now and guarantees that any future change needs to be made in 25 different places, with no map. No duplication is harmless. **On exceptions and errors** The sarcastic suggestion is to skip error handling because "well-written code never fails." Anyone who has ever had to trace a production bug with no useful logs knows the price of that philosophy. **On the bigger picture** The most serious passage in the text appears near the end. Roedy points out that programming languages are designed by the people who write compilers, but maintained by thousands of other developers who never have a voice in the design. There's a real tension between theoretical elegance and day-to-day practicality. The solution isn't to accept chaos, it's to adopt conventions that make code readable to humans, not just machines. **What to take away from all this** Code is communication. You write it once, but other people read it dozens of times. Every shortcut you take today becomes technical debt tomorrow. And the worst part of technical debt isn't the time it steals: it's the trust it erodes, both in the codebase and in the team. Roedy's text is over 25 years old and remains unsettlingly relevant. The full read is worth it. --- *Source: [How To Write Unmaintainable Code](https://www.doc.ic.ac.uk/~susan/475/unmain.html), Roedy Green*