ego.istic.org

We were sitting around a table in the foyer of Cambridge Buddhist Centre. He was drinking tea and parroting what he'd been told by some neo-Buddhist lifestyle guru.

“The big fact is, you have absolutely no influence over the world—the relative world, that is. None at all. So there's no point trying to change it.” After making this pronouncement he swigged his tea and set it on the table with a defiant grin, looking around for signs that someone was going to disagree.

I ignored his unspoken challenge and slid his mug a few inches along the table until it was in front of me. “Do you understand?” I asked.

He answered by picking the mug up and placing it back at his position. “You see? You can't control it at all.”

“But the mug is exactly where we both wanted it to be.”

The teacher at the temple of Gurantsa was approached by a worker from a nearby technology company.

“Teacher, I have observed something that troubles me. In my company there is a manager who does not communicate. Customers tell him their requirements, but the information never reaches those who design the products. Engineers tell him what resources they need and what specifications they are using, but their messages remain unread. Despite his behaviour, he receives even more information. Why do people keep giving him information? Why do they not see that he will not pass it on?”

The teacher answered, “In electronics, it is common to use a device made of two conducting plates separated by an air gap. Although the air gap breaks the circuit, the plates are close enough that charge on one plate can see the other. Current flows around the rest of the circuit, and charge accumulates on the plates.”

“You are speaking of a capacitor,” interrupted the worker.

“I am. But your manager is not an electrical capacitor but an information capacitor. He is a device across which no information can flow, consisting of two ears separated by an air gap.”

At that moment the worker was enlightened.

A programmer visited his master and asked for guidance.

“In my project I have to choose between two options. I can decide to do some computation in software, or on a specialist piece of hardware on my device. I have carefully studied the pros and cons of each approach, and both of them have serious shortcomings. Which option should I take?”

The master thought about his problem carefully, then answered, “I think you should use the third option.”

“But, master, I spoke of only two options. If you have seen some third plan pray tell me what it is.”

“Simply that you should use the third option.”

The programmer became frustrated. "Are you sure this option exists? Don't keep me in the dark.”

“There is indeed a third option. I advise you to put it into action as soon as you can.”

That night the programmer tossed and turned in his bed. He thought long and hard, trying to discover the third option. Eventually he realised that the major problem with his software solution was impossible to avoid by any approach. Annoyed with his master's deceit, he followed his original plan of using software.

Many years later, after the master retired, the programmer was promoted to Head of Development. One day a troubled novice came to him for advice.

“Master, I have two potential courses of action. I need to decide whether to cache interim results at the client, or always store them at the server. The first option has performance implications, but the second has security problems. Which should I focus on?”

At that moment, the old programmer became enlightened.

There was once a group of programmers who were also great friends. As programmers, they made great strides together along the Way; they also spent their leisure hours together in mock combat, song, and debate about the dharma.

One day the friends were joined in the temple by another programmer.

“Dine with us tonight,” said the first friend jovially, “and we shall cement a new friendship in the tea ceremony.”

The second friend opened his arms wide. “Yes, you must dine with us, and tell us your experiences, that we may progress together towards enlightenment.”

The new arrival nodded, and followed the friends.

That evening, the group indeed welcomed their new friend. They ate well and all spoke loudly and eagerly, save the new arrival, who finished his meal quietly. He retired early and meditated.

The friends were puzzled at this, and decided to treat him again the following night. They arranged a great feast, but again the new arrival was quiet, speaking only to directly answer questions.

Over the succeeding days, the new arrival joined the friends for a mock combat, for meditation in the temple, and for meals, but each time he kept to himself.

On the fifth day, the friends were loudly arguing a point of the dharma, when the new arrival interrupted. He spoke wisely and at length, convincing them about the whole matter.

One of the friends asked him: “Why is it that you have been so shy for so long and now speak with the words of a teacher?”

The new friend answered, “It is usual for newbies to lurk before posting.”

From that day, the new arrival was respected greatly, and the group remained friends to the end of their days.

A competent but inexperienced programmer once asked a visiting teacher a question.

“I have often heard you advise that a programmer should not only talk to his boss but also his boss's boss, but I do not understand. Surely this is a layering violation?”

The master asked a question in turn. “You usually program in C++, but you also know some assembly language. Correct?”

“I know a little assembly language, but I use it far less often than C++.”

“Why is that?”

The novice thought for a moment. “Sometimes I discover bugs in my C++ compiler, and can only confirm them because I can check the compiler's output. Sometimes the compiler produces inefficient machine code, and I can make my program faster by talking directly to the hardware.”

The teacher turned and left.