I recently finished reading Robert M. Pirsig's Zen and the Art of Motorcycle Maintenance, and it was an interesting ride to say the least. First and foremost it's a book on philosophy, which is something I wasn't accutely aware of, though I knew it was involved from various scraps of information I'd picked up over the years. Secondly it's a semi-autobiographical account of a road trip across the US on the motorcycle, and lastly it discusses briefly some aspects of motorcycle maintenance, not the specficics as such, but the process.
I ride motorcycles and that's what drove the initial appeal for me. After watching yet another incredible YouTube production from FortNine, I realised it had to be my next read. What I truly wasn't expecting was to find so much content that resonated with the developer in me. I highlighted a few passages while reading for subsequeuent review, and here are some of those that to me transced the subject at hand and demonstrate lessons that are well worth learning.
When discussing the process behind solving an issue with a non-running motorcycle, I could have sworn Pirsig was talkin about debugging a piece of code, and it dawned on me that debugging isn't a software problem, it's an engineering problem, and working through it looks similar in many engineering contexts:
The real purpose of scientific method is to make sure Nature hasn’t misled you into thinking you know something you don’t actually know. There’s not a mechanic or scientist or technician alive who hasn’t suffered from that one so much that he’s not instinctively on guard.
Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 94). HarperCollins e-books. Kindle Edition.
One of the key tenents that I aim to bear in mind when debugging an issue is this: don't assume anything. The moment you assume a line of code doesn't neven warrant considering because it's "simple", is the moment you condemn yourself to hours of cursing only to come back to that line at the top of the function later, and want to slap your previous self silly. Check that first if statement in the function, don't dismiss it. Start at the start, even when you think you know the start is correct. If you don't, you'll find more than a few times that when you finally work your way back there after exhausting all the 'obvious' options that you could have saved youself considerable time and torment.
Labouring a point here, everybody knows you should write clear code, not clever code. You know this, I know this, but I still can't help myself sometimes. Clever code can be fun, because it offers similar feelings of achievement as to when you were first learning to code, but keep it to hobby projects where it doesn't matter (and no, that's not all hobby projects).
Any effort that has self-glorification as its final endpoint is bound to end in disaster.
Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 189). HarperCollins e-books. Kindle Edition.
'Nuff said.
If you read an older book on writing programs (think from the 80s or earlier), they all start with writing out your code on paper, in pseudocode, and then taking it from there. Sure, they're often talking about ten liners and the like, and editors are better now, but that does't mean you should write code without thinking through your options first.
Your mind was already thinking ahead to what you would do when the cover plate was off, and so it takes a little time to realize that this irritating minor annoyance of a torn screw slot isn’t just irritating and minor. You’re stuck. Stopped. Terminated. It’s absolutely stopped you from fixing the motorcycle. This isn’t a rare scene in science or technology. This is the commonest scene of all. Just plain stuck. In traditional maintenance this is the worst of all moments, so bad that you have avoided even thinking about it before you come to it.
Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 251). HarperCollins e-books. Kindle Edition.
There's no little screw to round out in code, but how often have you found out that the part you assumed would be fast and easy turned out to be anything but? Sometimes the 'easy' part turns out to be the all-but-impossible part, and a little planning ahead really can help avoid those scenarios. Personally I find the best way to avoid those kinds of scenarios is to run my ideas by someone else before I start smashing the keys.
It’s this understanding of Quality as revealed by stuckness which so often makes self-taught mechanics so superior to institute-trained men who have learned how to handle everything except a new situation. Normally screws are so cheap and small and simple you think of them as unimportant. But now, as your Quality awareness becomes stronger, you realize that this one, individual, particular screw is neither cheap nor small nor unimportant. Right now this screw is worth exactly the selling price of the whole motorcycle, because the motorcycle is actually valueless until you get the screw out.
Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 257). HarperCollins e-books. Kindle Edition.
In my last book report-of-sorts, where I wrote about my thoughts on Jon Ousterhout's "A Philosophy of Software Design" I included a quote about leaving code better than you found it. It's one of the core concepts of that book (as well as the idea of shallow interfaces and deep implementations) that's stuck in my head ever since. Sure, here, Pirsig isn't really saying the same thing, but it's a not-dissimilar lesson that we'd all do well to heed.
The place to improve the world is first in one’s own heart and head and hands, and then work outward from there. Other people can talk about how to expand the destiny of mankind. I just want to talk about how to fix a motorcycle. I think that what I have to say has more lasting value.
Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 267). HarperCollins e-books. Kindle Edition.
Personally I've got a lot more to learn about motorcycle maintenance, but working on my bikes does make for a nice change from the the keyboard and screen which dominate all too many of my evenings. Doing so creates the same joys and pains too. Zen and the Art of Motorcycle Maintenance isn't a light read by any standard, but it's one I'll be reading again in the future, because I'm prety sure the first pass only just scratched the surface of understanding.