Analytical Thinking

According to the Predictive Index System I’m an analyzer, for what that’s worth. I don’t give much credence to the PI system, but I will say that I’m a bit preoccupied with analytical thinking as a Software Engineer. When the rubber of design, hits the road of implementation a lot of complexity can result. I’m always interested in how people deal with that complexity, particularly when things go wrong and bugs pop up. How one deals with bugs, I feel, is one of the defining qualities of a software engineer. I don’t consider someone highly skilled unless they can deal productively with issues. In fact I might argue that one of the difference between junior, mid and senior developers is their bug solving skills:

  • Junior: No particular methodology and some percentage of the time just gets stumped.
  • Mid: Has some tools and methodologies, may even be good with them, but often will require a fair bit of sweat to get to the solution.
  • Senior: Has a good set of skills, is efficient with them, but can often apply intuition to short circuit the process.

I think the thread that runs through the different levels of skills is analytical thinking – that to me, even more then gdb skills or what not – is the best methodology.

I’m always trying to sharpen my analytical thinking. I make sure that anytime an issue crops up, I not only find a solution, but consciously think about how I’m getting there.

Some of my favorite go to approaches:

  • The truth is out there: I’ve spoken to field reps where during the course of a call the percentage of effected users was quoted at 5% at the calls start and 20% twenty minutes later (later it was actually calculated at 0.4%). Get facts, by personal observation if at all possible. Can you yourself reproduce the issue? Be patient and get facts before working on a solution.
  • Occam’s Razor: What do we really know about the problems, and pursue the solution based on the fewest assumptions.
  • Eliminated all which is impossible, then whatever remains, however improbable, must be the truth. Worked for Sherlock Holmes.
  • Destruction and Creation: Rip things apart down to their fundamentals, and then reassemble them trying to match observations. What part of the code doesn’t seem to fit into the new paradigm?

That last one, Destruction and Creation comes from John R. Boyd. Not particularly well known outside of military thinkers, but I find his stuff quite sharp. His OODA loop theory is another great piece on thinking about thinking.

And of course, avoid problems in the first place. Employ TDD and write robust code. Consider what could go wrong, and if performance demands allow, test contracts at runtime, assume the worst even from code you’re certain is well behaved as it may not be tomorrow.