A few months ago at work, a charge was put out: “Let your coworkers know what you’re working on! Share your successes, make it clear to anyone on the team how your work is going.”
Well, our tiny development team already knew all that. It was the other 8, client-facing people who didn’t have a clue about whether I was having a good week or a bad week–about 90% of my job is the kind that doesn’t get noticed if it works correctly.
So I was inspired to share something of a “stripped bolt” story one week (which went over like a lead-balloon, but nothing-ventured-nothing-gained). I always felt that story fit a longer form than a Yammer post, so here we all are.
The Deep Background:
This is all essentially a personal telling of a concept I got from “Zen and the Art of Motorcycle Maintenance,” by Robert M. Pirsig. I had received the book when I was 16 or 17 as part of a Christmas bundle and took my first crack at it around 18 or 19. The first quarter of the book or so resonated to a point, but I didn’t get it. I could latch onto a handful of lines and the concepts they represented but in general I just didn’t get it. I set it down, picked up “Good to Great” by Jim Collins (because the operations VP at my division of Wendy’s at the time had fallen in love with it), and went on.
Fast-forward more than 10 years, when I heard last spring that Pirsig had died. Reading the testimonials about him that invariably mentioned ZATAMM made me feel like I had missed out, so I found my copy and read it over a couple weeks around Memorial Day 2017.
This time, it stuck.
The Origin of the Stripped Bolt:
Pirsig’s narrator tells a tale, talking about the enemies of Quality, where he stripped bolt while tearing down his machine. By moving too fast, without being fully present in what he was doing, he applied the wrong amount of torque and stripped the head of the bolt into uselessness.
Suddenly, what had been a routine, annoying task of (I think) adjusting his intake valves had rendered his bike completely useless. He was stuck–trapped unable to move forward and unable to return to the starting point. Also, just as suddenly his tried-and-true methods are no longer sufficient to the task.
He had returned to a beginner’s state.
Pirsig goes on to say this is something that should be chased. The beginner’s state of mind is the one we grow from. We no longer assume we know everything, are taking nothing for granted, making no assumptions. We’re curious, questioning, seeking understanding. He points out this is the entire point of Buddhist koans, and to avoid being on that uncomfortable edge of fresh understanding that comes from not understanding is to stop seeking Quality–because Quality cannot exist without understanding.
So what does all this have to do with software development, code, or anything that’s not high-level philosophy or motorcycles? I’ll tell you: everything.
A modified version of my Yammer story:
The story I shared with the client people at work was about developing a new program to run periodic metrics for our clients–we were essentially automating what someone had been doing by hand with Excel and SQL Server Management Studio.
This was also my first real foray into TDD, but that’s another post for another day. It’s relevant because I had a program I “knew” worked–it gave me numbers that matched the manual version, it created the entities properly, it exported them around without error (in my mock repositories, at least–how’s that for foreshadowing?).
Then we do a live test on the development client, me and my team lead. Everything works fine, until it comes time to export the existing KPIs to the comparison table…and I get an exception. Some silliness about the context being disposed.
This was the day the metrics were due to be published, I should mention. Also, this was a big proof of concept for my entire contribution to the company. Very anxious-making, especially as these methods had passed my unit tests and by all rights should not be doing this.
I did what any self-respecting programmer would do; I spent three or four hours making assumptions about my program and what it was doing, and making adjustments that should solve the problem I thought I had. Needless to say, every time a quick fix failed I fell a little deeper into despair–this was definitely an “I feel stupid” day.
Finally, I decided “Let’s just step through this.” I said it to myself spitefully, as if I were punishing the program for being obstinate and would soon prove it was being 150% unreasonable.
Instead, within three minutes I discovered the exception being thrown much earlier in the method than I thought possible. The enumerable I was trying to use for my inserts was an IQueryable<T> from the client’s database, being retrieved from a service class method that was a contained unit of work. Why did I think this was a workable pattern? I’ll tell you: ¯\_(ツ)_/¯ I’m sure it seemed clever at the time.
Circling Back:
My assumptions were the problem here. I “knew” how the program was behaving. I “knew” where the problems were. I “knew” the fixes. I wasn’t actually present in the problem solving process. I was skipping the most important step of understanding the current reality. It wasn’t until I went back to basics, “Let’s step through this and see what’s actually going on” curiosity and open mindedness, that I was able to see the problem.
Without stripped bolts like these, where we’re completely taken aback and can’t go forward or back, we wouldn’t learn. We wouldn’t remember to keep that beginner’s mind. We wouldn’t have a reason to shed our assumptions and actually understand.
At least that’s what I tell myself when I have a project overdue and I have to say something like “I’m planning to step through this use case locally and see if I can figure out what’s going on.”
Zen, Code, and Reveries 
Leave a Reply