Building Race Cars
At some point in your career, you may start to get the feeling that you aren’t truly worthy of being called a programmer unless you can build something like this -
So you’ll work really hard, put in a bunch of overtime, and end up building something like this -
But really, the thing that you should’ve been building is this -
Programmers love building big complicated things. We love the challenge, we love the puzzle-solving aspect of figuring out how all those pieces fit together, and we especially love the ego boost that comes with finally turning that ignition key and having our machine come to life.
Building complicated systems can be a boost for your career as well. Come annual review time, everyone wants to be The-Dev-Who-Built-The-Big-Shiny-Thing. Even if the project is massively behind schedule, it’s pretty likely that the person who put the most Shiny on their Thing is going to get the biggest bonus.
And that’s a real problem.
As a developer who’s dedicated most of his career to cleaning up and maintaining other people’s codebases, I’ve almost always found that complicated solutions aren’t any better than simple ones — in fact, they can be far far worse. Your proud moment of unveiling your clever system is my moment of recoiling in horror at the fact that at some point down the road I’m going to end up responsible for untangling the mess you just made.
In building your masterpiece you’ve welded all sorts of different aspects of the problem into one big clunky metal ball. From here on out, every piece of code that every other developer is developing has to either graft itself onto your contraption or somehow work around it. After a few months of “we’re just trying to fix bugs”, their accumulated patches will quickly wear off all the Shiny and leave you with just a Thing.
Six months later, I’ll be sitting at my desk ordering crowbars in bulk off Amazon. I’ve been doing this a long time, I can tell how many I’m going to need to pry your Thing apart. It’s not that I think you’re a bad programmer or that your coworkers were wrong to try and patch their way around problems, it’s just that I know there are easier ways to accomplish the tasks you want done and I greatly enjoy breaking complex things down into simpler pieces.
This isn’t to say that _every_ problem can be broken into simple pieces; there are a few exceptions. Some problems are just mathematically intractable and have no easy answers — for example, reconstructing 3D models of objects from photographs is notoriously hairy. Some systems are so tiny that the solutions you’d use on a beefy server just won’t run fast enough or won’t fit in memory — try running MySQL on your Arduino and see what happens. Sometimes your system has to talk to other systems that are just _weird_, and no amount of tinkering will completely eliminate the strange smells that waft across into your codebase. On those rare occasions when problems can’t be simplified, I’m usually OK with wrapping the whole mess behind an interface and slapping a “HERE BE DRAGONS” label on it.
Most of the time though, the problems you’ll be solving as a developer just don’t have that level of irreducible complexity — even if they seem to when you first start working on them. Are new problems head-scratchingly confusing? Sure. Will the first solution you come up with require a bunch of tedious rework? Probably. Does getting your code reviewed require more communication and negotiation with other developers than you’d really like because if they’d just let you check the whole metal-code-ball-Thing in you could’ve had the project done last Thursday? Yes, but trust me — those code reviews are more valuable than you think they are.
That shiny green race car at the top of this article looks super complicated. I look at it and all its strangely-shaped swoopy bits and I can imagine enough of the wires and gears and pistons inside it to know that I’d never feel competent enough to even begin to tinker with it. But to the engineer who was tasked with designing those curved fins next to the front wheels, it wasn’t really complicated at all — it was the simplest solution they could come up with for the problem they needed to solve. Complexity for complexity’s sake never entered the picture. Complexity is heavy, and heavy cars don’t win races.
So if you find yourself at the start of a new project and are debating with your coworkers about which of a dozen different directions your codebase could go, I’d suggest that the kudos you get during your annual review for being The-Dev-With-The-Shiniest-Thing just aren’t worth it in the long run.
In fact, I’d go so far as to say that if you want to be the most valuable person at your company, don’t try to write any complicated code at all. Take a long look at the problem, rummage around in your box of Legos until you find all the bricks you need, and say “Can’t we just stick these pieces together and call it done?”