Dan Weinreb’s blog

If you are, or want to be, a programmer, you should read “How to be a Programmer: A Short, Comprehensive, and Personal Summary” by Robert L. Read. You can read it free, as PDF or HTML, or buy it as a paperback book for around $12.

It’s 41 pages long (plus appendixes including the GPL), so it’s not all that short. But it’s concise, simple, direct, and packed with extremely useful information that you won’t find anywhere else.

It includes some excellent advice about programming itself, but much more than just how to write code. For example:

• How to Deal with Intermittent Bugs
• How to Work with Poor Code
• How to Deal with Difficult People
• How to Stay Motivated
• How to Disagree Honestly and Get Away with It
• How to Know When to Apply Fancy Computer Science
• How to Handle Boring Tasks
• How to Gather Support for a Project
• How To Tell People Things They Don’t Want to Hear

Based on my own experience, everything he says hits the nail right on the head. I do not have a single major disagreement with anything he says. (I have a few quibbles, and a very few points are dated, as it was written in 2003.)

Here are a few pieces of advice, so you can see what kind of thing he talks about:

• When debugging, you may see things nearby that need improvement, but don’t fix those at the same time. (I make this mistake often; it’s just so tempting.)
• If your system has redundant components so that if degrades gracefully, it’s especially important to have monitors that let you know that this is going on.
• The way you interview a programmer will affect how much he or she wants to work for your company.
• At the end of doing a job interview, sell your company. But you are talking to a programmer, so don’t color the truth. Start off with the bad stuff, then finish strong with the good stuff.

Everyone has missed deadlines because they neglected to include all the factors that contribute to the time it takes to complete a task. Here’s a checklist compiled from various sections of the essay, that you might want to use:

• Documentation
• Unit testing
• Integration testing
• Demos
• Planning itself
• Internal team meetings
• Communicating with other groups
• Dealing with outsiders
• Vacation time
• Sick time
• Mandatory company-wide training seminar
• Scheduled periodic activities
• Maintenance of existing products
• Maintenance of the development environment
• Some failure
• What part will each which individual work on
• Problems that cannot presently even be conceptualized

Make the time in your schedule to read this!

You can find out all about it at http://www.google.com/press/ita/,
and you can Google for “Google ITA” to find everybody’s opinion.  To everyone who sent congratulations, thank you!