I've spent my career helping people build software. This is a series of letters about what happens when the tools for building change faster than the principles behind building. Each one is a reminder that while the technology changes quickly, the questions that matter often stay the same.
--
Dear past Jenna,
The thing that drew you to tech in the first place, that it's always changing, is the thing that will keep you here.
Tools change (sometimes for the better and sometimes not) almost weekly. People who never consider themselves technical, much less a developer, will build apps in an afternoon with this new programming language called English. Products will go from idea to deployed before you finish your first cup of coffee (you have a toddler now, so you rarely get the full cup before it goes cold anyways). "I don't know how to code" or "I'm not technical" is no longer a barrier to building.
And that's exciting, given you've focused nearly your entire career helping others build software. But we can't confuse the ability to build with the wisdom to build.
One of the most valuable habits you've developed over the last two decades is asking a simple question:
"Should we build it?"
For most of your career, "Can we build it?" was a hard question. Time, budget, complexity, maybe the tech wasn't there yet. But those constraints were usually temporary. With enough people, time, and money, just about anything is possible. But the real questions were always: Should we build this? Is this the best use of our time? Does this solve a problem our customers actually need solved, or does it create new problems? What are we choosing not to build?
Those questions haven't changed, but the environment around them has.
Today, almost anyone can build software. Between tools like Lovable, Bolt, Replit, Claude Code, Codex, and whatever's next, the barrier to building software is lower than it's ever been. Now the question "Can we build it?" is too easy to answer. It's almost always yes, and so we build. That question and the friction of it has disappeared. It no longer helps us decide what deserves to be built.
We build because it will only take 15 minutes. We build because we can come back to iterate on it later. We build because we're curious. We experiment. And experimenting has always had a funny way of becoming production. That internal tool for your team? Someone depends on it now. Ope. Now it's open source, too. That weekend project you made for your kids' soccer team? It needs updates after the latest API changes. That AI-generated app you made for yourself? Congrats! You are now its lifetime maintainer.
Software has always been easier to create than to maintain. Remember those sprints spent getting tests working again? To fix security vulnerabilities introduced by dependencies? Remember that penny you chased across systems because a tax calculator service got swapped out and surfaced a whole bunch of rounding errors? We accepted those costs because engineering resources were scarce. This scarcity wasn't always bad. It forced us to ask the more important questions, like what deserved to exist.
AI made it dramatically easier to create software. And every new app, feature, script, internal tool, or even weekend project becomes someone's responsibility. But now we've removed much of the friction that made us pause before creating it, friction that forces us to ask these important questions.
And since it's easier to create, software starts looking the same. When we all have access to the same models, tools, and building blocks, it's easy to build software that's just like everyone else's.
This doesn't mean we stop building! But it does mean the bar has moved.
Now the differentiator is whether you saw something others didn't. Whether you deeply understood the customer and their problem. Whether you removed the unnecessary instead of adding yet another feature. Whether you solved a problem worth solving instead of simply proving you could.
Code was never the differentiator. Looking back, the best engineers I've worked with were remembered because they knew which problems were worth solving in the first place.
You'll also find yourself asking a related question more often (and not just about what you're building but what others are building): "Should this exist at all?" That's a letter for another day.
You'll be tempted to celebrate how quickly you can build. And you should. But don't let the ease of building lower your standards for what deserves to exist. As the answer to "can we build it?" becomes an easier question to answer, raise your standards for answering "should we build it?" just as quickly.
Until the next postcard.
