Saturday, 8.37pm
Sheffield, U.K.
But if thought corrupts language, language can also corrupt thought. – George Orwell, 1984
When it comes to dealing with the complexity of the world around us, thinking in terms of machines and computers seems to provide some useful approaches worth considering.
Philosophers have wrestled with questions of matter and mind for millennia.
Is matter something that exists out there independent of all thought?
Light and trees and animals and movement?
Or, since everything we perceive is actually reconstructed inside the dark chamber that houses our brains, does everything really exist only in our minds?
Such questions are perhaps best left to the philosophers.
From a practical view whether a tree exists in the material world or exists only in our minds is less important than what we spend our time doing in the world we inhabit.
Most of our existence is a search for control of the world around us.
So, we build houses, create factories and form societies.
But we don’t always think about or recognise the different kinds of thinking that go into doing those things.
So, if we think of ourselves as machines – maybe as computers – what kind of programming are we following and are there ways in which we could do things better?
Let’s start with the physical transformation of the world around us.
That comes down to having tools – tools that help us change material from one state to another.
That seems a pretty obvious first step for the species and it’s something that we’re pretty good at now.
The next step is about putting different physical tranformations in a process – arranging them so that they result in something bigger than the individual things themselves.
The classic example here is a car factory – whether the gigantic integrated facility designed by Ford which ushered in the age of mass production or the lean facilities pioneered by Toyota that run to a heartbeat set by customer demand.
The task here is of saying what must be done to change from one state to another – something that is called imperative programming.
Imperative programs tell you how to do something – what the steps are that you need to follow in order to make something happen.
If you have a morning routine or insist that your staff complete their tasks in a particular way you are doing imperative programming.
Most things work just fine if you approach them with an imperative programming mindset – knowing how to do things is important most of the time.
As you go from problems of matter to problems of mind, however, there comes a point where it stops being enough.
And this usually happens when what needs to be done is not clear and the people involved look at things in different ways and have different thoughts.
This is called a pluralist situation – and things start to get fuzzy and messy and a little complicated.
Maybe even complex.
At this point what you need to do is shift from thinking about how something should be done to what needs to happen.
In programming terms the easiest one to appreciate these days is css – the cascading style sheets that govern how a web page looks.
css is a programming language – one in which you set out how you want things on your page to look and then it all happens at once – your page goes from simple html to being displayed in whatever style you wanted.
In other words you describe what you want and the programming language takes care of the details.
This kind of programming is called declarative programming and it’s closer to the idea of a mental model than a process model – what rather than how.
So, why might this be useful?
The U.S military, for example, does declarative mission planning – it sets out what needs to happen and lets its units work out how to make things happen.
That’s the essence of business and life strategy as well – without having a clear model of what needs to happen there is no point in spending time working on the how because the chances are you won’t make the right things happen.
The problem in the modern world is that there is lots of knowledge on how to do things and much less insight into what needs to be done.
A programmer or programming shop, for example, can build you anything you want as long as you can tell them exactly what you want.
Most of the time clients don’t know.
And that’s the secret – nobody really knows – bosses don’t, managers don’t and workers don’t.
And that’s because they have been trained for years to program their lives and business using imperative programming techniques but never been exposed to declarative ones.
Even the whole neuro-linguistic programming stuff seems to be (on a cursory reading) imperative programming.
Of course there are lots of discussions in the programming world about the precise definitions of these terms and which languages you should use.
For the purposes of my argument here you can ignore all that.
The point I’m making is that you should consider thinking about what you do before working out how to do it.
That’s pretty obvious really.
But what’s not obvious is how to go about doing that – how to think about the what that’s in your mind.
Perhaps you will notice the slight irony in using an imperative approach to illuminate a declarative activity.
A paper that might help you get started if this is of interest is Thoughts on learning and taking action which is about how to construct declarative mental models.
And if you’re too busy to read the paper the answer to why you might do this is to get peace of mind.
Because that is all that matters.
Cheers, Karthik Suresh
Handcrafted insight 