Earlier quoted context omitted.
I would call this as The hierarchy of 'Troubleshooting Software Problems' ( as a parallel to Maslow's hierarchy of NEEDS). In order to fix a problem at certain Level, you have to go to 'Bottom Most' layer which is ROOT cause of the problem. >So you might have a data problem, a code problem, a workflow problem, a design problem, an architectural problem, a team problem, a project problem, an organizational problem, a…
I think the best way of thinking about it is to split problems up across levels. So if you have a code problem that you've worked out to be a design problem, you now have two problems. The higher level one needs to be fixed before you can fix the lower level one. So the client complains about software behavior. You now have a client problem. You isolate the issue down to a problem in the data. You fix the data but th…
well sometimes problems have workarounds, otherwise the poor 100x programmer would have to solve all existential problems first. (maybe a 1000x programmer could do that, when he finally reveals himself)