Recently I observed that the process of arriving at a conclusion is far more important than the conclusion itself. A conclusion, when doled out, is a recommendation, a best practice and a lesson learned, perhaps after many trials. It hides, in its finality, all the errors, failures and trials experienced in the process of arriving at it. And unless someone can really look behind the conclusion and appreciate the effort involved or the problem that the conclusion offers a solution for, they might actually not appreciate the solution as well.
I am handling a training for a department at an engineering college on how to use simple automation tools and techniques to build, manage and maintain computer labs. During the course of the initial discussion regarding the training, I realised that I was offering to solve problems that they had not yet experienced first hand. I was offering solutions (and hence my conclusions) on some of the better ways of doing things because they eliminated recurring problems, made the life of system admins simpler and provided short cuts – without first having to go through an painful journey interpersed with random failures and complex challenges.
If they adopted my recommendations they might end up managing their labs better. But they might not be able to appreciate the simplicity or elegance of the solution. Or even what it represented. And hence, it is possible that the solution itself might be lost to them.
How do I make someone value the advantages of automating and scripting infrastructure setup when they don’t really see a problem doing repititive work? How do I convey the ethic of solving a problem once? 1 How do I explain how I arrived at the conclusion that a specific tool is better to use for its simplicity and effectiveness as compared to another tool? Or more basically, how do I convey my own ethic of choosing simple and little tools rather than ones that might be popular, complex or exhaustive? How does one learn to choose elegance over complexity? Is this an evolution and a lesson learned – or can it be taught? Is it a matter of taste or rational choice? How do I provide instruction on the manner in which someone else might arrive at a similar conclusion as I did given the same inputs, influences, constraints and catalysts?
So given that I am essentially pushing my conclusions on others when I impart a training, how do I make it a fair process of learning to arrive at important conclusions (and hence adopt a much more useful learning attitude) than just blindly apply and adopt conclusions made by others? Given the constraints of time (I have to attempt to teach so much in very short a time frame), opportunity (what if others don’t have the same opportunities as I do or did which will help them learn and arrive at their own conclusions) and motiviation (others might not be as interested in learning to learn, ie. arrive at the conclusion themselves, than just observe the facts and adopt them).
The last aspect – motivation – is a rather important one. Unless a person is really motivated to learn a concept well, they will only scrape the surface enough to get by. I could spend a whole lot of energy outlining a bottoms-up approach to slowly build a foundation to explain a concept and hence appreciate the end result. But unless a person finds this process interesting, it might be lost to them.
These are some open questions. I need to evolve a balance between these two extremes so that I can attempt to do justice. And so I will write more about this as I learn.
- Chapter 16, “Fixing Things Once”, The Practice of System and Network Administration, 2nd Ed ↩