Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

mr_bean (3802)

  (email not shown publicly)

Journal of mr_bean (3802)

Thursday January 05, 2006
09:55 PM

humility, assertiveness and sense of humour

[ #28256 ]

Laziness, impatience and hubris, the 3 perl
programmer virtues may have their source in these
3 critical personality traits from the Psychology
of Computer Programming (1971) by Gerald
Weinberg, apparently one of the first 'people'
people in programming.

Assertiveness is the other side of the coin of
humility, and both are necessary. Without
humility, success leads to overconfidence
(hubris), which leads to blind self-destruction.
On the other hand, assertiveness is like a steam
boiler without a safety valve. And on the
gripping hand, a spirit of self-criticism is like
a safety valve without a steam boiler.

This collusion of opposites is a reason for the
humour of the 3 perl virtues.

The other necessary traits: ability to tolerate
stressful situations, adaptability to rapid
change, and neatness.

This book seems to have got under the radar here.
I wonder why I have heard more about a
contemporary at IBM, Brooks and his Mythical
Man-Month, which appears to have come out 4 years
later in 1975, when essentially the same
observation is made by Weinberg.

It appears like Brooks he escaped from IBM into
academia. It appears the suits sent him back to
do a PhD in psychology. The experience seems to
have only changed him superficially. I wouldn't
call the book scientific, despite the inclusion
of some experiments he did teaching programming.

He tells stories about life as a programmer in
relation to some ideas of academic psychology.
One funny one is about 'a military project that
involved the creating of a world-wide network.'
The government was getting completely fictional
accounts of the progress being made. He also says
that when programmers don't get feedback about
their work, 'they start to vary the input in
arbitrary ways to see the effect--to get some
feedback, even at the risk of a poor evaluation.'

Some interesting hairshirt views about learning:
'When our program does not run correctly, we have
the opportunity to learn more specific lessons.
Quite often, under the pressure of production,
the programmer is tempted to bypass a trouble
spot with a fix that he knows will work, since it
does not use some new technique which he was
trying to master. .. [But] he will have missed a
golden opportunity for learning. No time will be
more propitious for learning than that time at
which the need for learning is felt most
strongly--the very moment when we detect an

Some principles for language design: Uniformity
or 'If a programmer asks, Can I write ...? The
answer should be yes. Just like the child who is
told, No, too often, the programmer working in a
nonuniform language will tend to be discouraged
from trying new things.' This is close to DWIM. I
thought I saw something close to TIMTOWTDI too,
but perhaps what I remember was my looking for

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.