As developers, we make decisions constantly. Which framework to use. How to structure a database. Whether to refactor now or ship the feature first. Whether to take that new job offer. The quality of these decisions compounds over time, and having a clear framework for making them reduces stress and leads to better outcomes.

Reversible vs Irreversible Decisions

Jeff Bezos describes this as one-way doors versus two-way doors. A one-way door decision is difficult or impossible to reverse - once you walk through, you are committed. A two-way door decision can be easily undone if it turns out to be wrong.

Most decisions are two-way doors:

  • Choosing a CSS framework - you can switch later
  • Adding a new API endpoint - you can deprecate it
  • Trying a new library - you can revert to the old one
  • Hiring a contractor for a short project - the engagement ends

Few decisions are truly one-way doors:

  • Choosing a primary programming language for a large codebase
  • Selecting a cloud provider when deeply integrated
  • Publishing an API that external customers depend on
  • Accepting a job in a different country

The key insight: treat two-way door decisions quickly. Do not spend three weeks evaluating CSS frameworks. Pick one, start building, and switch later if needed. Save your careful analysis for one-way door decisions where the stakes are genuinely high.

Second-Order Thinking

First-order thinking asks: "What happens if I do this?" Second-order thinking asks: "And then what happens after that?"

Most people stop at the first order. Here is what it looks like in practice:

Decision: Skip writing tests to ship faster.

  • First order: Feature ships sooner. Team looks productive.
  • Second order: Bugs appear in production. Debugging takes longer without tests. Future changes are risky because you have no safety net. The next developer is afraid to refactor. Technical debt accumulates.

Decision: Introduce a microservices architecture for a small team.

  • First order: Services are independently deployable. Feels modern and scalable.
  • Second order: Network calls replace function calls, adding latency and failure modes. Debugging spans multiple services. The team of four now needs to maintain service discovery, distributed tracing, and deployment pipelines for each service. Development velocity drops.

Second-order thinking does not mean you avoid action. It means you make decisions with your eyes open about the downstream consequences.

The Decision Journal

A decision journal is a simple but powerful tool. Before making a significant decision, write down:

  • The decision - what you are choosing and the alternatives you considered
  • Your reasoning - why you chose this option over the alternatives
  • What you expect to happen - specific, measurable predictions
  • The date - when you made the decision

Revisit the journal periodically. Compare your predictions to actual outcomes. Over time, patterns emerge. You discover where your judgment is strong and where it has blind spots. Maybe you consistently underestimate migration timelines. Maybe you overweight technical elegance and underweight user impact.

The journal is not about beating yourself up over wrong calls. It is about calibrating your judgment through honest feedback.

Avoiding Analysis Paralysis

Analysis paralysis happens when you research, compare, and deliberate so long that you never actually decide. It is the enemy of progress, and developers are particularly prone to it because we are trained to evaluate tradeoffs carefully.

Signs you are stuck:

  • You have been evaluating options for more than a week without new information surfacing
  • You are reading the same comparison articles for the third time
  • You keep finding "one more thing to consider" before deciding
  • The cost of delaying the decision exceeds the cost of picking the wrong option

Tactics to break out:

  • Set a decision deadline. "I will choose a database by Friday." Having a hard stop forces you to act with the information you have.
  • Use the 70% rule. If you have 70% of the information you wish you had, decide. Waiting for 100% information means waiting forever.
  • Ask: what is the cost of being wrong? If the cost is low (two-way door), just pick and move on. You will learn more from doing than from researching.
  • Default to the simpler option. When two choices seem roughly equal, pick the simpler one. Simplicity is easier to change, debug, and explain.

Group Decisions

When decisions involve a team, a few extra principles apply:

  • Disagree and commit. Once a decision is made, everyone commits to it fully, even those who argued for a different approach. Undermining a decision after it is made is worse than making the wrong decision with full commitment.
  • One decision maker. Consensus is slow and produces watered-down compromises. Identify one person who owns the decision, gather input from the team, and let that person decide.
  • Write it down. Document the decision and reasoning in an ADR (Architecture Decision Record) or similar format. This prevents revisiting the same discussion six months later when someone new joins.

Start Deciding

The best decision framework is the one you actually use. Start with the reversible/irreversible distinction. Apply it to your next decision today. You will immediately feel less pressure on the decisions that do not warrant it, and more focus on the ones that do.