How to be a Programmer...
This is an excellent paper, many people in our industry would benefit from reading it.
There are too many really good sections in this paper, so I’ll just pick a few that really struck a chord with me.
Learn to Debug - What great advice. This is something I am personally pretty good at (very good at if I don’t say so). I laughed when he said “Debugging is fun, because it begins with a mystery.”. How true. “Debugging requires creativity and ingenuity” – how very very true!
How to Fix Performance Problems – “The key to improving the performance of a very complicated system is to analyze it well enough to find the bottlenecks, or places where most of the resources are consumed.”. I think he has read Optimizing Oracle Performance (or maybe it was the other way around). This quote sounds funny at first “Often, the bottlenecks in performance will be an example of counting cows by counting legs and dividing by four, instead of counting heads.” But it was really insightful – given the surrounding paragraphs. Find that quote and read the next paragraph about what to do when you run out of low hanging fruit. In my “Is Tuning Dead” talk – this is what I talk about. The software is getting really good at fixing low hanging fruit, there is none left for us many times. Read states “What do you do when you start to run out of low-hanging fruit? Well, you can reach higher, or chop the tree down”. Sometimes the tree needs to be chopped down – I call it “look to your algorithm – you want to go faster – you’ll need to take a serious look at that”.
How to Deal with Intermittent Bugs – “The intermittent bug is a cousin of the 50-foot-invisible-scorpion-from-outer-space kind of bug.”. Good examples in there, something I spend lots of time investigating myself.
How to Conduct Experiments – Indeed! Read that list in the paper. “First, try to be very clear about your hypothesis, or the assertion that you are trying to test. It also helps to write the hypothesis down, especially if you find yourself confused or are working with others.”
How to Stress Test – can anyone say “test to destruction”.
How to Balance Brevity and Abstraction - “There is a certain dogma associated with useful techniques such as information hiding and object oriented programming that are sometimes taken too far.”. Strange, I feel the same way about “generic data models” and their ilk. And then he closed with “It is relatively easy and certainly a good idea to confine non-portable code to designated areas, such as a class that makes database queries that are specific to a given DBMS.” Yeah, “specific to a given DBMS”, that sounds so nice.
How to Tell the Hard From the Impossible – say no more.
Anyway, read the paper – you’ll either a) enjoy it because you learned it the hard way or b) appreciate it having the information/advice given to you because you are in the process of learning it.