The Three Virtues of a Programmer

[Derrezed]

1) Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.
2) Impatience - The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.
3) Hubris - Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.

Written by Larry Wall in his second book outlining Perl I actually learned these from my comp sci teacher in high school and they spoke to me...
Just thought I would share them and see if people wanted to discuss or talk about how these help programming for those learning.

 

[Office_Shredder]

I don't see how being lazy inspires you to write detailed documentation of your code

 

[AlephZero]

See http://www.pacifier.com/~mmead/cs162/professional.html for the difference between "amateur" and "professional" programmers. (It was written 40 years ago, but it's still true).

Your three criteria are basically "amateur". There's nothing wrong with aspiring to be an amateur programmer of course - just so long as you realize that is what you are doing.

 

[jackmell]

Let's see, I think I'm a pretty good programmer. This is what I think are three good virtues to being a good programmer:

1. Understand programming all the way down to the bit-level. If so, I believe you're going to do some really great things.

2. Break up the programming job into small manageable parts. Get them working individually, then put them together one by one so that you can better manage errors.

3. Try to break it: a successful testing strategy is to break it. If you fail to break it, then you've not reached your testing objectives. The real objective of software testing then is to fail to meet the testing objective.

An anecedote: So I'm runnin' this VAX system, a live 200-user system and I'm in kernal mode and messin' in the system where I shouldn't. I flip one single bit and crash the system. So they come in, "hey dude, what happen to the system?" I say, "oh man, I don't know. I'll look into it." Yeah, I know. That's terrible. Maybe I'm not such a good programmer.

 

[Derrezed]

Well Larry Wall was no amateur, and they should be taken as a joke but with some truth.
The laziness means you find the shortest route to accomplish what your doing, to decrease overhead and memory usage. That's what I took it as but I am very much an amateur but i agreed understanding binary and testing your program to break it are very important. I am rather lazy about documenting my code too lol.

 

[Derrezed]

See http://www.pacifier.com/~mmead/cs162/professional.html for the difference between "amateur" and "professional" programmers. (It was written 40 years ago, but it's still true).

Your three criteria are basically "amateur". There's nothing wrong with aspiring to be an amateur programmer of course - just so long as you realize that is what you are doing.

Very Informative! Especially the bit at the end about executives and programmers.

 

[I like Serena]

See http://www.pacifier.com/~mmead/cs162/professional.html for the difference between "amateur" and "professional" programmers. (It was written 40 years ago, but it's still true).

Nice article. :)

 

[AlephZero]

Well Larry Wall was no amateur

The distiction between amateur and professional has nothing to do with programming ability and talent. (Except that bad professional programmers would disagree with the previous assertion!) Pretty much everything about LW and Perl is "amateur" in Weinberg's sense.

 

[I like Serena]

The distiction between amateur and professional has nothing to do with programming ability and talent. (Except that bad professional programmers would disagree with the previous assertion!) Pretty much everything about LW and Perl is "amateur" in Weinberg's sense.

Erm... what Larry Wall did was very useful to other people.
His original drive may have been to help himself, but he set up Perl in a way that benefits everyone, which I consider rather professional in Weinberg's sense.
The way Perl was designed shows lots of forethought and experience.

(Suffice to say, that I like Perl. )

 

[Derrezed]

Yea I didn't know amateur programmers worked for NASA and created their own very useful computer languages.

 

[jedishrfu]

I liked the article. I worked with some engineers who would often sneer at the programmers. We worked in C on a DOS PC at the time and railed at us cause they could whip out MS BASIC code so much faster until they hit the dreaded 64K limit.

We were building a card bay monitoring system that checked board temps, voltages... roughly 200 sensors. Later I learned that their BASIC version ran faster because they checked only 20 sensors and as they expanded it they hit the 64K limit in BASIC.

I tried to help by telling them to remove the comments, reduce var names... but that only gained so much space and finally I said you need to rewrite it in C to get around that limitation on MS BASIC.

I have to say though that there were a few really good engineers who trusted my comments and would approach programming problems like a programmer and they often acted as the bridge between us and the more hardware centric engineers.

Their manager once told that he could understand the difficulties programmers had as he once wrote a BASIC program. I didn't have the heart or gumption to tell him how naive he was in his understanding.

Often we would be blamed for slow performance when in fact we were coding to a hardware design that used 14 bit integers packed into memory crossing byte boundaries
that required us to creatively use structs and unions in C with a lot of data shifting to get things lined up. To the engineer he saved memory but at the expense of the software having to do more data manipulation.

Nowadays everything is COTS and hence more amenable to programming.

No comment goes unpunished in the corporate world.

 

[rcgldr]

See http://www.pacifier.com/~mmead/cs162/professional.html for the difference between "amateur" and "professional" programmers.

Maybe I missed it, but that article didn't seem to distiguish between programs to be used by other people, while maintained by the original programmer (or abandoned once released), versus programs which will be maintained by other programmers, which would require better internal documentation (better source code documentation, perhaps external documents if special algorithms are involved).

I don't think virtues of a programmer can be simplified into a few one liners, which is why there are so many books about programming methods and styles.