Feeding My Ignorance

As someone who is, by nature, destined to ponder on "why" it is no real surprise that I often find myself analysing my own thought processes - certainly a road to eternal recursion - thinking about thinking about thinking about....

...

The most recent outbreak of this character flaw saw me considering the fact that I have a knack for sorting out why things are not working as they should - in my work this certainly dates back to 30+ years ago when I was troubleshooting the integration testing of what was an early computerised communication system.  There was no shortage of folks who could define what the system should do; write the code to do it; build the equipment for the code to run on.  However, very few seemed capable of (quickly) getting to grips with why the system was not doing what it was expected to.

I was one of those few - and, from time to time, this skill has been used and honed throughout my working life.

The act of creating some software system requires different skills from the task of sorting out where the "bugs" are.  Hence "doing" and "fixing" in the title of this blog.

So why should some people find it a lot easier to do the fixing than others do.  Its difficult to tell, but I think one of the crucial skills is the ability to think the unthinkable - no, that's not quite right - the unthinkable is just that, unthinkable - but in any situation there is a lot of things that are just "waiting to be thought".

In some ways this skill is what is perhaps a bit lacking (or not encouraged) on most helpdesks where there are checklists to step through to determine the problem.  This is all very well, but the biggest problems are caused by "that which has not been thought of" and therefore it cannot be on any checklist.

I am sure that when faced with a "situation" I do not use a checklist per se - however, I am also pretty sure that my 'method' involves a series of steps that could be codified into a "meta-checklist".  I have used the "meta-" prefix to indicate in this case that what I use is something that in some ways generates a checklist of what I need to do!

I have no intention of flogging this particular subject to death here - nor of trying to explain precisely what is meant by some of what I have said.  What I do want to do is try and draw out some comparisons/lessons or whatever regarding how the "way of thinking" helps me progress through life.

Perhaps the fundamental difference in approach between doing and fixing is that the "do-er" starts by systematically working through to get to a desired end state whilst the fixer starts from an end state and has to determine what road was taken to get there.  I may be biased, but the latter approach has to turn up more options and opportunities than the former.

If I were to have to have a succinct phrase that summed up "what I do" in terms of my job it would probably be "problem solver".  Obviously that is quite a general description, but it covers most of what I do.  Perhaps "situation analyst" would be a better one - since not every situation is a problem - with all the negative connotations of that word, some are most definitely opportunities.  Equally, not every situation needs a 'solution' - what was the phrase used - ah yes - "problem suppression".

First thing is to try to "understand" what the situation actually is.  Not always obvious.  The doer will tend to take things "at face value" and - if you like - treat the symptoms rather than the disease.  This can result in simply moving the problem around.

Next you must come up with some scenarios that "explain" the situation - how did we reach this point.  In the real world this may well be complicated by the fact that the world does not stop to allow you to examine its 'state' - things keep happening - things keep changing the 'evidence'.    Inevitably - and unlike the do-er - the fixer will be facing incomplete knowledge and the certainty that even what he "knows" may well not be the "truth, the whole truth and nothing but the truth".

Sometimes, the do-er is much better equipped to investigate the situation.  This occurs, usually, when the situation has resulted from a lack of 'knowledge' of how to use the system on the part of the user.  So, in effect they have "failed to do something that they should have done".  The converse is often the result of "doing something they should not have done" - or, more correctly perhaps, "doing something that the do-er didn't expect them to"!!

This takes the situation out of the "worldview" of the do-er.  It has been demonstrated many times that we are incapable of visualising something that is unexpected so as soon as that happens the do-er has a problem in that they cannot envisage getting to the state that the system finds itself in, given "normal" use of the system.

The fixer on the other hand simply takes things as they are and starts to hypothesise about how we got there.

There is a downside to being a "fixer" of course - it becomes very difficult to steer a single course.  More often than not they see the options going forward as well as all the roads that have led to the place that they are now in.  However, anyone who has read the rest of my blog will know - I believe that although all roads lead to where we are - there are plenty of roads that are untravelled.  So - in some senses I see not only what has led to where we are now, but also what we 'might' have experienced if we had chosen some of the different roads.

That does not mean that I am any better than anyone else at visualising the unexpected - but I hope that I have in my sights a wider range of the "expected" than most - I am sure I fail sometimes, but I hope that I can envisage more options than the norm.

That - of course - doesn't always help and can, in some situations, be a real difficulty.  Seeing a different point of view rarely makes choices easier - but it sure can help if you would otherwise be stuck - and that is when the benefit of the 'fixer' comes in.

I think that, on balance, I prefer the challenge - the 'originality' - the adventure of being a fixer.