How to be a Programmer
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!
July 11th, 2010 at 10:46 am
Excellent read thanks for sharing. The only weak point is the estimate part. From my experience the estimates work only for things that are similar to the things you’ve done in your past. For the novel things which are usually the ones that add value estimates are pure waste of time. Its more honest to say that you’ll have to do some research and prototyping in order to give even semi accurate estimate. Unfortunately the thing that real world understand by estimates is the lowest number mentioned which is then considered as a hard fact under all circumstances. And if your number is not low enough someone higher in the food chain will provide a lower one. Who said that the programmers are overly optimistic.
http://www.dilbert.com/strips/comic/2010-02-21/