Things I Believe About Work That I Can't Prove
Reading note
Essays for people who want the pattern behind the pattern.
This page is designed to read like a quiet, deliberate argument rather than a feed item.
Most systems fail at the boundaries between teams, not inside them.
The person who can translate between technical and non-technical stakeholders is more valuable than the person who’s deepest in either domain. Nobody wants to hear this, including translators.
If you can’t explain the tradeoff, you haven’t finished the architecture.
People don’t resist change. They resist being changed without being consulted.
The best documentation is written by someone who just figured it out, not by someone who’s known it for years.
Premature optimization and premature abstraction are the same instinct wearing different clothes.
Every system eventually reflects the communication patterns of the organization that built it. Conway’s Law isn’t a law — it’s a warning that almost nobody heeds.
The cost of a meeting isn’t the time in the room. It’s the decision that didn’t get made because everyone assumed someone else would follow up.
“We should automate this” is sometimes a way of avoiding the harder conversation about why the process exists at all.
Constraints produce better work than freedom. But only if the constraints are real and not invented by someone who’s afraid of the answer.
You can tell how healthy an engineering culture is by how people talk about the last outage. If they talk about the person who caused it, it’s broken. If they talk about the system that allowed it, it’s working.
Most “technical debt” is actually decision debt — the accumulation of choices that were never made explicitly.
The instinct to add is stronger than the instinct to remove. This is true in code, in process, in organizations, and in life. The people who know when to subtract are rare and undervalued.
Nobody’s job description matches their actual job.
The most important skill in architecture isn’t technical. It’s knowing when to stop designing and start building. The second most important skill is knowing when to stop building and start deleting.
Trust is a faster protocol than process.