The Discovery

I recently came across the term Laws of software engineering. I found a list of 100 items and started reading them. There are several lists out there, and the number of “laws” varies—the most common appearing to be 13.

I’ve heard about best practices, principles, patterns, rules, and laws many times, but no one ever presented me with a comprehensive list of them all.

After a few minutes of reading, I realized something: these laws shared a philosophy. All the lists I found shared common ground, and any developer would find many of them to be their compass when programming.

The Question

But wait… if these rules make so much sense, why aren’t they treated like rules?

Nobody hands you this list when signing your first SWE contract. Not at university either.

And then I tried to imagine: what if I had read them as actual LAWS a few years back — how different would my understanding be, how would they affect my work.

The Good Side

TBH, I’m not sure. But I suspect:

• I would have been less confused and chaotic at first
• I would have faced fewer dilemmas
• I could have reached decisions in a more deterministic way

The Bad Side

But here’s the thing: rules are meant to be broken.

Breaking a rule should be an intentional move—well thought out and worth the risks.

The real question becomes: how do you build the skill to know when to break them?

I guess the best way is to actually break them: in your first years as a developer, probably due to ignorance. Later, on purpose — because you’ve also learned what happens when you follow them without question.

The Paradox

Not presenting them as a set of holy rules might actually be the right call.

That’s probably why everything “depends” when it comes to programming decisions. It depends on whether it’s time to break a rule or just follow it as usual.

---

Inspired by https://lawsofsoftwareengineering.com/
Read at your own risk.