I’ve written a lot of code over the past 35 years.
In my earlier years (starting at age 7), everything was an experiment, with nothing slated for production (thank god). I didn’t know the limits, I didn’t know design, and I didn’t know what I didn’t know. It was chaotic and glorious.
In my teens, responsibility began to kick in. I found myself in the world of Linux development, working on GNOME and Gaim/Pidgin, and later creating libnotify/notification-daemon, Galago, and others. So much of what I built was suddenly used by people and companies around the world. If I had an idea — a new function, a new feature — and saw it through, it’d be on people’s systems, part of people’s toolkits, part of my maintenance burden.
Early in my professional career, a friend and co-worker gave me piece of advice that stuck with me:
Don’t build what you don’t know you need.
If you only think you or your users will need that function or that interface someday, but there’s no evidence of it yet, maybe leave it out.
I grappled with this for a while, and initially pushed back against the idea (“BUT WHAT IF IT’S USEFUL!”, I’d think), but… he was right. And it ultimately shaped how I developed software, though with one tweak:
Don’t ship what you don’t know you need.
There’s value in the building, but that doesn’t mean everything you build must make it into the codebase.
I let this guide me when working on Review Board and other projects. It’s easy to go down a rabbit hole and want to fully flesh out some piece of architecture to its extremes or build some cool what-if feature, because it’s fun to write code! But more and more, I instead find myself choosing to leave that code behind and out of my final commit or review request.
It’s good to build, though. Exploring a concept, finding the extents of it, really understanding the problem space. But, if you trim it down to its best parts, you’ll often end up with something far more maintainable, more reviewable, more ready to build upon in the future.
Think about photography (do you dabble? I do). You might take a hundred pictures of a sunset and show just one or two. The stars of your work, the best of the best. All those pictures contributed to finding the ones you most want the world to see, but once you’ve done that, you can shelve those photos or toss them out.
Those pictures — and that code — may still be worth looking at in the future, worth revisiting. But it doesn’t need to be part of what you present, right now.
To put it simply, aim for quality over quantity, and know what to leave on the cutting room floor.
(Not written by AI. Em dashes mine.)