The abstract descriptions are sometimes leaky. Recently I had a short training on “how to solve problems”, which assumed discrete steps, something like “define the problem”, “collect facts”, “find out causes”, “propose a fix”.
Some people seem impressed by seeing four or five bullet points that in theory would allow them to solve any problem, if they only apply them in the right sequence. To me, it seems like the real world does not follow this “waterfall” model.
For example, collecting the facts. Which facts? About what? How much certainty do you need for those facts? If you really tried to collect all facts about a nontrivial system, it would take much more time than you usually have. So you go with some assumptions, like “these are the things that usually break, let’s check them first” and “these are the things that are cheap to check, so let’s check those, too”. And you solve half of the problems like this, quickly. For the other half, you take a step back, check a few more things, etc. And when the things really get complicated, then you start going step by step, verifying one step at a time. But it would be a mistake to say that you wasted your time by trying to solve the problem before you had all the facts. You did something that works well on average, it’s just that problem we had today was an outlier.
(I am not saying that this is completely useless. Sometimes people make the mistake of going in circles without taking a step back and checking their premises, so it is good to remind them to collect more data. But you need to be adaptive about that, which is something that in my case the high-level description abstracted away.)
The abstract descriptions are sometimes leaky. Recently I had a short training on “how to solve problems”, which assumed discrete steps, something like “define the problem”, “collect facts”, “find out causes”, “propose a fix”.
Some people seem impressed by seeing four or five bullet points that in theory would allow them to solve any problem, if they only apply them in the right sequence. To me, it seems like the real world does not follow this “waterfall” model.
For example, collecting the facts. Which facts? About what? How much certainty do you need for those facts? If you really tried to collect all facts about a nontrivial system, it would take much more time than you usually have. So you go with some assumptions, like “these are the things that usually break, let’s check them first” and “these are the things that are cheap to check, so let’s check those, too”. And you solve half of the problems like this, quickly. For the other half, you take a step back, check a few more things, etc. And when the things really get complicated, then you start going step by step, verifying one step at a time. But it would be a mistake to say that you wasted your time by trying to solve the problem before you had all the facts. You did something that works well on average, it’s just that problem we had today was an outlier.
(I am not saying that this is completely useless. Sometimes people make the mistake of going in circles without taking a step back and checking their premises, so it is good to remind them to collect more data. But you need to be adaptive about that, which is something that in my case the high-level description abstracted away.)