After decades of building technology products, I've come to believe the hardest part was never the technology itself. The hard part is knowing what to build — and more importantly, what not to build.
The trap of capability
When you've been in the industry long enough, you start seeing patterns. Every few years, a new wave of technology arrives that makes previously impossible things suddenly trivial. And every time, the same mistake gets repeated: people build things because they can, not because they should.
The best products I've been part of weren't the most technically ambitious. They were the ones where we had the discipline to say no to ninety percent of what was possible, and obsess over the ten percent that mattered.
Simplicity is a discipline
Young engineers often mistake simplicity for lack of sophistication. It's the opposite. Simplicity is what you get on the other side of complexity — after you've understood the problem deeply enough to strip away everything that doesn't serve it.
The art of building is the art of removing.
This applies beyond code. It applies to teams, to processes, to strategy. The most effective organizations I've worked with were small, focused, and ruthlessly clear about what they were trying to do.
What I've learned
A few things I keep coming back to:
- Ship early, learn fast. The market is the only honest feedback mechanism.
- Hire for taste. Technical skill can be taught; judgment can't.
- Protect the maker's schedule. Context-switching is where good ideas go to die.
- Write things down. If you can't explain it simply, you don't understand it yet.
Building is still the most satisfying thing I know how to do. The medium changes, the principles don't.