Lessons From 20 Years of Building Software
Not a listicle. Just a handful of things I've learned about shipping products, leading teams, and staying in the game long enough to get better.
I’ve been building software professionally for over two decades. That’s long enough to have made most of the avoidable mistakes at least once.
Here are a few things I’ve come to believe — with the caveat that all of them are provisional and context-dependent.
Ship something, then make it better
The instinct to wait until it’s ready is usually a form of fear dressed up as professionalism. Most software gets better through contact with real users, not through additional rounds of internal polish.
The corollary: knowing when something isn’t ready is a genuine skill. The judgment you’re developing is not “should I ship sooner” but “what’s the minimum that makes the thing real.”
The team is the product
You can ship a mediocre product with a great team and find your way to something good. You can ship a technically impressive product with a dysfunctional team and slowly watch it decay.
I’ve led both kinds of teams. The human dynamics are almost always the constraint, not the technology.
Communication compounds
Every hour you invest in making complex things clear to your team pays dividends you can’t directly see. The developer who understood the problem correctly the first time, the designer who didn’t have to ask a clarifying question, the stakeholder who didn’t escalate a concern — none of those appear in your metrics.
Being a clear communicator is not a soft skill. It’s an engineering leverage multiplier.
Long-term thinking is a competitive advantage
Most organizations optimize for the next quarter. If you can think clearly about the next two years and make decisions that serve both horizons, you’re playing a different game.
This doesn’t mean ignoring the short term. It means being willing to pay a small short-term cost for a large long-term benefit — and being able to articulate why that trade is worth making.
Build something of your own
The perspective you get from owning a product end-to-end — writing it, marketing it, selling it, supporting it, watching it succeed or fail — is qualitatively different from working inside a company. I can’t recommend it enough.
It will make you a better engineer, a better product person, and a more honest evaluator of your own skills.
None of this is original. All of it took me longer to actually internalize than I expected.