Chapter 19: Building Things That Matter
Nobody’s gravestone says “Rewrote the app in Rust.” But they might say “Built a system that helped ten thousand people get healthcare.” The stack was never the point.
We’ve spent most of this book talking about what software development isn’t — it isn’t your identity, it isn’t your tribe, it isn’t your stack. So let’s spend this chapter talking about what it can be, at its best. Because underneath all the identity confusion and tribal warfare and framework anxiety, there’s something genuinely beautiful about this profession. And it has nothing to do with the tools.
Software development, at its best, is the practice of building things that change people’s lives. Not in the grandiose, “move fast and break things” Silicon Valley sense. In the ordinary, unglamorous, profoundly meaningful sense.
The Things That Actually Mattered
Think back over your career. Not at the technologies you used, but at the impact. The actual, measurable, human impact.
Maybe you built a system that helped small businesses manage their inventory, and a shop owner told you it saved them ten hours a week — ten hours they now spend with their kids. Maybe you fixed a performance bug that made a government website load fast enough for elderly users on slow connections to actually complete their benefit applications. Maybe you wrote the code that processes payroll, and every two weeks, a few thousand people get paid correctly because of something you built.
These aren’t the stories we tell at conferences. We tell stories about scaling challenges and clever architectures and the time we reduced latency by thirty milliseconds. But the stories that actually matter — the ones that would matter if you were looking back on your career at the end — are the stories about impact on humans.
And here’s what’s striking about those stories: the technology is barely relevant. The shop owner who got ten hours back doesn’t care whether the system was built in Django or Express. The elderly person who completed their benefit application doesn’t care whether the server runs on AWS or GCP. The people who get paid correctly every two weeks don’t care whether the payroll system is written in Java or C#.
The impact is real. The technology is incidental. And yet we spend most of our professional energy focused on the incidental part.
The Inversion
Somewhere along the way, an inversion happened. The means became the end.
Software is a means to an end. It’s a way to build things that people use, things that solve problems, things that make life a little better or easier or more connected. The technology — all of it, from the language to the framework to the cloud provider — is in service of that end.
But developer culture often treats the technology as the end itself. We celebrate technical elegance as if it were the goal. We debate architectural choices as if they exist in a vacuum, divorced from the humans they’re supposed to serve. We spend more time talking about how things are built than about what they do and for whom.
This inversion is a natural consequence of the identity fusion we’ve discussed throughout this book. When your identity is wrapped up in your tools, the tools become the most important thing. When you’re a React developer, the React part is the subject and the developer part is the modifier. The building — the actual making of things for actual people — becomes secondary to the technology used to do it.
Reversing the inversion doesn’t require giving up technical excellence. It requires putting technical excellence in its proper place: as a means to the end of building things that matter.
What “Matters” Means
“Building things that matter” can sound like a call to work only on world-changing projects — to save lives, to fight climate change, to transform education. And if you have the opportunity and the inclination to work on those things, that’s wonderful. The world needs software developers working on important problems.
But “matters” doesn’t have to mean “changes the world.” It can mean something much simpler.
It matters when the software works and the person using it doesn’t have to think about it. It matters when the documentation is clear and the developer who comes after you can understand what you built. It matters when the system is reliable and the people who depend on it can trust it. It matters when the code is maintainable and the team that maintains it doesn’t dread opening the repo.
These are small, quiet ways of mattering. They don’t make headlines. They don’t get conference talks. But they represent genuine care for the humans on the other end of the software — both the users and the developers who’ll inherit your code. And that care is the thing that makes this profession meaningful, not the choice of framework.
Craft Without Ego
There’s a concept in Japanese aesthetics called “wabi-sabi” — the beauty of imperfection, of impermanence, of things that are functional and honest rather than flashy. It’s a useful lens for software.
The best software isn’t the most technically impressive software. It’s the software that serves its purpose well, that’s honest about what it is, that doesn’t try to be more clever than it needs to be. It’s the CRUD app that processes orders reliably. It’s the CLI tool that does one thing and does it correctly. It’s the internal dashboard that nobody talks about but everyone relies on.
This kind of software requires craft. Real craft — the kind that cares about error handling and edge cases and what happens when the network is slow. But it’s craft without ego. It’s craft that’s in service of the user, not in service of the developer’s reputation or the developer’s stack identity.
Writing a clean, well-tested, maintainable API in whatever-language-the-team-knows is a more meaningful achievement than writing a technically impressive but unmaintainable system in a language you chose because it flatters your identity. The first serves humans. The second serves your ego. And the gap between those two things is the gap between software that matters and software that just exists.
The User You Never Meet
One of the challenges of caring about impact is that software developers rarely meet the people who use what they build. There’s a distance — organizational, geographical, temporal — between the person writing the code and the person whose life is affected by it.
This distance makes it easy to forget that the person exists. To optimize for clean code or cool architecture instead of for the human experience. To make decisions based on what’s technically elegant rather than what’s practically useful.
Closing that distance, even a little, changes everything. When you’ve watched a real person struggle with software you built, you think differently about error messages. When you’ve heard from a customer service representative about the problems users face, you think differently about edge cases. When you understand that a slow page load means a real human waiting, frustrated, maybe giving up — you think differently about performance.
The best developers carry a ghost user in their head at all times. A real person, with limited patience, limited technical skill, limited time, who just wants the thing to work. That ghost user doesn’t care about your stack. They care about their problem. And keeping them in mind is the surest way to build software that matters.
What’s Left When You Take the Stack Away
We’ve arrived at the place where this chapter and this book converge.
When you take the stack away — when you strip off the labels, the frameworks, the tribal affiliations, the identity performances — what’s left is the work. The actual work of understanding what people need and building things that provide it. The work of caring about quality not because it reflects well on you but because someone is depending on what you build. The work of solving problems, real problems, for real people.
That work is available to you in any language, on any platform, with any framework. It doesn’t require a specific stack. It requires attention, care, skill, and a willingness to put the human on the other end of the software at the center of your decisions.
This is what software development is for. Not for identity. Not for tribes. Not for framework wars. For building things that people use, that people rely on, that make some small corner of the world work a little better.
The stack is how you do it. The mattering is why.