> Don't rewrite code without consultation.

This is linked to a pet peeve of mine, especially with restless, young developers. There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it". I don't know how many times I've seen someone go down the path of seing battle-tested code, not understanding it, thinking they can rewrite it better only to spend a month falling in to all the same pitfalls that lead to the original code. The middle road is of course refactoring. Cleaning up the code in small, discrete steps to something you can understand and work with is many times better than just tearing stuff out and restarting.

I hate this list. It should really be called the Ten Commandments of Good Little Worker Programmers. The 'commandments' are all about creating nice friendly programmer cogs that work smoothly together, minimising hassle for their employers.

There's nothing there about programming as an art. There is nothing there about pushing the boundaries of what is possible through determination, vision and, yes, ego. There is nothing about solving complex technical problems through sheer force of will.

To hell with 'egolessness'. Why shouldn't programmers have an ego. And, indeed, doesn't it take an ego to do anything great, to think that preposterous thought that you can do something no-one has done before.

> The only true authority stems from knowledge, not from position.

That's certainly not the full story. In many organizations, having a lot of knowledge about something that someone else is supposed to know more about is a good way to make them feel uncomfortable or in extreme cases dislike you.

From a practical vantage, knowing how to apply what knowledge you do have (and having the will to follow through) is a lot more valuable.

It doesn't help to have a broad and deep understanding of software development and business but be socially awkward and suffer from severe akrasia.

It is interesting that all of us are getting a different takeaway from this list; something different resonates with different people.

It also surprises me that these lessons originated in 1971 (though I had not heard of this text until just now.)

Back then, IBM was hiring English majors and training them in assembly to work on OS/360 etc. It would not have occurred to me that developers back then would have cultivated a stereotype of a "prima donna."

Because to me, and perhaps this is a reflection of my age, it has only been recently that the popularity of joelonsoftware-esque "pamper your developers!" has led to a culture in small companies where we demand free beer and 36" Macs as a condition for employment.

Or has it always been that way for developers (of young tech companies; none of this really applies if you work at Fidelity Investments) modulo the greatest tech of the day?

* Be kind to the coder, not to the code. ^ * Treat people who know less than you with respect, deference, and patience. - My friend/cofounder has been inspired by the codeyear thing and have been bringing to me a lot of silly code issues... guess i was being a bit rude with him lately.

The corollary: All human knowledge can be known.

Sad times when Atwood is giving coding advice ...