
The Tao Of Programming - muon
http://www.canonical.org/~kragen/tao-of-programming.html
======
visitor4rmindia
> _A novice programmer was once assigned to code a simple financial package._

> _The novice worked furiously for many days, but when his master reviewed his
> program, he discovered that it contained a screen editor, a set of
> generalized graphics routines, an artificial intelligence interface, but not
> the slightest mention of anything financial._

> _When the master asked about this, the novice became indignant. ``Don't be
> so impatient,'' he said, ``I'll put in the financial stuff eventually.''_

I love this one because it took me many many years to "get" this lesson: it's
not about the code. It's about the Program.

EDIT: Minor edits

~~~
silentOpen
I'm not sure I understand this one yet. Could you explain what you mean about
code vs. Program?

To me, it seems the novice is correct here (supposing that those components
produced are required for a good result). Is the lesson similar to that of
building DSLs?

~~~
visitor4rmindia
I will try to explain.

Firstly it is a focus on "results" rather than output. The novice has produced
a lot of output but no results. How would you evaluate if the components serve
their purpose? Are they doing too much? Are they not doing enough? It is only
by virtue of the program's results that you can check. As programmers we tend
to evaluate the code (which is an _internal_ focus) more than the running
program (which is an _external_ focus). This is a great way to learn but a bad
way to deliver anything of value to an end customer.

As a programmer, the novice would understand and be interested in the ins-and-
outs of his screen editor, gui routines, and AI module. However, he would
probably not have the same level of understanding of finance. For a good
product, the novice should concentrate on raising his understanding of finance
to the level where he can deliver solutions to his users. By ignoring his
users (delegating them to an _afterthought_ ), he is making a fundamental
mistake.

Finally, it is a question of _value_. This is key - the most fundamental
aspect of this scenario. The programmer, for all his effort, has delivered
nothing of value to his users. Worse, he does not even have the attitude and
direction required to deliver value. When someone says "I'll put in that stuff
later" (or it's equivalent), you can be sure they will deliver something of
poor quality to the users.

In the end, if you cannot say the work you have done today will make someone's
life better - what is the point of working so hard?

~~~
silentOpen
Ah! I did not understand the emphasis. It didn't occur to me that the novice
would be working on things that were not relevant. Thank you for explaining.
Also, I may still not understand the depth of this lesson, yet.

------
sundarurfriend
Ah, old memories... I remember reading this years ago. And recently while
naming my blog too as 'The Tao of Programming' by myself, I thought it sounded
vaguely familiar (but oddly, didn't think of Googling for it).

But reading this now, I realize this is more like a set of Zen koans than like
Tao Te Ching itself. A little 'poetry' here and there like Tao Te Ching, but
most parts are obviously inspired from koans.

------
radu_floricica
So many pieces of truth in here. Most of them I internalized long ago, but
still there is the odd one which I encountered recently. This time it's
"Software rots if not used". It is indeed a mystery, but oh so true.

~~~
noss
Not such a mystery. It stays the same, but dependencies continue to change and
it does not participate in shaping them or being shaped by them.

~~~
radu_floricica
Not only the dependencies, also the requirements and the people who use it.

But it's more than this. I think the real lesson is that a program is always a
work in progress... like a walking person, always falling forward and putting
one leg after the other to stop the fall. The moment you don't touch it
anymore it dies.

"Working" can be a programmer writing code, or just a user putting data in, or
submiting the occasional bug report... or anything. But the moment it stops
interacting it gets out of sync with the world.

------
MaysonL
Once, a large computer company, seeking to plumb the depths of the Tao,
decided to psychologically test a large group of its programmers, including
its Masters. Unfortunately, they did not have enough copies of the test.
Luckily the test came in two separate parts, so half the group got one part,
and half the second. When the group was done taking one part, the tests were
exchanged, and the psychologist administering the test, following his
programmed script, gave the exact same instructions that he had already given,
ending with "Are there any questions?" He was about to command "Then you may
begin." when one of the Masters shouted out: "Should we use the same
personality as we did on the first half?" The psychologist was silent, and
completely baffled. One novice in the room, and some reading this story years
later, became enlightened.

[Stolen, with slight alteration, from Gerald Weinberg's _The Psychology of
Computer Programming_ ]

------
dschobel
2.4 is my favorite by far:

 _A novice asked the Master: ``Here is a programmer that never designs,
documents or tests his programs. Yet all who know him consider him one of the
best programmers in the world. Why is this?''

The Master replies: ``That programmer has mastered the Tao. He has gone beyond
the need for design; he does not become angry when the system crashes, but
accepts the universe without concern. He has gone beyond the need for
documentation; he no longer cares if anyone else sees his code. He has gone
beyond the need for testing; each of his programs are perfect within
themselves, serene and elegant, their purpose self-evident. Truly, he has
entered the mystery of Tao.''_

------
catherinej
Interesting quote from this re intermittently visible bugs: "Computers
simulate determinism."

