Zen and the Art of Computer Programming
An Essay © 1986 by Larry W. Yother, Ph.D.

Programming is a perfect, if often maddening, example of the creative problem-solving technique. The question, boiled down to its very essentials, is always this: how can I make this (expletive inserted or deleted as you wish) machine do what I want it to?

There are other, lesser, considerations, of course. The system will invariably impose all manner of restrictions: the memory space isn’t big enough, the language is limited, input-output devices won’t do what you would like them to. These become challenges, albeit frustrating ones.

Most of the restrictions, however, are in your own mind. It is very difficult to resist the trap of continuing to look for a solution in the wrong place. If an approach to a particular problem yields no results, the usual response is to work even harder on that same approach. This unfortunate fact seems to be true in all human endeavors, from child-raising to international relations. You, as programmer, must know about when something should be expected to pay off, and, if the time passes and there is no payoff, you must stop doing whatever you’re doing and try something else. You must look around at this point, try to see what you’re really doing, and do something else.

Often the problem is not where you think it is. You might stare at a formula or a loop for hours, wondering what’s wrong with it, when the problem is a duplicate variable or a problem with initialization much earlier in the program. It’s not easy to change directions. You will be convinced that you’re on the right track, that you’ve just about got it, that only a little more effort will solve the problem.

Forget it. It’s the will-o-the-wisp.

Now then, if you have made the necessary change in direction, you may find later that the program still doesn’t work because you have some vestiges left of your old way of thinking. Somewhere buried in the program is a critical juncture which depends on the old way. It will be much easier to find if you know it’s there It is often useful to stop completely and do absolutely no work on the project for a few days.

Now, it is important that you have stopped not out of laziness but to give your subconscious mind a chance to work. What usually happens is that the solution comes to you at some totally unexpected moment, usually while you are relaxed and not thinking of the problem at all. The butterfly lights on your shoulder when you stop chasing it.

There is also a tendency in this game to go for the needlessly complex solution. Computers can do such elaborate and complex calculations and handle such intricate routines in so short a time that one is tempted to keep adding details until finally there is no possible way to understand what has been done. It is too easy to overlook some critical detail if the path through the program is too difficult. It is something like sending a small child to the store for a loaf of bread. Your chances of success are greater if the route to the store is fairly short, passes no playgrounds or amusement arcades, and if you give the child the exact amount of money, than if you send the child on a five-mile jaunt through city streets with ten dollars in his pocket. The great ideas are all simple ones.

How can you keep from falling into this trap?

Awareness is part of the answer. Tell yourself that the danger is out there, and constantly ask yourself if there should be a simpler, easier way to do it. You might enjoy looking at all those lines of wonderfully obtuse, arcane code, loaded with complex algorithms and advanced programming features, all nestled among countless pairs of parentheses (these are especially good if four or five right-hand parentheses all come together at the end), but is it all really necessary?

The artist is ruthless: the most valuable piece of equipment in any art studio is the trashcan. Never mind that you spent hours working up some elaborate procedure. Never mind that it has become your baby, that you feel like a mother to it, that you couldn’t bear to throw it out. Throw it out, if there’s an easier way to do it.

You have not lost everything you throw out. Every process developed, every idea expanded, every algorithm converted to working code, will expand your mind and experience. You have become greater for it. You have learned something. You have “grown,” to use the jargon of the human-potential movement. You can afford to throw it out.

Writing the problem along with your current thinking on paper is a surprisingly useful thing to do when you are bogged down. It’s easy not to do that, to think to yourself, “There’s no reason to write this down; I wonít understand it any better.” Ah, but you will. Very odd how the human mind works, and seeing something in writing will often allow you to organize it better. The time spent drawing charts and graphs is usually a good investment.

And while you’re drawing those charts, feel free to embellish them with all manner of doodling and seemingly extraneous and worthless decoration. The idea is to relax, enjoy yourself, and stay with the problem, all at the same time. Remember what we said about relaxation.

There is also help available from persons who know little or nothing about computers. There are two ways in which an inexperienced person can help you see a solution: in the first way, the person you ask will often see a typing error or other obvious mistake that you have stared at all day without seeing, or, if not totally inexperienced, that person will usually avoid the complexity trap mentioned earlier. A naive individual, not knowing that a problem is too difficult to solve, will often go to the heart of it and see the solution right away.

The second way involves the necessity of explaining what you’re trying to do to someone who doesn’t understand it. Obviously this is very similar to the process involved in writing down the problem, mentioned earlier, but it’s even more so. The process of verbalizing the problem will force you to see it more clearly yourself, and it is very common to see the solution in a flash of blinding insight about halfway through that explanation. You will find yourself feeling oddly grateful to that other person, who has no idea what he or she did for you. In addition to solving the problem, you have created a little bit of human communication, and have grown a little closer to that person.

If you use flowcharts during the planning process, be careful that the inherent constraints in the flowchart form do not inhibit you. Keep the flowchart open and informal, especially during the early planning stages. Fortunately, newer developments in flowchart theory, especially the so-called “top-down“ approach, take this into account. Keep in mind that the flowchart is only a tool, and that it has a nature and form of its own, which may not necessarily coincide with the nature and form of actual program writing.

If the above remarks have any common theme, it’s probably this: respect integrity. Respect the integrity of yourself, and the integrity of forms and processes. Be yourself, and let the process be itself. You’ll do better.