The Social Operating System of Software Teams
Every workplace has unwritten rules. But developer culture — shaped by open-source traditions, internet forums, late-night IRC conversations, and decades of shared frustration — has a particularly dense and sometimes contradictory set of them. Some are genuinely useful norms. Some are historical artifacts. All of them will affect your daily experience as a developer if you don't know they exist.
Here are ten of them, explained with the honesty they deserve.
-
You Don't Ask How Long Something Will Take Without Expecting a Wildly Wrong Answer
Estimation is not a solved problem. When a developer says "a couple of days," that can mean anywhere from four hours to three weeks. This is not deception — it's the genuine difficulty of predicting complex work with unknown unknowns. The culture norm: don't penalize honest estimates by punishing people when reality diverges.
-
The Person Who Touches the Code Last Owns the Bug
Technically unfair. Practically universal. If your commit is the last thing that touched a file before it broke, you're getting the first Slack message regardless of whether you caused the bug. This is why comprehensive commit messages are not just hygiene — they're self-defense.
-
"It Works on My Machine" Is Funny Precisely Because It's True
The meme exists because this sentence has been said, in complete sincerity, millions of times. It's not an excuse — it's a data point. If it works on your machine and not in CI, the environment is the bug. This realization is humbling every single time.
-
Never Deploy on Friday
Not a rule. Not a policy. Just hard-won collective wisdom encoded into culture by everyone who has ever spent a weekend on an emergency rollback. Your future self will thank you every single time you respect this one.
-
The Quiet Developer Is Often the Most Dangerous One in the Room
The person saying the least in the architecture discussion frequently has a very specific concern they are waiting for the right moment to raise. When they do speak, pay close attention. The senior developer who asks one quiet question and then goes silent again just saw something nobody else did.
-
Comments Explain Why, Not What
A comment that says
// increment i by 1above ai++is noise. A comment that says// increment by 1 here because the API returns 0-indexed but our UI is 1-indexedis signal. The unwritten rule: if you're going to comment, say something the code can't say for itself. -
Nitpick Comments in Code Review Are Still Real Comments
Some teams prefix "non-blocking" feedback with
nit:. This is civilized behavior. A code review full of uncommented nitpicks reads as hostile even when it isn't. Signaling "I care about this but it won't block the merge" is a social skill as much as a technical one. -
The Most Dangerous Words in Software Are "This Should Be Simple"
The moment anyone — PM, executive, or developer — says a feature "should be simple," the feature will immediately reveal four hidden dependencies, a decade of technical debt, and an edge case that requires a meeting with Legal. This is not a coincidence. It's the universe responding to hubris.
-
Whoever Writes the RFC Usually Wins the Argument
The person who takes the time to write down a concrete proposal, with trade-offs documented, almost always shapes the outcome more than anyone who just has opinions. Writing is thinking made visible. The unwritten rule: if you care about the outcome, write it down first.
-
Asking "Dumb" Questions Is Actually a Power Move
The developer who asks the question everyone else was afraid to ask is not exposing ignorance — they're creating value. Unasked questions become unexamined assumptions. Unexamined assumptions become production bugs. The person who asks "wait, why do we do it this way?" is doing the team a service, even when the question is answered in five seconds.
These rules aren't formal. You won't find them in any handbook. But you'll feel them every day — and once you name them, you'll navigate the culture a lot more effectively.