The Zen of Programming: Part Five

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. This episode is Part five of me reading the Zen of Programming by Jeffrey James, published in 1988. There is only one part remaining. The book is a tongue in cheek nod to the works of the real Zen tradition. The author has repurposed them into a text on programming, and the result is unlike any book on programming I've read. It's poignant, accurate, and funny. Truly a rare treat. The text is divided into five books. Each book is attributed to a different master in the Zen programming tradition. Book 5 is attributed to Master Lan C. It features colons and this is where the book starts to become really fun. I'll read each colon and add some commentary. Before we get into it, I need your support to keep small batches going. There are two ways you can do that. You can support me on Patreon or by subscribing to Software Kaizen on substack. Your support allows me to keep making fun and educational software delivery Education. Find links to both at smallbachel fm, um, 120 and thank you very much. Okay, now let's hear some coens from the Zen of Programming. The master Lan Tse, tended to teach using the koan, a teaching device unique to Zen. Often the meaning of an individual koan is difficult to resolve, and frequently there are several inner and outer meanings. One, A novice who had studied long at the university went to see the master programmer. The novice said, I have memorized the collected algorithms of the ACM, all 12 volumes of the Art of Computer Programming, and I can program in Lisp, Prolog, Snowball, Algol, Module 2, and ETA. The master nodded politely. It is seldom that I meet a man as erudite as yourself, he said. I would like your opinion of a program that I have written. I would be happy to assist you, said the novice, throwing his chest out with pride. The master went to his personal computer and inserted a diskette. First I must make a copy, he explained. They sat there for a few minutes, listening to the rustle of the spinning drive. Suddenly the computer displayed a message reading no more space on disk. Abort, retry or ignore. The master programmer typed R to retry the operation. Once more they listened to the drive, and once more the error message appeared on the screen. But the master merely pressed R Once more repeating the same sequence of events. Finally, the novice could restrain himself no longer. There is no more room on the disk yet, he said angrily. It is too full, the master said. It is your mind that is too full. And then the novice was enlightened. Here we see a reinterpretation of the classic Zen koan. Your mind is like a cup. It is too full. You must empty it to learn. Thus spoke the master. Any program, no matter how small, contains bugs. The novice did not believe the master's words. What if the program were so small that it performed but a single function? He asked. Such a program would have no meaning, said the master. But if such one existed, the operating system would fail, eventually producing a bug. But the novice was not satisfied. What if the operating system did not fail? He asked. There is no operating system that does not fail, said the master. But if such a one existed, the hardware would fail, eventually producing a bug. The novice still was not satisfied. What if the hardware did not fail? He asked. The master gave a great sigh. There is no hardware that does not fail, he said. But if such a one existed, the user would want the program to do something different. And this too is a bug. A program without bugs would be an absurdity. A, uh, non such. If there were a program without any bugs, then the world would cease to exist. I found this book when Brian Finster posted this colon on LinkedIn. I think it is 100% true, and this is why there will always be bugs. I think this colon is one of my favorite passages in the book. And it gets to the fact that the users of your software don't care all of the abstraction layers that go into producing it. If it simply behaves as they don't expect, they will consider it a bug. And because there's always humans using software producing it and using it, there will always be bugs. The magician of the Ivory Tower visited the master programmer, bringing his latest invention. As usual, the master programmer looked up from his terminal and saw the magician standing in the doorway. What have you brought this time? Asked the master. This is my greatest invention, said the magician, wheeling a box into the room. It is the ultimate desktop publishing system. With it I do everything that can be accomplished with a typesetter, a light table, and a camera. I have designed it so that anyone familiar with traditional printing can learn to use the software in a few months. A programmer can learn it in twice that time. Here is a sample page that I have generated. Behold. It resembles the first page of the Gutenberg Bible. The master programmer examined the sample Output a slight smile on his face. What is the anticipated usage of this device? He asked. We will use it for technical publishing, said the magician. Here's an aside, a special note from the editor. The magician is often used in Zen folktales to introduce antithetical circumstances. It is not known if this personage actually existed. A novice went into the master's cubicle and saw a new computer sitting upon the master's desk. What is that computer? Asked the novice. The master placed his hand upon a small box that was connected to the computer by a wire. Behold, said the master. This device controls what we see on the screen. The novice looked closely at the screen, but all he saw were meaningless symbols. The screen simulates a desk, explained the master. For example, here on the screen is a filing cabinet in a trash repository. Here also is a typewriter and a calculator. This is a wonderful invention, whispered the novice in awe. Uh, it is not as wonderful as it seems, said the master. He took the novice by the shoulders and made him stand several feet back. Can you see the two desks? Asked the master. The novice nodded. One is on the floor and the other is on the screen, he remarked. Just so. Now, is there something missing on one of the two desks? The novice pondered a moment. One of the desks does not have a computer on it, he said. The master shook his head. Neither of the desks has a computer on it. I can't help but feel that the Cohen sees the new PC and mind the fact that this book was written in 1987 as some lesser than the computers of the past. Back when computer users program their own operating systems and assembly and only use terminals or something like that. I just get a, um, back in my day or old man yells at cloud feeling from this Cohen. Now a novice asked the master. What is the true meaning of programming? The master replied. Eat when you are hungry. Sleep when you are fatigued. Program when the moment is right. I think this is absolutely true. Programming is a creative act. There will be times when it is not possible to program, but sometimes the moment is right. The best programs are written in these blissful flow state moments. Hearing a disturbance, the master programmer went into the novice's cubicle. Curse these personal computers. Cried the novice in anger. To make them do anything, I must use three or even four editing programs. Sometimes I get so confused that I erase, uh, entire files. This is truly intolerable. The master programmer stared at the novice. And what would you do to remedy this state of affairs? He asked. The novice thought for a moment I will design a new editing program, he said. A, uh, program that will replace all these others. Suddenly, the master struck the novice on the side of the head. It was not a heavy blow, but the novice was nonetheless surprised. What did you do that for? Exclaimed the novice. I have no wish to learn another editing program, said the master. And suddenly the novice was enlightened. Here we have just another reinterpretation of the never ending problem programmers trying to create new standards. I believe this is also covered in a, uh, famous XKCD comic. A novice asked a master, whenever I program on a new system, I must learn a new language. Why are there no standards? The master turned away. The only true standard is death, he said. 8 A novice asked the master, is there a Buddha nature in the ETA compiler? The master replied, have you ever noticed that the null character is 000 in both octal, hex and decimal? Suddenly, the novice was enlightened. Now for the last Koan 9. Two programmers named Daigu and Guro were making presentations to the president of a large corporation. When he stood up to speak, Guro said to the executive, you are wise by nature and understand the true meaning of computers. Nonsense, said Daigu. Why do you praise this fool? He may be an executive, but he knows nothing about computers. The executive rewarded them both and then hired a consultant to determine which was correct. I think this is a Dilbert esque take on management, but hard to argue with. If you've experienced, I can tell you this type of thing certainly does happen. And that's all for this batch. You can get your own guide to the Zen of, uh, software delivery. I call it the Small Batches Way. The PATH is four Understanding of Continuous Delivery, Software Architecture, Production Operations and tdd. The PATH contains everything you need to become one of the new Zen masters. Get the guide@thesmallbadgesway.com Anyway, I hope to have you back again for the next episode. So until then, happy shipping.