These are not rules. They’re heuristics: patterns that have helped me build better, think clearer, and waste less time. Some came from books. Some came from mentors. Some came from making the wrong choice and having to sit with the consequences. Some came from conversations with minds very different from my own. I keep this list because I forget things under pressure, and having them written down means I can re-read them when I need to.

They apply to engineering. They also apply to business, decisions, relationships, and anything where you’re trying to get something from not-existing to existing.

Direction matters more than speed

Technology is one of the most powerful forces humanity has ever created. It has reduced disease, scarcity, and war. But power without direction is dangerous. Building fast is easy. Building toward something good is the real challenge.

Before asking “how do I build this?” ask “should this exist, and for whom?” The second question is harder and more important. Not every efficient system is a good system. Not every optimization reduces suffering. The people who build things have a responsibility to think about what those things do in the world. Not just whether they work. Whether they help.

Think in tradeoffs

There is rarely an absolute best option. There is the right option for this context, these constraints, this team, this moment. The person who understands the tradeoff space will consistently outperform the person who memorized the “best practice,” because best practices are just tradeoffs someone else already evaluated for a context that may not be yours.

When evaluating options, ask: what does each choice optimize for, and what does it sacrifice? If you can’t articulate the sacrifice, you don’t understand the option well enough yet. This applies to architecture decisions, product decisions, career decisions, and what to eat for dinner. The skill is the same.

Talk to the pain first

Before you build, source, invest, or create anything, find the people who have the pain you want to solve and ask them about it. Not to sell. To listen.

Ask open questions: What’s the hardest part of your work right now? What do you wish existed that doesn’t? What do you currently overpay for? What have you tried that didn’t work?

One person’s pain is an anecdote. Five people with the same pain is a signal. Ten people with the same pain is a market. Their answers are your product specification. You don’t need to imagine what to build. The people who have the pain will tell you. Your job is to listen carefully enough to hear it.

People are bad at predicting what they want, which is why surveys fail. But people are excellent at describing what hurts them right now, which is why conversations work.

The build barrier is real

There is a hierarchy: nothing, something, experience, build. Most ideas die between experience and build. Thinking about a project is comfortable. Reading about a domain is comfortable. Flowing with the river of daily experience is comfortable. Actually creating the first file, writing the first line, placing the first order, making the first call: that’s where friction lives.

The gap between “I could build this” and “I am building this” is where most human potential evaporates.

The antidote is lowering the activation energy. Don’t plan the whole system. Create one file. Write one function. Make one call. List one product. The rest follows because momentum is real and perfection is the enemy of existence.

Planning is building (with a boundary)

Planning and thinking are not procrastination. A well-designed genesis document, a clear architecture diagram, a list of the right questions: these are built artifacts. They went from not-existing to existing through deliberate effort.

But planning becomes procrastination the moment it loses its boundary. Every planning phase needs a gate: a point where you’ve gathered enough information and you start constructing. “I will decide by Friday” works. “I will decide when I feel ready” doesn’t, because readiness is a feeling that never fully arrives for anyone who takes decisions seriously.

The gate has to be a commitment, not a feeling. Set a deadline. Trust the decision. Move.

Understand the “why,” not just the “how”

Knowing how to configure a system is useful. Understanding why the system is designed that way is what lets you debug it when something unexpected happens, or design a better solution when the requirements change.

The “how” gets you through today’s task. The “why” gets you through next year’s redesign. Go one level deeper than what the task requires. That extra layer is where the real understanding lives. It’s also the layer that makes you the person others come to when things break, because you’re the one who knows why things were built that way in the first place.

Solve the pain, then become the infrastructure

The most durable value comes from a two-step pattern. First: solve someone’s pain. This earns trust. Second: become the infrastructure that prevents the pain from returning. This earns recurring value.

A single transaction is valuable once. A relationship where someone depends on you to keep a problem solved is valuable continuously. This applies to businesses, careers, and relationships. The consultant who fixes a system once gets paid once. The consultant who maintains the system gets paid forever.

Seek the things that get more valuable over time, not the things that get consumed. A brand compounds. A network compounds. A body of written work compounds. A single deliverable does not.

The explore-exploit tradeoff applies to decisions

In reinforcement learning, an agent must balance exploration (trying new options) with exploitation (using the best known option). Explore too long and you never act. Exploit too early and you miss better options.

Decision-making works the same way. At some point, the marginal value of another hour of research drops below the marginal value of having the thing and working with it. For people who naturally see many dimensions of a decision, the temptation is to keep exploring forever because there’s always one more angle.

The optimal strategy is to explore with decreasing probability over time. In practice: set a deadline. Gather information until the deadline. Decide. Trust the decision. If a choice is difficult because both options are very good, that’s not a hard decision. That’s two good options. Pick one and stop.

Document everything

Not because someone told you to. Because your future self is a different person who won’t remember why you made this decision, what the alternatives were, or what you learned last time this problem appeared.

The act of writing forces understanding. You can’t write clearly about something you don’t understand. The archive becomes searchable memory. The documentation becomes a gift to your future self, your teammates, and anyone who encounters the same problem after you.

I keep structured notes on every project, every course, every concept I learn. Three months later, when a similar problem appears, the answer is already written down.

Update your beliefs

Most people form an opinion early and then filter all subsequent information through it. The engineer who chose a framework in 2018 defends it in 2026 not because they re-evaluated, but because changing would mean admitting the first choice wasn’t optimal. The business owner who picked a strategy defends it against evidence because the sunk cost feels real.

Hold your opinions loosely. If new evidence suggests a different approach, the cost of changing your mind is nothing. The cost of defending a wrong position is everything. The people who update fastest learn fastest.

This is harder than it sounds. The ego wants consistency. But consistency without updating is just stubbornness wearing a suit.

Always deliver something

If you get asked a question and you don’t know the practical answer, build a document. If you can’t ship a feature, ship a design. If you can’t ship a design, ship a list of questions that need answering. The worst outcome is “I worked on it but have nothing to show.”

There’s always something you can put on the table. A draft, a diagram, a prototype, a clearly articulated problem statement. Delivering something, even something incomplete, creates surface area for feedback. Delivering nothing creates silence, and silence is where projects go to die.

Range is a feature

There’s a cultural pressure to be one thing. To specialize. To pick a lane. Specialization is rewarded. Range is suspicious.

But the most interesting things happen at intersections. A data engineer who cares about civic infrastructure sees a problem that a pure data engineer and a pure civic activist both miss. A builder who cares about aesthetics creates things that a pure engineer and a pure designer both can’t. The deep specialist solves problems within their domain. The deep generalist sees problems that specialists don’t recognize as problems, because the problem lives at the intersection of two domains that specialists never visit simultaneously.

Don’t apologize for your range. It’s the reason you see things others don’t.

Aesthetics are engineering

A well-designed interface reduces cognitive load. A beautifully structured codebase is easier to debug. A site that feels right gets read more carefully. Typography affects comprehension speed. Color affects emotional state. Layout affects information hierarchy. These aren’t subjective preferences. They’re measurable effects.

Treating form as separate from function means building half of what you could build. The interesting work happens when both are treated as inseparable. This applies to code, to documents, to presentations, to physical products, to the way you organize your notes. If it can be experienced by someone, its form matters.

Think in systems

Not just “this works.” Think: where does the input come from, where does the output go, what happens when a component fails, what depends on what, how does it change over time, who maintains it, what does the error path look like, what are the second-order effects.

Every component exists in a system. Understanding the system is what separates someone who executes tasks from someone who designs solutions. It’s also what lets you see opportunities that others miss, because opportunities often live in the gaps between components that nobody is looking at.

Your future self is a different person

The you who will read this document in six months has different knowledge, different priorities, and a different emotional state than the you who wrote it. Build for that person. Document for that person. Make decisions that serve that person, not just the person you are today.

This is why documentation matters. This is why compound investments matter. This is why burning bridges is expensive. Your future self inherits everything you build and everything you break. Leave them something good.

---

These ideas come from many places: Kleppmann, consulting work, open-source communities, mistakes, reading widely, and conversations with minds very different from my own. What I’ve added is the combination, the lived experience of applying them, and the act of writing them down. I share them because the best ideas grow when they travel.

If even one of these saves someone an hour of spinning, or helps them cross the gap between “I could build this” and “I am building this,” the post was worth writing.