Reading the Zen of Programming. Part One.

Speaker A: Hello and welcome to Small Batches with me, Adam Hawkins. I'm, um, your guide to software delivery excellence. In each episode I share a small batch of a theory and practices along the path. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let's begin today's episode. The next months of episodes will be different. I'm trying something new. I came across a haiku posted on LinkedIn on the nature of bugs. It was profound and wonderful. I tracked it back to the book the Zen of Programming by Jeffrey James. The book was published in 1987. It's a bit of a tongue in cheek nod to the works of the real Zen tradition. The author has repurposed them into a text on programming. The result is unlike any book on programming I've ever read. It's poignant, accurate and funny. Truly a rare treat. The book is out of print, but you can still find it on ebay. So that's what I did and read it in a single sitting. It's only about 50 or 60 pages. The text is divided into five books. Each book comes from a different master in the Xen programming tradition. Each book uses a different medium. Book one uses Chronicles. Book two uses Folktales. Book three uses Analects. Book four uses Koans. Last and by far the best. Book five uses Haikus. I'm going to read it on the podcast with some commentary. One book per episode. So in this episode I'll read you the foreword and introduction to the Zen of programming. Here we go forward. There is little doubt that an ancient art of programming is generally misunderstood by the Western mind. Popular opinion considers it a type of engineering, mechanistic and materialistic. Many people believe that programming is merely a means to an end, and that a program and a programmer can only be judged by the ability to make money. These primitive misconceptions come from a profound misunderstanding of the true purpose of programming. The superior programmer does not strive for surface accomplishments, but seeks a mystical identification between human and machine. In the light of Zen, there is no separation between hardware, firmware, software, interface and comprehension. Rather, all of these are combined into a harmonious whole. Attaining this state is only possible when the programmer has finally learned to set aside the false sense of ego with which most of us live our lives. This is computer the way of the Zen programmer. It is sometimes said that a programmer who has mastered Zen has mastered life. Such a programmer views the world with an inexhaustible childlike joy. Walking down the street, the enlightened programmer can sense the computers in the houses and the buildings on either side. The enlightened programmer can feel and hear the steady hum of the electrical pulses of modulated data transmission flowing through the telephone wires. The enlightened programmer has become one with the universe. As a teacher, I am naturally gratified that my former pupil Jeffrey has been able to perform so great a service as to bring the lost classics of Zen programming to light. It is to be hoped that this volume will re establish Zen as an essential part of the well rounded programmer's education. Written by Dr. CPU the College of Machine Transcendence, Lotus University, Lhasa, Tibet now onto the introduction when Mr. James asked me to provide an introduction to his next book, I could think of no better way to accomplish this than to relate my own personal experiences in the arcane realm of programmatic maintenance, one of the least understood of the deadly arts of programming. I do not doubt that some readers will maintain that there is little in common between the, uh, profound teachings of Zen and the humble art of program maintenance. But as the Master said, the way or path is in all programs, even in a video game. Therefore, it must also be true that the long neglected art of program maintenance must have its Zen aspects, though they might not be immediately apparent to the untrained mind. My story begins a few weeks after I had graduated from college with a bachelor's degree in computer science. My goal upon graduating was to work for a research and development organization, preferably in compiler or operating system design. I finally found an organization that was willing to hire me, but only on the condition that I learn the system by performing program maintenance for an unspecified period of time. Naturally, I was somewhat offended at this suggestion. I had not gone through five years of college just to waste my time fixing some other programmers mistakes. However, there was the promise of interesting work in the future, so I accepted, making a mental note that I could always find another job if this one did not work out. When I reported to work the next week, I was taken to meet the master of the maintenance group. The personnel manager led me quick step uh, through the darkened corridors of the development center, finally pointing out a door at the end of a long hallway. He's in there, she said, and then scurried away if ill at ease. I walked to the doorway and peered inside. I saw a man working at a terminal, but his back was towards me, so I had no idea of his age or appearance. I was just about to make my presence known by coughing when without as much as a single backward glance, the master said, please be seated. I peered over his shoulder at the incomprehensible display that flashed upon his terminal as his slender fingers danced across the keyboard. Finally he gave a little grunt of, uh, satisfaction, logged off, and then turned to face me. What I saw surprised me, for he did not seem to be the type of man who would be a Zen master. His face was bland, almost ugly, and his hair formed a confused nimbus about his head. But what one noticed first were his eyes, which showed pale blue even through his thick spectacles. He inspected me from head to foot and nodded, as if confirming a private opinion. So you are the new hire? He asked sourly. Yes, I replied, simulating enthusiasm I did not feel. I gave him a quick rundown of my experiences and grades in college. The Master listened politely and then said, that is all well and good, but have you ever done program maintenance? I confess that I had not. The Master heaved a great sigh. Well, we shall do what we can, he said. Then he took an enormous program listing from the shelf. Opening it at random, he handed it to me and asked, what do you make of this? I stared at the listing. It was assembly code intermingled with some strange macro language. Every tenth line transferred control to some cryptic subroutine, and if there was any structure to the program, it was incomprehensible to me. What is this program? I asked. The Master took the listing from my lap. It is the code of the Ancient Masters, he said. And when you have learned to snatch the error code from the trap frame, it will be time for you to leave. Then he closed the listing and returned it to the shelf. I soon learned that program maintenance was more difficult than I had assumed. I first attempted to learn the assembler in which the code had been written, but much to my annoyance, I discovered that the assembler had never been properly documented. All that existed was a set of notes from the hardware developers who had either died or left the company many years before. The code was of little help. It is true that there were occasional comments, but these were as opaque as the assembler, containing nothing but tantalizing references to primeval hardware architecture. When I complained to the Master, he listened politely, created a long moment of silence between us, and then answered me. You are seeking to understand something that cannot be understood by your rational mind, he said. All that results is frustration. You must empty your mind. Only then will you come to understand the code. And the Master began solely at first, to explain the convoluted logic of the code of the Ancient Masters, and as I listened to his calm and passive voice, I finally began to perceive a glimmer of the vast and eternal light that was hidden inside the code. The Ancients knew nothing about good programming practice, the Master said. They sought to understand the inner workings of the universal computer mind. What need did they have for proper documentation? The programs were expressions of the ultimate. But though I was slowly coming to understand, I felt as if I were a fly struggling in amber. So much of what the Master said went against what I had learned. So little of it made sense to my rational mind. But the Master was always patient with me, explaining again and again that I must stop trying to think with my rational mind, but rather to apprehend the meaning of the code subconsciously. After many months of instruction, I felt confident enough to attempt my first patch. Hoping to surprise and please the Master, I did my work secretly. I wrote a patch that reworked several lines, reassembled the program, and then released the new program to the production system. The next morning, I came in a little late. Much to my surprise. The director of the Development center was in the Master's office, along with the personnel director. The personnel director saw me as I walked up the hall and closed the door. I heard loud voices, but could not understand what was said. I, uh, waited until the visitors had left and then went into the Master's office. Well? I asked. Your patch was brought up on the production machine at exactly 6pm yesterday evening. It has now been removed, and you still have your job, said the Master. At last, I understood the total futility of my efforts to understand the code with my rational mind. And with this came a great sense of despair. Sensing this change, the Master began teaching me secret techniques of meditation and debugging, techniques that he claimed had been handed down from the support group to support group since the dawn of the computer age. And as I listened, I came to realize a great truth about my prior experiences with programming. In college, I had thought that the main task of the programmer was to control the workings of the hardware and software, and that the highest art of programming was the successful application of good programming techniques to accomplish an assignment or goal. But program maintenance is not like program development. To maintain a program is to treat it like a growing plant. It avails nothing to pull and tug at a shoot in an attempt to make it grow faster. In fact, such activity usually serves to kill the plant. A program must be nurtured carefully before one makes changes. One must be familiar with every convolution of logic and possess a deep understanding of the program's purpose. This understanding does not come overnight, but it is built up over time. After many months, I was at last able to make successful patches to the code, but only after long sessions of meditation, the listings propped open on my desk. I also found that it was easier to concentrate if I burnt some incense as I worked, never forgetting to repeat the mantra that the master taught, Nol so stix ex eot, which he said signified the five fold beginning of the universe. And soon I found that I no longer cared whether I received credit for my work or nor did I see any separation between myself and the programs that I maintained. And like a man who has lived in the shadow all his life, I began to understand the, uh, Zen of programming. The ineffable and indescribable power that lies behind all programming like a sun that casts shadows on the earth. Freed from the meaningless promptings of, uh, my ego, I came to realize that those mighty lines of programming had only seemed obscure to me because I had not yet become enlightened enough to understand them. I now knew why the ancient programmers had never documented their programs, for an English language description would have been more confusing than enlightening. Then one day I found myself working on a problem that dealt with the most complex part of the code, the error analysis routines. Without knowing it, I issued a patch that determined an error condition from examination of the contents of the hardware trap area, allowing the program to continue execution correctly. That afternoon, for the first time, the master programmer entered my cubicle. He put his hand down upon my shoulder and looked down at me. Time for you to leave, he said. Such m was my first experience with Zen programming. Though I have been assigned to many projects since that time, I have never forgot the teachings of my first master. Imagine my surprise then, when I discovered that so many of the Master's favorite sayings in the Zen of programming. At last I began to see the ancient traditions that lay behind his unforgettable teachings. The world owes a debt to Mr. James for his rediscovery of that classic and seminal work, which, but for his perseverance, might have been lost forever. Mr. James has collected in this volume a treasure trove of the peripheral Coens tales and the poems that comprise the outer teachings of a legendary integration sect. It is through the efforts of scholars such as Mr. James that the immortal light of enlightened programming will shine upon future generations of humanware. Written by Charlie Chuck Babbage. Now I realize I forgot to read something important here, which is the preface to the book. This is actually written by the author of the book himself, also going by the editor in the text. The publication of the DAO of Programming was so well received by the programming public that I was asked by Info Books to present a translation of the peripheral and related texts that served to complement the famous classic. Although I protested that my abilities were inadequate to the task, I was at length persuaded to attempt it. The present volume is the result of many months of study and translation. It attempts to encapsulate a complex subject through the presentation of excerpts from the traditional source works. I have little doubt that many compure theologists will question my selections. Why did he not include the parable of the Unix programmer, the Elephant and the prostitute? They will ask. Or how dare he neglect the time honored tales of Turing's adventures in marketing land? To these critics, I can only say that I've done my best to make a, uh, representative selection. To date the various passages in the text, I have utilized the Dynasty system. For those not familiar with this method of dating, there may have been four dynasties or generations. The First Dynasty, the so called Golden Age, harkens back to the days when computers were constructed of glass tubes. Most modern scholars have concluded that this era is mythical. The Second Dynasty begins with the invention of the transistor and ends with the invention of the printed circuit. Modern computer history begins with the Third Dynasty, which was dominated by mainframes and the warlords who controlled them. The fourth generation begins with the suppression of the Integration Sect, whose rebellion against the established order was brutally crushed by the fanatical Blue Legion. Ironically, it was this suppression that led to the spread of Xen programming into the outside world. In addition to the traditional material that makes up the body of the present volume, I have been fortunate enough to secure the assistance of Doctors Babbage and Yu, who were kind enough to provide the introduction and foreword respectively. It is my hope that their contributions to this work will in some small way serve to overcome my own inadequacies as the editor. Jeffrey James. Alright, so I hope that gives you a flavor of what to expect in the next episodes. As you can tell, this is certainly unlike any book on, um, programming you've likely ever read. But trust me, this is a good one. And that's all for this batch. Go to Smallbatches FM116 for a link to the Zenith programming um, and this month's free giveaway of Release it. The next episode will cover book 1 Chronicles from Master Ninja. Anyways, I hope to have you back again for the next episode, so until then, happy shipping.