Severity: Critical — The Everyday Fibs of Software Engineering, Ranked by Eventual Damage
Photo: office whiteboard sticky notes developer team meeting humor, via thumbs.dreamstime.com
Let's get one thing straight: no one in software engineering lies. We simply make forward-looking statements under conditions of extreme uncertainty, in the same way that meteorologists don't "lie" about sunshine. But when those statements come due — and they always come due — the resulting damage varies wildly. What follows is a rigorous taxonomy of the profession's most beloved fibs, complete with severity ratings. Print it out. Put it in the break room. Frame it in the incident review room.
1. "It's a Quick Fix"
Frequency: Constant. Hourly, during sprint reviews. Severity: 🔴 Critical
The king. The emperor. The lie that launched a thousand Friday-night incidents. "It's a quick fix" is spoken with total sincerity and zero data. The fix is quick in the developer's mental model of the codebase, a model that was last updated in 2019 and does not reflect the 40,000 commits made since.
The reckoning: The "quick fix" touches a shared utility function used by the billing system, the reporting pipeline, and one cron job nobody remembers writing. Three weeks later, finance asks why an invoice printed in Vietnamese. Nobody connects it back. Nobody ever does.
2. "I'll Add Tests Later"
Frequency: Every single commit that isn't fully covered. Severity: 🟠 High
"Later" is not a date. "Later" is not a sprint. "Later" is a spiritual concept, like karma. The tests will be written in the same universe where you finally organize your desktop downloads folder.
The reckoning: Two years later, a new hire asks why this module has no tests. The original author — you — is now the person who has to either admit the truth or mumble something about "the migration." You choose the migration. There was no migration.
3. "I've Read the Documentation"
Frequency: High, concentrated around new framework adoption. Severity: 🟡 Moderate
You have read the documentation the way tourists have "seen" the Louvre: briskly, in passing, while thinking about lunch. You skimmed the quickstart, vibes-read the API reference, and are now building production infrastructure on a feature that was deprecated in the paragraph you skipped.
The reckoning: A Stack Overflow answer from 2021 saves you, which is its own indictment.
4. "It Works on My Machine"
Frequency: Situational, peaking during demos. Severity: 🟠 High
Technically true. Devastatingly incomplete. Your machine is a museum of accidental state: three versions of Node, an environment variable set in 2021 during a different crisis, and a node_modules folder older than some of your coworkers.
The reckoning: Production, which is not your machine, which was the entire point.
5. "I'm Almost Done"
Frequency: Daily, especially in standups. Severity: 🟠 High
"Almost" is doing heroic work in this sentence. You are almost done in the sense that the remaining work is 90% of the work. The happy path is complete; the happy path is 10% of the path.
The reckoning: The demo. Specifically, the moment someone in the demo asks, "What happens if the field is empty?"
6. "That's Technical Debt, We'll Clean It Up Next Quarter"
Frequency: Quarterly, like a ritual. Severity: 🔴 Critical
A statement of intent dressed as a plan. The team knows, on some level, that next quarter's priorities will be set by the same forces that set this quarter's, and those forces have never once chosen "cleanup."
The reckoning: A full rewrite, proposed by someone who wasn't there, funded by someone who wasn't told, built by someone who is currently updating their résumé.
7. "Yes, I Code-Reviewed It"
Frequency: Every Friday at 4:45 PM. Severity: 🔴 Critical
You looked at the diff. The diff was 900 lines. You approved it with the speed and scrutiny of a TSA agent at 6 PM. Your LGTM is a legal signature on a document you did not read.
The reckoning: The bug ships, and the git blame points directly at your approval like a bloodhound. There is no alibi. The timestamp is not on your side.
8. "The Requirements Were Unclear"
Frequency: Post-incident, universally. Severity: 🟢 Low
Sometimes true! But it is deployed as a shield in situations where the requirements were perfectly clear and you built the wrong thing with tremendous confidence and craftsmanship. A beautifully engineered solution to the wrong problem is still a monument to this lie.
The reckoning: Mild and recurring — mostly it just means you get invited to fewer early planning meetings, which, honestly, sounds like a promotion.
9. "I'll Document It"
Frequency: Every time someone new joins the team. Severity: 🟡 Moderate
Spoken sincerely, in the warm afterglow of explaining a system to a new hire. The explanation took forty-five minutes. The documentation will take forty-five minutes. The documentation will never be written.
The reckoning: The next new hire, in eight months, receiving the same forty-five-minute verbal explanation, and the cycle continues until someone leaves the company and takes the oral tradition with them.
10. "Zero Days Since Last Incident"
Frequency: Written on the whiteboard, updated grudgingly. Severity: 🔴 Critical
The most tragic lie of all, because it's not even a lie about the future. It's a lie about the present — a race between the counter being reset and reality resetting it for you. The board reads "0" for exactly as long as it takes the on-call phone to buzz.
The reckoning: Immediate. That's the beauty of it. No deferred consequences, no slow burn. Just the counter, wiped to zero again, and the pager, singing its song.
The Honest Closing
Here's the thing: none of these fibs make you a bad engineer. They're pressure-release valves in an industry that runs on optimism, deadlines, and a shared fiction that estimates are predictions. Every senior engineer you admire has told all ten, sometimes in the same afternoon.
The real skill isn't avoiding the lies. It's knowing which ones you're currently telling, and having a rough idea of when the bill arrives. Track your fibs like you track your dependencies — because like dependencies, they always, eventually, need updating.