The Zen of Programming: New Manuscripts

Speaker A: Hello and welcome to Small Batches with me, Adam Hawkins. I'm your guide to software delivery excellence. In each episode I share a small batch of the theory and practices along the path. Topics include DevOps, Lean, Continuous Delivery, and conversations with industry leaders. Now let's begin today's episode. It has been a surprisingly long time since we last spoke. I did mean it when I said Small Batches will return in 2025, though I did not mean for it to be this late into the year. Simply put, my flow was completely disrupted. I've struggled to find the flow that enabled me to reliably and predictably produce this podcast. I don't know if it will reappear in the same way, but for now, I'm here today with the first episode of Small Batches in just about a year. So, dear listener, I appreciate your patience and hope to reward you with only an episode that small Batches can deliver. I left this podcast in 2024 reading the book the Zen of Programming. It was published in 1988 by Jeffrey James. It's a tongue in cheek reference to the works of the real Zen tradition. Now, my deep study surfaced a lost appendix to the original manuscript. This lost appendix was published in the last few years, making it markedly modern compared to the original edition published about 40 years ago. I was pleasantly surprised to see my own learnings distilled in this appendix. Even better, the Master used all the styles of the other masters in this manuscript. So in this episode, I give you the insights of the multifaceted software ronin Master Kaizenji. Master Kaizenji is said to have walked the entire software development life cycle. Unlike other masters who devoted themselves to a single cycle, Kaizenji became proficient in local and global optima, often blending them in unusual and surprising ways. Now, some scholars speculate that he was once a wandering part time cto, moving from one chaotic company to another, finding the patterns that often eluded others and distilling them into words. Legends claim that Kaizenji never completed a single project in the conventional sense. Rather, he left behind trails of insight scattered across multiple mediums. His haiku captured the fleeting frustrations and triumphs of debugging. His Cohens challenge even the most seasoned developers to reconsider what a program truly is. His Analects record cryptic yet profound reflections on software evolution, and his chronicles and float tales recount epic sagas of collaborative coding under impossible conditions. Though no living programmer has seen him in decades, Kaizenji's works continue to circulate in whispered references and hidden git repos it is said that when a developer reaches a moment of profound knowledge, a fragment of Kaizenji's teaching appears in their code, as if the Master himself is still guiding the hands of those who seek the path. The first reflection is found in a haiku from Master Kaizenji. It captures a fundamental truth that programmers struggle with. Developers scream into the void of tech debt. CASH REGISTER RINGS this one hits me hard because it's a hard learned lesson. Programmers are craftsmen. There is an assumption that high quality craftsmanship means higher customer satisfaction. This is simply not true. Software quality, as seen by the developers, is not a measurable quality by the customer. The customers simply see what it does for them, regardless of how well or how poorly it's built. This effect may be so pronounced that developers can be banging their heads against keyboards while customers are happily paying for premium tiers. The point is not that software quality is immaterial. The point is that they are not directly correlated. The poorest and most frustrating to work in codebase can create immensely profitable businesses and many happy customers. The next reflection comes from a Cohen. In Master Kaizenji's Lost Manuscript. The koan recounts an interaction between a student and the master. A student raged to the master, our code is a cursed forest, twisted, rotted and unknowable. Nothing could be worse. The Master led him to a sealed chamber beneath the temple. Inside lay a program etched on brittle paper written in three languages that no longer exist, its logic branching like a creature trying to escape itself. The student whispered, who would build such a thing? The Master closed the chamber door. No one built this program, he said. They simply discovered what someone else feared to face. And then the novice was enlightened. Master Kaizenji hits two core points in this colon. The first point is that poor programs are not built instantaneously. They are the result of accumulation. One choice introduces a poor architecture pattern. Future code changes continue to use the pattern. Eventually, something else comes along. The old code remains. New code uses a new pattern. This is just one way code becomes twisted, surprising and difficult to change. It's easier for new programmers to come into a code base and think retroactively about the past decisions to only see the current state. And this is what leads me to my second point. The second point is that all those accumulations are mostly rational decisions in the environment at the time. People often don't think to themselves, you know what? I should make this code objectively worse. It's more likely the case that they're thinking, what's the best fit for what I need to do and can do at this time. Codebases may reach a point where attempting to pay down the technical debt is just too risky. This is especially true of the difficult and system wide architectural problems that ah, require roadmapping or executive buy in or even specific initiatives and okrs. The team may want to do something about them, but they are fearful of what confronting them actually costs. This next reflection is in an analect from Master Kaizenji. An analect is a fragment of conversation. This one is between an engineer and Manager. My new process will solve everything. It will not. Manager. Regardless, I expect you to follow it precisely. Engineer. We will follow it until it slows us down. Manager. And then, Engineer, we will quietly do what works. Manager, you cannot do that. Engineer. We already have. My takeaway from this anecdect is that there is always the documented and shadow process. The shadow process is what actually happens on the Gamba. This is the real process. If people want to understand the real process, then they must go to the Gemba. Going to the Gemba will dispel any illusions. And moreover, there will always be some level of shadow process. One should work to minimize the delta between the documented process and the shadow process. Then Kaizen is possible. The next reflection comes from Master Kaizenji's chronicles. A chronicle is a narrative that records events over time. Day one. The disciple approached the Master with a full Jira board. Master, we have estimated each task. Our sprint is planned with detailed subtasks and user stories. The Master replied, stirring a cup of tea. Do the tasks move faster because they are counted? He asked. Or do they move when the moment allows? Sprint 3. A bug appeared unexpectedly. Velocity charts no longer reflected reality. The disciple detected a problem. Master, the work is behind schedule. The master casually gestured to a window. A cherry blossom fell from the tree into the river. The river does not rush. It flows. Where the channel opens, so does code. Month five A uh release arrived. Unpredictable and imperfect. The disciple bowed. Master, how could we have known? The master sipped his tea. To know is to see what already passes. Planning is only a mirror of intention, not of outcome. This is a reflection on the nature of software development. The best laid plans are at best a hope. In practice, they are broken the moment the work truly begins. Different approaches are better suited to accommodate this reality. Trying to control chaos in the cynefin sense will not work. You must probe to gain understanding and then seek to move the system into another domain. Flow of information or deliverables is all that matters. At the end of the day, your approach can either embrace this fact or constantly struggle against it. As Master Kaizenji says, the work moves when the moment allows. This final reflection is in a folktale from Master Kaizenji. I dedicate this folktale to my teammates for their work over the last year. Weeks passed. Lines of code collapsed and reformed as if alive, stubborn and unyielding. Each morning, one programmer would arrive to a tangle of errors left behind. Another would return mid afternoon to trace a function that had refused to work the day before. Days turned into weeks, weeks into months. Functions that seemed broken beyond repair slowly began to respond, only to twist themselves into knots once more. Still they returned. Keys clicked in rhythm, screens glowed late into the night, and ideas were passed silently from one to another. And in the end, when the program finally ran without collapsing, no one remembered who had typed which line. What remained was the quiet presence of hands and eyes moving together, threading through the impossibility day after day. This folktale covers one of my deeper learnings on the socio technical systems we work in. The technical end can completely collapse, and the social end can act as life support in the face of great and many challenges. This is part camaraderie and part interpersonal respect, I think. So don't discount people's ability to overcome challenges when they're paired with like minded people. And that's all for this batch. I hope you enjoyed these excerpts from Master Kaizenji's work. Now, I cannot tell you when I will be back again. Just know that I am attempting to to stabilize my flow to get back to a reliable episode schedule. There is still more small batches in software Kaizen to come. So until then, I hope to have you back again for the next episode. Happy shipping.