The Shape of Everything
A website mostly about Mac stuff, written by August "Gus" Mueller
» Acorn
» Retrobatch
» Mastodon
» Micro.blog
» Instagram
» Github
» Maybe Pizza?
» Archives
» Feed
» Micro feed
February 4, 2003
(This post is from my old, old, super old site. My views have changed over the years, hopefully my writing has improved, and there is now more than a handful of folks reading my site. Enjoy.)

A little while ago slashdot posted a story to a pdf entitled "How To Be a Programmer: A Short, Comprehensive and Personal Summary". I just got done reading it and here's my review:

Short version: Awesome. Every programmer should read this.

Longer version:

Robert L. Read (the author) has put more programming truths together in a single document than any I have ever seen. I found myself in awe at his ability to put into words what I have learned throughout my programming career. I'm sort of speechless as to what to say about it, but I'll try.

It's basically got 3 sections- Beginner, Intermediate, and Advanced- where he focuses on what you should be learning and doing at those stages. Read them all. It's even got stuff in there that would be very very good for managers to read. It goes over topics from learning how to debug, to learning new skills, and even to how to utilize embedded languages. It was all written in a manner that I think a programmer of any type and level would be able to pick up on- and I don't think it even ever mentioned a single programming language. You will learn from this paper, no matter what your skill level is.

Some of my favorite snippets- "Embedding a programming language into a system has an erotic fascination to a programmer.", "How to Know When to Apply Fancy Computer Science", and "Life is too short to write crap nobody will read. If you write crap, nobody will read it. Therefore a little good documentation is best. Bad documentation is very bad. Managers often don't understand this, because even bad documentation gives them a false sense of security that they are not dependent on their programmers. If someone absolutely insists that you write truly useless documentation, say yes and quietly begin looking for a better job"

My only complaint would be that it never mentioned something that I noticed right away at m1 - you need to learn to how to realize what you don't know. I've seen way too many programmers who thought they were the shizat, with fancy certifications and what-not, but couldn't create a linked list to save their life. Maybe they were missing the part of the brain that groks that information... Not that I know what the solution to the problem is, I've just had the opportunity to observe it. And now that I think about it, I've never seen anybody who couldn't recognize this become a competent programmer.

Anyway, to all my friends that are programmers, read this. It's worth more than it's weight in gold, even if it were printed on 2 inch thick lead paper.