Ask most teams for their values and you get a poster nobody reads. The principles that matter are different: they are the ones people argue about, hire for, and hold each other to when a deadline is looming.
These are ours. They are not slogans; they are how we make decisions when the answer is not obvious, and they show up in concrete places, code review, architecture calls, and what we choose not to build.
Clarity over cleverness
The clever solution that only its author understands is a liability, not an asset. The moment that person is on holiday, the system is frozen.
In practice this means: name things for what they do, not what is fashionable; prefer a longer, obvious function to a dense one-liner; write the comment that explains why, not what; and choose the architecture your team can hold in their heads over the one that would look good in a conference talk.
In code review it sounds like: 'I had to read this three times, can we make it boring?' Boring and obvious beats clever and fragile almost every time.
Ship to learn
Opinions about what users want are cheap. Usage is data. The faster we get working software in front of real people, the faster we learn what is actually true.
That is why we work in small, shippable increments, days not months, each one behind a flag, each one instrumented so we can see whether it moved anything. A plan that survives only in a document has taught us nothing.
The discipline is resisting the urge to add 'just one more thing' before the first real feedback. The first version being slightly embarrassing is a feature: it means you shipped early enough to still change course cheaply.
Own the outcome
We are not order-takers. If a requested feature will not move the metric that matters, the most valuable thing we can do is say so, and propose what will.
This cuts both ways. It means pushing back on a spec that does not add up, and it means not hiding behind 'it was in the ticket' when something ships that clearly does not serve the user. The person who wrote the ticket had a goal; the ticket is just their best guess at how to reach it.
Caring about the outcome rather than the ticket is the difference between a vendor and a partner.
Sweat the seams
The hard part of building software is rarely any single component. It is where the components meet: the integrations, the handoffs, the retries, the edges where two systems make different assumptions about a null, a timezone, or a currency.
We spend our attention there. That means writing the integration test that exercises the real boundary, handling the third-party API's failure modes explicitly, and being precise about data contracts between services.
It is also where craft is most visible to a user, because a product that quietly breaks almost always breaks at a seam.
The anti-principles
Principles are sharper when you also say what you will not do. We do not chase resume-driven architecture, adopting a technology because it is interesting rather than because a constraint demands it. We do not treat test coverage as a number to hit rather than a tool for confidence. We do not ship a feature and walk away without watching whether it worked.
And we do not let a design system, a linter config, or a process become an end in itself. Every rule earns its place by preventing a real problem, or it goes.
Naming the anti-principles is how the real ones stay honest.
Hiring and holding to them
Principles only work if the team genuinely shares them, so we hire for them: the technical exercise is close to real work and we look at how someone reasons about trade-offs, not whether they memorized an algorithm.
After that, the principles live in the everyday: a code review that asks for clarity, a planning session that questions whether a feature moves the metric, a retro that asks which seam bit us this time.
A principle you cannot point to in last week's work is just a poster.
Principles under deadline pressure
Anyone can hold to principles on a calm week. They are tested when the deadline is Friday and the clean solution is Monday. Our answer is not to abandon them but to make the trade-off explicit: ship the shortcut, write it down as deferred work with a trigger for revisiting, and tell whoever depends on it.
The failure is the silent shortcut, the one nobody records, that becomes load-bearing by accident. A shortcut you chose deliberately and documented is a normal part of shipping.
The principle that survives pressure is the one with a pressure-valve built in.
How they show up in review
The clearest test of whether principles are real is a code review. Ours produce a recognisable set of comments: 'this is clever, can it be obvious', 'what happens at this boundary when the other service is down', 'does this actually move the metric or is it scope creep', 'can we ship a thin version and learn first'.
None of those require a document to remember. They are habits, and habits are what a principle becomes when the team genuinely shares it.
If your reviews do not sound like your values, one of the two is not real.
Key takeaways
- Favor clarity your whole team can build on; boring beats clever.
- Ship small and often, behind flags and instrumented, to learn from real usage.
- Care about the metric behind the ticket, and say so when they do not line up.
- Put your attention on the seams where systems meet; that is where products break.
- Name your anti-principles so the real ones stay honest.
- Hire for how people reason about trade-offs, then hold to the principles in daily work.