Andrey Agibalov Common sense sounds nice — but everyone’s version of it is different. What’s “obvious” to one person can look completely wrong to another. That’s why relying on it in a team never works.
When a question like “how should we do this?” comes up, don’t waste time arguing whose common sense is more common. Talk it through once, agree on the rule, and write it down. After that, there’s nothing to argue about — you just follow the agreement.
Discussions like “my formatting is better because…” or “we should use this brace style instead…” can be fun over a beer, but not during actual work. Once you’ve agreed on a style, turn it into something the computer can understand. Start with a written guideline, then make it real by adding a linter that enforces it. And if possible, go one step further — use an automatic formatter so that nobody even has to think about formatting again.
When you work in a team, you’re dealing with a web of interdependencies — between people, code, and processes. It’s healthy to minimize those interdependencies wherever you can. One way to do it is by drawing clear borders between what teammates can expect and what they shouldn’t expect to happen.
For example, during a code review, we shouldn’t argue about code style. Yes, it might be worth revisiting the rules — but not here and not now. In the review, we follow the existing guidelines. If the guidelines need to change, that’s a separate conversation. It happens once, gets documented, and becomes the new rule for everyone.
That’s how a team stays efficient: fewer surprises, fewer personal opinions, fewer circular debates. The goal isn’t to control anyone — it’s to reduce noise so the team can focus on real work.
Agreements do limit you — but they also protect you. They define what others can expect from you, and what you can safely expect from them. Those limits are what make real freedom possible.