Rules Without Reasons

"Show, don't tell." "Never commit directly to main." "Functions should be no longer than 20 lines." "Always use passive voice in scientific writing."

The thing that connects every failed training program, every style guide that gets ignored, and every team that "knows the rules" but still ships garbage is the same: the rules showed up without their reasons.

What a Rule Looks Like Alone

A rule by itself is a tip. "Keep functions short." Ok. How short? What counts as short? What if making it shorter makes it harder to read? When does this apply and when doesn't it?

Tips are fragile. They work in the context where someone discovered them. Move to a different context and they break, and the person following them has no way to figure out why, because they never knew why the tip existed in the first place.

I've watched this happen in code reviews, in woodworking forums, in photography groups, in writing workshops. Someone learns "show, don't tell" and then applies it to exposition that genuinely needs to just tell the reader something. Someone learns "use hand tools for fine work" and then hand-planes a surface that the random orbit sander would have done better. The rule was correct somewhere. They don't know where, so they apply it everywhere.

What's Under the Rule

Rules don't come from nowhere. They're derived from something, whether anyone bothered to write it down or not.

Under every rule is a principle — a trade-off preference. "Clarity over cleverness" is a principle. It doesn't tell you what to do. It tells you which direction to lean when you have to choose. Under every principle is a value — a reason for caring. "We value code that humans can maintain" is the value. That's why clarity matters more than cleverness. That's the answer to "who cares?"

When people get the whole stack, they develop judgment. When they only get the rule, they develop compliance.

Compliance is a person who follows the 20-line function limit even when the 25-line version is clearer. Judgment is a person who keeps the function at 25 lines and can tell you why: because the principle is clarity, and splitting this function harms clarity. The rule serves the principle. When it doesn't, the principle wins.

What Happens Without the Stack

I've seen every version of this go wrong.

Rules without principles means there's nothing to do when two rules conflict. "Keep functions short" and "don't create unnecessary abstractions" will collide eventually. Without a principle to arbitrate, people either pick whichever rule they heard most recently or freeze.

Principles without values means nobody knows why they should care. "Clarity over cleverness" sounds nice until shipping day, when someone asks "who cares about clarity, we need this to work." If the value isn't there — if people don't understand that maintainability is what keeps the lights on six months from now — the principle has no weight.

Rules without interpretation means rigidity. The meeting policy says every meeting needs an agenda. An urgent incident happens. Someone actually says "we can't start the incident response call, there's no agenda." That happened. I was there.

Principled Rule-Breaking

This is the part most training completely misses. If you understand why a rule exists — if you can trace it back through its principle to its value — then you also know when to break it. And, you can explain why.

A 25-line function in a codebase where the principle is clarity? Fine. You're serving the principle, not the rule. Document why.

An emergency response call without an agenda? Obviously fine. The value is focused work time. The principle is preparation over improvisation. An emergency is inherently unprepared-for. The rule about agendas was never meant for this, and anyone who understood the derivation would know that instantly.

But, someone who only got the rule? They'll either follow it off a cliff or break it with no ability to explain the decision, which means the next person doesn't learn anything from it either.

This Isn't Just About Work

"Exercise 30 minutes a day." That's a rule. What's the principle? If it's something like "sustained capability over short-term optimization," then missing a day doesn't require punishing yourself with a double session. One bad day doesn't break a sustainable pattern. But, without the principle, people either follow health rules like religion or throw them out entirely when they inevitably miss a day. The rules create compliance or guilt, neither of which is the point.

Where Judgment Comes From

The version of this that actually works starts with the principle, not the rule. Derive the rule from it. Then look at edge cases where the rule and the principle disagree.

That's where judgment develops. Not from memorizing the rule. From understanding what the rule was trying to protect and recognizing when protection looks different than the rule anticipated.

Rules without reasons are tips. Tips are fragile. Grounded knowledge adapts.