When you first learn to program, you feel like a wizard. You write a script, and the computer does what you say. You measure your productivity by the number of lines you commit.
"I wrote 500 lines of code today!" is the battle cry of the Junior Developer.
But as you transition into a Senior role, a dark realization sets in: Every line of code you write is a liability. It is something that has to be read, tested, debugged, and eventually updated when dependencies break.
Do I agree that "Less code = fewer bugs"? Absolutely. But there is a dangerous trap hidden in that statement. Here is how to think about code as a liability without destroying your codebase's readability.
1. The Maintenance Tax
Code is not a static asset like a house. It is a living organism that constantly decays.
Security: More code means a larger surface area for vulnerabilities.
Cognitive Load: When a new developer joins your team, they have to fit your logic into their brain. A 10,000-line microservice is infinitely harder to grasp than a 1,000-line one.
The Fix: Before you write a custom utility function, ask yourself: Does the standard library already do this? Can we solve this at the database level instead?
2. The "Less Code" Trap: Code Golfing
This is where the "less code" mantra goes wrong.
Some developers take it literally and try to compress complex logic into a single, unreadable line just to save vertical space. We call this "Code Golfing."
// A "Clever" One-Liner (High Liability)
const getActive = (u) => u.filter(x => x.s === 1 && x.a > 18).map(x => x.n);
// Boring, Readable Code (Low Liability)
const getActiveAdultUserNames = (users) => {
const activeAdults = users.filter(user => user.status === 1 && user.age > 18);
return activeAdults.map(user => user.name);
};
The first example is less code, but it is a higher liability because the next developer to read it will spend 10 minutes trying to decipher what x.s means.
Less code should mean less complexity, not just fewer keystrokes.
3. The Joy of Deleting Code
The best pull requests are the ones with negative lines of code.
When you refactor a messy module, delete a deprecated feature, or replace 500 lines of custom logic with a well-tested, open-source library, you are actively removing liability from your organization.
Conclusion
Your job as a software engineer is not to write code. Your job is to solve business problems. If you can solve a problem by deleting code, changing a process, or using an existing tool, you have done your job perfectly.
What is the biggest block of code you’ve ever deleted, and how did it feel? Let me know in the comments below!
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com
Top comments (0)