ego.istic.org

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.

One day, a teacher was checking on a novice, and saw that he was stepping through code in a debugger.

“Why are you stepping through your program?” asked the teacher.

“To check that my program executes in the way I expect,” answered the novice.

“You have compiled with compiler optimizations turned off?”

“Of course,” the novice snapped.

“Then the thing you are stepping through is not your program.”

A teacher once came to the court of Tsukin. The four most enlightened developers greeted and dined with him. The teacher asked them each, “What is a specification?”

“It is a snowflake,” said one. “It first exists as formless moisture, from the primordial chaos of functionality. Time and atmosphere crystallise it into a form, after which it flows, perfect and entire of itself, through the realm of man until it meets with others of its kind and forms a soft, hard blanket to support his steps. It may be covered by other snowflakes, but until the day it melts to rejoin the void it keeps the form it was given.”

“You are indeed wise,” answered the teacher. “It is a pleasure to share a meal with you.”

“My colleague misstates the point,” argued the second. “A specification is like a tree. It heeds the blowing of the wind and the changing seasons. In Spring, it sprouts new buds and extends its sheltering branches. In Summer, it spreads its seed wide, that new trees may fill the areas beyond its reach. In Autumn, it sheds the leaves that weigh its branches. In Winter, it retreats within and hardens itself against the gathering storms. Its shape, its branches and whorls, are different every year, but it keeps the same trunk, the core of its being. Even if it is destroyed and only the stump remains, it will regrow into a new form, yet remaining a tree.”

“You have achieved great insight,” noted the teacher. “The flavour of your observations enhances that of this rice.”

“Yet, I must apologize for the answers of my friends,” stated the third, humbly, “for a specification is like a travelling companion. He knows the country, and can recognise the work of the laws of kings and that of the paupers who follow them. He can tell which places to visit, and which to avoid. He knows the history of the land he travels, and each new journey even adds to his knowledge.”

Again, the teacher answered favourably. “Truly, you are a worthy scholar, and your presence makes the court strong.”

However, the fourth developer disagreed. “He still has not answered well; a specification is like a storm over a town. All know that they must build their houses to withstand its might, yet when it comes, all bite their nails, unsure whether they have done so. When it has passed, some houses have owners proud at the strength of their construction, and others have builders on the roof, replacing the tiles that proved too weak. Everyone rejoices that they will be ready for the next storm, but when it comes, again they worry.”

“A precise description,” the teacher applauded. “There must be some very learned discussions at this court.”

“But which of us is right?” asked the first developer. “Tell us: what is a specification?”

The teacher spoke immediately. “I do not implement vague specifications.”

The five of them sat in silence for a long time, appreciating the dishonesty of language.

A developer once complained to his teacher that his office was too noisy and he could not concentrate on coding. He pleaded with the teacher, “Show me how to achieve meditation so that I may be able to finish my paper.” The teacher scolded the developer, “Do you seek to become wet before getting in the bath?”

The developer asked him again over lunch, “Please teach me this afternoon. My paper must be submitted tomorrow.” The teacher scolded him again, “I am busy all day and have no time to spare. You must seek the way yourself.” The developer was angry but went back to work. Later, he saw the teacher walking by and waylaid him, saying, “I realise that you are busy but please teach me.” The teacher entered his own office and opened the blind. “Very well. I am no longer busy.” At that moment, the developer was enlightened.