Knowing vs Thinking

A lot of the blogs that I read are about programming and project management. They are predominantly written by people that have a lot of online credibility as "experts" in their field. It dawned on me recently, that although I don't have the interwebz cred that they do, I actually have as much or more real world programming and project management experience as most of these "experts".

The funny thing about getting old is you don't realize it.

— Dolly Parton (and I'm sure a lot of other people but that's the google hit I got for the phrase)

Anyway, if being 30+ years old and having worked as a professional programmer for 10+ years qualifies some other guys to pontificate about the business of programming and hit the front page of digg for doing it, I might as well do some of it too.

"I think ..." is a phrase that strikes fear into my heart when uttered during discussions about debugging, troubleshoting or project status. I think means that the speaker is not confident enough to say I know. I know means that it is a dead certainty that the following statement is fact. It should mean that the statement has been verified before sharing it with the team. I think means that something is being vaguely recalled or assumed based on history, pride or prejudice.

I heard the dreaded I think phrase three times at work today. Two out of the three times the speaker was soon proven wrong via empirical research. That in and of itself is not a big deal. People are wrong all the time; it's to be expected actually in the software world. The dangerous thing about I think is that it costs valuable time. A potential failure mode has been identified and the question has been asked if it could be the true cause of the current problem. By thinking this is not the problem it is discarded as a root cause and other avenues are searched. Unless someone else forcefully believes that the cause which is now thought by the group to be disproved it will not be revisited until many other options have been exhausted.

In my experience, it usually only takes a few minutes to know something instead of just think it. These few minutes spent upfront can be critical when an emergent problem is being dealt with. Troubleshooting (at least good troubleshooting) is the process of running through an n-ary tree with a depth first spanning algorithm. The early decisions prune large portions of the search space and if a partition is discarded falsely, it will take great effort to resurrect it.

I'm going to write another post at some point about how I approach building and ordering the decision tree because order is crucial for efficient operation, but the point I'd like to get across today is that each hypothesis needs to be tested in realtime. Know that it is true or false and you will save a lot of time and confusion in the long run. When the issue at hand is a loss of several thousand dollars of corporate income per minute it can make the difference between being fired and getting the biggest bonus of your life. If you approach every problem as thought it were that important you will become a better programmer/sys admin/manager/mechanic/whatever.