* Don’t worry, this isn’t another job title you’re going to have to add to your CV this year
One thing that I’ve come to notice of late is that I’m a little different to a lot of developers that I meet. Many developers, seem to have a penchant for wanting to write code for the sake of writing code. To optimise, to agonise over, and ultimately to perfect the very specific piece of code that they’re working on, regardless of the bigger picture of the project. An old colleague of mine once described the in-depth discussion about low-value optimisations as “intellectual masturbation”, and I think the phrase suits this kind of thing well. I’m regularly surprised by the eagerness of developers to dive into these rabbit holes, while being oblivious (or maybe just uncaring) of how little value they hold. I just don’t get it.
Admittedly, I’m not entirely devoid of a love of the “craft” of writing code. I do feel the joy of a really well optimised algorithm (jesus that sounds nerdy, even to me). I do find myself grinning at the end of working on a story, when I’ve refactored a bunch of the smells out of the code I’ve just written and halved its size and complexity. But, what really drives me is delivering changes into environments. To me, there’s no point in all the hard work and effort to make it “more perfect”, if it isn’t getting shipped. I could forgo all of the really stereotypical ego-phalating parts of developer life (time-complexity anyone?) if I got to slowly but steadily make the codebase better whilst delivering new features and functionality to it.
I’m not even that fussed about what the functionality is in all honesty. Most of the time it’s more the feeling of accomplishment that comes from getting work done and shipped. What I can’t stand, however, is writing code for the sake of writing code. It’s probably why I struggle so much finding a side project that I actually want to start. I need to have a reason to develop software. Software, in and of itself, isn’t reason enough.
I like to think that it’s a truly altruistic trait. The idea being that I want to do good things. To provide those good things to others and get all the “helping other people” good feels that you get from that. There’s definitely a bit of that maybe (along with the selfish power-trip side of things), but realistically there’s a large part that’s just plain boredom. You see, the thing I’ve come to realise is that maybe it’s not just that I’m a business-orientated developer. One who cares about the overall functionality/completeness of the product I’m building and is happy to sacrifice the minutiae of the craft for the greater good. Maybe it’s that I just get bored easily. After a while of working on the same story, i just want to get it shipped and move on to the next, and maybe I just hit sooner than others.
Another thought that springs to mind, as it often seems to these days, is that this reflects the now age old “agile vs waterfall” conundrum. In this instance, it’s “make the code perfect” vs “get it shipped and make it better later”. The common refrain I hear is “oooh but we’ll never DO it later and it’ll always be CRAPPY”. Well, to that I say “GOOD!”. If we don’t get back to making it better, that means that it wasn’t worth the effort. Or that, more importantly, there are way more important things that are worth the effort. In this case, I’m bloody glad we didn’t waste our time to make your algo use that little bit less memory when it’s parsing. Instead we shipped a new feature, wahoo!
On balance, I think it’s important to remember to pinch a little bit from each camp. Constant rushing without good code leads to getting slowed down later with tech debt. Constant perfectionism leads to no traction at all and thus, no value. For me, I’ll always be a bit more of a delivery focussed developer and that’s alright with me.