isms.seff.ai

There are a million things you could do, pick 1

Software engineering isn't about building everything possible. It's about choosing what to leave undone.

June 14, 2025
engineering
philosophy
prioritization
tradeoffs
management

The Art of Leaving Things Undone

Every morning, you wake up to infinite possibilities. You could refactor that legacy module. You could add that feature users have been asking for. You could upgrade the framework. You could optimize the database. You could write more tests. You could document the API. You could...

Stop.

There are a million things you could do. Pick 1.

The Industry's Dirty Secret

We don't talk about it much, but software engineering is really change management in disguise. We're not builders—we're choosers. We don't create features as much as we decide which features not to create.

Every line of code written is a thousand lines not written. Every feature shipped is a hundred features abandoned. Every priority chosen is an infinity of possibilities rejected.

The Tyranny of Possibility

Modern software development offers us god-like powers:

  • Infinite Libraries: There's a package for everything
  • Endless Patterns: A design pattern for every scenario
  • Unlimited Compute: Cloud resources that scale to infinity
  • Boundless Creativity: No constraints on what we can imagine

But this abundance is a trap. When you can do anything, how do you choose what to do?

The Mathematics of Choice

Let's say your backlog has 100 items (and that's conservative). The number of different ways you could prioritize those items is:

100! (100 factorial) = 9.3 × 10^157 or 933,262,154,439,441,526,816,992,388,562,667,004,907,159,682,643,816,214,685,929,638,952,175,999,932,299,156,089,414,639,761,565,182,862,536,979,208,272,237,582,511,852,109,168,640,000,000,000,000,000,000,000 (52 commas)

That's more than the number of atoms in the observable universe. And that's just ordering what you already know about. It doesn't include the infinite things you haven't thought of yet.

Why Everything Is a Tradeoff

When you choose to do something, you're not just choosing that thing. You're choosing:

What You're NOT Doing

  • Every feature you build delays every other feature
  • Every bug you fix leaves another bug unfixed
  • Every optimization you make leaves performance on the table elsewhere

What You're Committing To

  • Every feature needs maintenance forever
  • Every dependency you add is a future migration
  • Every abstraction you create is complexity someone must understand

What You're Signaling

  • Your priorities teach your team what matters
  • Your choices train your users what to expect
  • Your decisions shape your product's identity

The Real Job: Saying No

The best engineers aren't the ones who can build anything. They're the ones who know what not to build.

This is why senior engineers seem to do less but accomplish more. They've learned the art of strategic laziness. They've mastered the discipline of not doing.

The Framework for Choosing

How do you pick your one thing from the million possibilities?

1. Impact vs Effort

The classic 2x2 matrix isn't just a consultant's trick. It's a survival tool. High impact, low effort? That's your sweet spot.

2. Reversibility

Can you undo this decision? Reversible decisions can be made quickly. Irreversible ones deserve more thought.

3. Compound Effects

Some choices make future choices easier. Others make them harder. Optimize for decisions that open doors rather than close them.

4. The Cost of Delay

What happens if you don't do this now? Sometimes the answer is "nothing," and that's your cue to skip it.

The Cultural Challenge

The hardest part isn't the choosing—it's the explaining. Everyone understands why you did something. Few understand why you didn't do the other 999,990 things.

  • Stakeholders see missed opportunities
  • Users see missing features
  • Developers see technical debt
  • You see tradeoffs

Your job is to make the invisible visible. To explain not just what you're building, but what you're consciously choosing not to build, and why.

The Peace of Constraints

There's a Zen to accepting that you can't do everything. When you truly internalize that there are a million things you could do but you can only pick 1, something magical happens:

You stop feeling guilty about the 999,990 things you're not doing.

The Practical Reality

In the end, software engineering is about making peace with incompleteness. Every system is unfinished. Every codebase has room for improvement. Every product could be better.

The question isn't "How can we do everything?" It's "What is the 1 thing that matters most right now?"

Choose Wisely

Your code will outlive your reasons for writing it. Your architecture will outlast your assumptions. Your priorities will echo through your codebase for years.

There are a million things you could do. The 1 you choose defines everything.

Choose wisely. Choose consciously. And most importantly, choose.

Because not choosing is also a choice—it's choosing to let randomness and reaction drive your work instead of intention and strategy.

The million things will still be there tomorrow. But today, you can only do 1.

What will it be?