Logic for the helpless

Agreeing to disagree

There is nothing I enjoy more than the buzz of logic, the challenge faced with consuming information, much of it jumbled and disparate, eliciting points that feed the process of elimination and leading you to a point of forceful affirmation of the conclusions you have drawn.

When it comes to these things, I do not enjoy being confrontational, but I need to be persuaded, having a hunch will not do, the data, the facts, the thinking and the wherewithal must be laid out for scrutiny. It could seem like a clash of egos, a joust of knowledge minds pitted against minds almost to the point of exasperation.

Trust is valuable

Much as I have wanted to entertain some earnest protestations most of today, I just was not carried along with the premise. My dashboard was informing me that things were fine, yet I was being fed contrary indicators that could not be explained. I have to be able to trust what my dashboard is telling me or have nothing to work with.

I have spent decades poring and sifting through logs to reconstruct events and activities, it is almost an art of divination. I have an open mind, sure of what I know, and ready to learn new insights, it is exhilarating. It is also understandable that others might interpret logs differently and quite outside the moorings of what they intend, that is a given.

The detailed proof

This is where an eye of the minutiae and detail comes to play. You cannot afford to miss essential information, words and jargon used, timings, relationships, and expected outcomes. I could be lazy not wanting to devote time to that because of my conviction, then, you cannot avoid it. It needs to be done painstakingly and thoroughly to debunk any assertions completely.

That is where the buzz sets in, you feel the racing neutrons coursing the channels of deliberate and considered thought. The temptation to obliterate beckons but the better nature to educate gains prominence. In the end, we are here to help, but if you want to make it my problem, speculation and escalation just asks to prove where the problem is, and how we can work together to help you solve it.

Sound logic and incontrovertible evidence

The techniques are hardly obscure

There are some things I like about the work I do that could be irritating for others who may not understand the intricacies of the technologies at play. On occasion, I get a report suggesting the system is not working, which is understandable from their perspective.

What irks me is when technical people refuse to be technical by not reporting the issue with observational and the crucial detail necessary to pinpoint where the problem might be. There are so many parts to the system which needs to run in order, from it beginning through it failing during any number of visible processes and probably at the end.

The detail is revelatory always

Along with this are chatty logs, a real-time journal of activities that one expects these technical users to be able to review, but for their disinterest or some other thing. It does not make it fun when you find that people put in no effort.

In any case, you review the situation and pinpoint with incontrovertible and documented evidence of what the issue is and how it arose. The solution should not have to be dictated to any other expository verbosity, it should be obvious as it is bright sunlight, but no, they hesitate in disbelief and then expect you to embark on an unnecessarily timewasting rigmarole of trial-and-error, which I just can never have the time or patience for.

Once the case is closed, that’s it

Once the situation is proven, that is the end of any analysis, I am not in the business of make-belief or magic, there is qualitative logic to what we and my engineering background cannot be diverted towards the esoteric for either entertainment or conviction.

Sometimes, I wonder, if I were a lawyer using the law of evidence, whether anyone who suggests a hypothetical line of discourse once I have closed my case. I think not. Take it as it is except if you can present better evidence. On that, I am up for the challenge and ready to learn something new.

Thought Picnic: I don't know it all

Know why you do

In my line of work, I have variously found myself at loggerheads with others when it comes to problem resolution.

In context, it is important for me to understand why scenarios and circumstances present themselves before seeking a range of paths towards solutions that might resolve or eliminate the problem entirely.

A background in logic

There are many people who come from many walks of life and careers into the Information Technology profession taking up roles from design and architecture, through project and change management to support and much else.

It goes without saying that whilst many again are good at what they do when things are working like clockwork, the gaps in their fundamental knowledge of things begin to show when problems or emergencies arise.

There is a great user and support community out there from where one can get answers to a range of issues and problems. Yet, being able to craft a question properly or explain the scenario properly lends itself to other being able to visualise that setting and hopefully present ideas, opinions or clear solutions with steps to implement them to resolution state.

What an engineering mind gives you

My engineering background requires that there must be a purpose for any activity undertaken towards obtaining a solution. For me, it has to be logical, sensible, goal-oriented and capable of advancing knowledge and experience that any other similar scenario can literally use those steps as a template.

I do not work too well with trial-and-error, where purpose and goal are lacking that brawn rather than brain is used to hopefully get an unexpected outcome that then turns out to be the solution.

Because there is no particular method to trial-and-error problem resolution, stumbling upon a solution might well be fine, but you are left with whether you can backtrack and formularise those trial-and-error steps into a clear guide with full understanding of the problem, why the problem arose and what can be done to resolve it.

Reading the runes

I regularly peer through error logs trying to ‘divine’ from the logs what set of circumstances have presented the error observed from after. In doing that, I have to make more deductions over assumptions to begin to make headway.

In many cases, what the logs tell me gives me a sense of certainty about where things have gone wrong and possible insights as to how to right the situation. It is at this stage that I might become unpersuadable of alternative thinking if the logic and the reasoning is neither clear nor convincing.

In exasperation, I have sometimes walked away from a situation, though usually after I have shared my views and wait for the doubters to come to the conclusion that I might have been talking sense all along.

I don’t know it all

Yet, I have to be careful that this assuredness does not descend into intellection arrogance blinding me from other perspectives and perceptions. It is important to have a good idea of what knowledge you have, what knowledge you do not have and most pertinently be quick to retrace your steps where the absence of knowledge has precipitated into negligence or ineptitude.

Ignorance is fine if it means the quest for knowledge remains an ongoing pursuit with the view of mastering the rules established and then breaking new ground with new thinking and new perspectives.

Make allowances to learn anew

The constant quest for knowledge also limits the occurrences of negligence borne of not acquiring and using knowledge that is already available and the possible crime of ineptitude where wilfulness or hubris has made one almost too sure of a situation when it really is not the case.

Curiosity and a sense of precociousness are attributes one must always possess along with a questioning and challenging disposition. We can trust many things, but they should really only be trusted that much if they have also been verified as trustworthy – paraphrasing Ronald Reagan aphorism of “Trust, but verify.”

The inspiration for this blog came from Dr Atul Gawande’s first Reith Lecture in 2014 on The Future of Medicine, titled, Why Do Doctors Fail? [PDF Transcript]. In this lecture, he referenced an article Toward a Theory of Medical Fallibility [Subscription PDF], Samuel Gorovitz & Alasdair MacIntyre (1976) Published in The Journal of Medicine and Philosophy, 1976, Vol 1, No 1.

Technical tinkerers are the worst

Taking calls for old jobs

Late last week, having left a project in which my contribution was critical, I got a call from the project manager about some issues that they had encountered and were having problems resolving.

I agreed to take calls from the technical people and see what I could do to help. When the call finally came through and I was told what they had encountered my intuition and experience just felt it was a non-problem that had been complicated by unnecessary tinkering on the one end and a basic inability to understand abstraction with technologies.

A template is a template is a template

The environment we built provides for the ability to document the settings on one environment using a portable format and wizard assisted method in an export process and the using the same wizard to import the settings into another environment.

This follows a basic template format which allows for common elements to be transferred but requires that some unique elements be edited to reflect the new environment. All those elements had been documented.

One of those elements deals with recording the status of the environment, but the references are not updated and hence technicians cannot check the state of the environment for operational effectiveness – the simple solution is to delete the foreign references and select the local references.

Tinkerers are the worst technical people

Now, I know technicians like to see what goes on under the bonnet; I have no problems with that. I like to know how a television works because I studied electronic engineering but I don’t at a whim go poking a screw-driver in the back of my television just because it is fun, I could be electrocuted, quite easily, even if I knew exactly what I was doing.

I sometimes give deference to the simple notice – No user serviceable parts – I wonder if that appears on modern equipment nowadays, I suppose the warning is more the risk of losing your warranty if you try to tinker with the innards of your equipment.

After the conversation ended, I just knew the smart guy had tinkered with the template directly and wrecked the environment and was now looking for assurances that if he continued that dastardly act the functionality of the environment could be guaranteed.

The absence of logic and reason

Since I was away from home, I could not simulate the conditions he was describing, in fact, I should have asked at the beginning what symptoms had been presented to them before the tinkering started.

The problem with many technicians and engineers today is that they lack analytical skills, they’ll rather tinker and test unsound assumptions with trial and error – they might eventually solve the problem but you can never get them to walk you through the problem discovery to problem resolution because the critical ingredient for analysis is logic and reasoning and that is usually missing.

I fear something in the educational system has deprived many technical personnel of the ability to just stand back, review the situation, work out scenarios, dry run possible resolutions and test assumptions against sound logic. They can see what but never seem to know how or why.

They have to be seen doing something and thinking is not part of doing something, it is scary, I can assure you it is – because what ends up happening is every single issue requires a complete rebuild once they hit a bottleneck - that is time and money.

Doing it right the first time

From my wealth of experience, I have rarely had to rebuild anything I have built myself because of the time taken to understand what I am doing in the first place. However, in many cases I have had to rebuild what others have done because it becomes evident that certain omissions in the construction process are critical to the operation or performance of that environment and that omission cannot be corrected in live systems.

I am sometimes left completely exasperated by the lack of meticulous application of technical expertise in some of these places, I take my time because my philosophy is what is worth doing at all is worth doing well - the first time.

Yes, he did

Anyway, I was called by the project manager again today to arrange another meeting with the technical people and somehow they had tried to call me a couple of times during the day, well, the reason why I had not gotten the call was because the tinkerer had transcribed my number wrongly.

So, we chatted and I had to get the first bit of information out of him, indeed, he had edited the template directly – I simply said, I cannot believe that you edited the XML file, anyone should know that an automatically generated file is not there for tinkering.

Basically, even if you can identify the elements that need changing, there is no telling what other related elements are linked by coded or encrypted values, but in true cowboy fashion, he had edited the file and corrupted the environment.

Now, there is no way how I could then engage in a conversation with this tinkerer on the level of an experienced and learned technician with the expertise to distinguish himself properly.

And indeed, the conversation did get to a point where he remonstrated that he had not just started working with these environments and I was getting irritated with what was turning out to be an abject waste of my time.

The impossible question

By the time we got to the end of the conversation, he wanted to know if he could trust the environment he had built, well, I trust the environment I built, I trust the use of templates to transfer settings and I trust my ability to leave black boxes alone if I decide to use wizards to perform otherwise time-consuming activities.

I could not vouch for his skills or expertise and in the end, he decided I was not helpful at all, I am glad it ended that way because I would be an idiot to vouch for the kind of stuff he had been doing.

I called the project manager and gave him a piece of my mind asking that next time I would rather converse with others with constrained cowboy tendencies whilst intimating him of the fact that my time had really been wasted almost unforgivably.

Some so-called administrators should never be let near critical infrastructure for the sanity of the bigger world.