Affiliate Disclosure: By buying the products we recommend, you help keep the site alive. Read more.
We’ve already walked you through the most essential programming principles you need to know about, but there’s another class of programming principles that may prove even more beneficial than those.
Whereas the aforementioned principles teach you how to be smart with your code, the following principles will teach you to be wise with your code. Some of them are strange, and many of them are humorous, but they’re all equally practical and important. Take heed!
1. The Bloat Principle
This one has so many variations that it’s hard to pick one as the main one. Perhaps the most “official” version is the Law of Software Envelopment, more commonly called Zawinski’s Law, named after Jamie Zawinski and mentioned in The Art of UNIX Programming:
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
It’s talking about the tendency of programs to attract more and more features over time and inevitably drift towards increasing complexity. You may know this as feature creep, which is the ongoing addition of new features that have nothing to do with the main purpose of the program. Feature creep leads to bloat, and bloat is often undesirable.
This can also apply to software performance:
“Software expands to consume all available resources.”
Back in the 90s, hard drives and CPUs and RAM were far more restrictive than they are today and programmers worked hard to fit as much as they could within the limits. Yet now that we have bigger drives and faster CPUs and more RAM, we still struggle to respect limits. Everything gets bloated over time. It’s your job to keep that in check.
2. The “Worse Is Better” Mentality
Almost as if in response to the Bloat Principle, we have the Worse Is Better mentality, first coined by Richard P. Gabriel in an essay he wrote about software quality:
“Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.”
In other words, it’s wise to figure out the one problem your software aims to solve and then be very good at that one thing. Keep it simple. The more you spread yourself thin, the more unmanageable the project will become, and the more undesirable it becomes for users.
What happens when you ignore this? You end up with the Software Peter Principle:
“A overly complex project will eventually become too complex to be understood even by its own developers.”
It comes from the broader Peter Principle, which states that when employees are promoted based on their current competency and not their expected competency at their next position, all employees eventually end up in a position of incompetence. Take that principle and apply it to software, and you’ll see why worse software can often be better.
3. Eagleson’s Law
“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”
This seemingly demotivational saying is actually something to embrace. The fact is, nobody is perfect. You might think you’re a genius programmer right now, but there’s always something more you can learn, always more room to grow. If you ever look back on old code and cringe, it probably means you’ve learned something new since then.
Put another way: if you look back on an old project and you can’t see anything you can improve or would do differently next time around, you’ve likely stagnated as a programmer.
4. Principle of Least Astonishment
“If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.”
First published in the IBM Systems Journal back in 1984, this principle is still surprisingly relevant today — perhaps more so than ever before.
It essentially touches on the delicate balance between innovation and familiarity: if a piece of software is too different from others of its kind and doesn’t conform to user expectations, then they likely won’t adopt it. It’s better to strive for incremental improvements that are just big enough to be impressive but small enough to stay familiar.
5. Law of Cybernetic Entomology
“There’s always one more bug.”
Often called Lubarsky’s Law of Cybernetic Entomology, it’s unclear who this Lubarsky actually is. However, his principle rings true for all programmers: no matter how cleanly you write your code, no matter how robustly you test your modules, no matter how often you refactor your classes, there will always be another bug.
In a way, this is a freeing principle. While we should definitely strive for bug-free code, it’s also important to remember that perfectionism is the enemy of good. Look for bugs, fix them when they arise, and then move on.
6. Kernighan’s Law
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
Brian Kernighan, the very same one who co-authored the C programming language bible, is famous for this insightful law. The crux of it is this: write good code, write readable code, write simple code, anything as long as it’s not clever code.
Trying to flex your programming muscles with ivory tower complexity is the exact opposite of what it means to write clean and better code. The harder your code is to understand, the harder it will be to debug when it inevitably breaks.
And as Robert C. Martin explains, it’s not just about debugging either:
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code . . . [Therefore,] making it easy to read makes it easier to write.”
7. Rubber Duck Debugging
This one isn’t so much a principle as it is a technique, but it’s so helpful and strange that we’d be remiss to leave it out.
First told in The Pragmatic Programmer, rubber duck debugging is when you debug broken software by explaining your code to an inanimate object (e.g. a rubber duck) one line at a time. It works because the act of explanation triggers different parts of your brain, and you’re more likely to spot inconsistencies and figure out where you went wrong.
For this reason, a rubber duck can be a surprisingly nifty gift for programmers, whether you buy it for yourself or for a programming buddy of yours.
8. The Ninety-Ninety Rule
“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
This cheeky little proverb by Tom Cargill gets at the heart of why programming can be so frustrating: no matter how close you think you are to being finished, you’re much farther away than even your best estimations. When you think you’re done, you’re only halfway there.
It goes hand in hand with Hofstadter’s Law:
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
9. Parkinson’s Law
“Work expands so as to fill the time available for its completion.”
This one principle, coined by Cyril Northcote Parkinson, is a broader principle that absolutely applies to programming and goes hand in hand with the Ninety-Ninety Rule above: however much time you have to finish a project is exactly how long it’s going to take. In software development, “finishing early” is pretty much a myth.
Parkinson’s Law is the reason why proper deadlines are crucial if you want to finish and ship your software. That’s why modern professional programmers often recommend agile project management principles and project management tools like Asana.
10. Brook’s Law
“Adding manpower to a late software project makes it later.”
The next time you’re late on a project, which is likely since most programming projects need more time than allotted, remember that adding coders won’t solve it any faster.
In fact, it’ll probably take longer to complete. Not only do you need to bring the new coder(s) up to speed, they’ll likely clash with the existing coders. More things will need to be documented, more bureaucracy will be needed to keep everyone on the same page, and more friction will come out of the whole crunch-time experience.
Going Forward as a Programmer
Now that you know these principles, you’re actually better suited for the real world of programming, not just what you’ve encountered in school, in a web course, or in a bootcamp. These principles come from years and years of experience and failures.
With this newfound wisdom, you can now set forth to a high-demand programming career with more realistic expectations. For that, learn how to maximize your programming career opportunities. And if you decide that programming isn’t for you, don’t fret — consider one of these non-coding tech jobs instead.
Which of these principles ring truest to you? Know of any other weird programming principles that we missed? Let us know down in the comments below!