So this will be an interesting blog post. I’m going to combine engineering with…working out!
There’s a little saying that goes around about working out. The saying goes, What’s the best exercise to do? The answer is, the one that you will stick with and actually do!
The idea is supposed to be to find an exercise that you enjoy doing and that makes it easier to stick with it. That you are motivated to go work out. But this idea doesn’t always work in real life. I exercise a lot, and I have for a long while, but the reality is I don’t enjoy it. I enjoy the results and the benefits but in the middle of a tough workout my mind is usually thinking, “this sucks”.
In response to this, another saying started popping up in workout circles, and this saying is, “Discipline beats motivation”. You don’t stick with an exercise necessarily because it is fun (and in fact, it might be the opposite). You stick with it because you want the results and because you know the exercising is worth it, and also because it is only temporary. That 30 minutes on the treadmill will eventually end, after all.
In the middle of doing something not fun, you can stick with it and finish it out by telling yourself it is only temporary and there is a finish line.
“Embrace the suck”, if you will.
OK, so let’s flip this back to engineering, specifically software development. There are definitely fun parts of software development. I enjoy solving problems, designing architectures, and that moment when your CI pipeline runs to completion and all your unit tests passed. But there are things I don’t like. I don’t like writing endless unit tests, I don’t like having to go refactor or reformat a bunch of code to pass a style guide review, and I don’t like that moment when you know how to solve a problem but realize you have a lot of housekeeping code to go write to scaffold it all up.
I’m reminded of a career day I remember attending, and this is something that came up there as well. There was an anecdote about someone who wanted to be an interior designer, so they went to school and got credentialed and got an entry-level position at a firm to gain some experience. And got very disgruntled because the first six months was calculating square footage and looking up material prices in catalogs and putting together estimates. They thought they were just going to do “the fun stuff”, i.e. here’s a blank piece of paper, go draw and design some awesome lobby for a doctor’s office, and not do “the boring stuff”, i.e. find all the materials and quote out how much it would cost to refloor and paint said doctor’s office.
But learning how to do all that boring stuff, and then actually doing all the boring stuff, is incredibly important to the overall quality and excellence of your work. Just giving a client a picture of an awesome lobby doesn’t solve their problem…they need the lobby completed! You could write the most awesome elegant algorithm ever, but without the glue code, the edge case handling, the security integration, the unit tests to catch bugs, then what you’re delivering may be full of bugs, security holes, and performance problems.
Polish and quality frequently come from the boring parts, not the fun parts. It is the discipline that gets you through all these parts of the software development process and ensures that you are delighting your customers by delivering a complete, quality solution.