improper fixup

The important thing here is to consider Occam's razor.

There are billions of potential problems/details/tracks in existence all around us. We wouldn't get anywhere by picking them at random.

It's way faster to try to cover the most likely sources of a problem first and only branch when there is a significant reason to. Being selective about what alternatives to try first is not the same as ignoring the existence of alternatives, but a required optimization step in real life.

We regularly discuss on this forum the importance of details. But real world problems don't have one detail to be careful about. It may have 100 or 10000 details. Some details more important than others. Some details impossible to handle because they are not compatible with something else. When going on vacation, there is much gear that would be good to bring. But the car has limited space. When doing embedded work, there is much cool things to implement, but a processor have limited code/ram space and may have a tight power budget.

Same thing when trying to solve problems. We don't have the mental computing power or bandwidth to hunt all potential alternatives concurrently. It's meaningless to stand 2 cm from the wall and discuss the structure of the wall paper when a viewer standing 2 meters from the wall would notice that the wall paper is hanging upside down.

Too early zooming down too deeply when problem solving is similar to prematurely starting to optimize source code. The end result will be suboptimial, or there will have been significant extra work without any gain.

The important thing here is to consider Occam's razor.

There are billions of potential problems/details/tracks in existence all around us. We wouldn't get anywhere by picking them at random.

It's way faster to try to cover the most likely sources of a problem first and only branch when there is a significant reason to. Being selective about what alternatives to try first is not the same as ignoring the existence of alternatives, but a required optimization step in real life.

We regularly discuss on this forum the importance of details. But real world problems don't have one detail to be careful about. It may have 100 or 10000 details. Some details more important than others. Some details impossible to handle because they are not compatible with something else. When going on vacation, there is much gear that would be good to bring. But the car has limited space. When doing embedded work, there is much cool things to implement, but a processor have limited code/ram space and may have a tight power budget.

Same thing when trying to solve problems. We don't have the mental computing power or bandwidth to hunt all potential alternatives concurrently. It's meaningless to stand 2 cm from the wall and discuss the structure of the wall paper when a viewer standing 2 meters from the wall would notice that the wall paper is hanging upside down.

Too early zooming down too deeply when problem solving is similar to prematurely starting to optimize source code. The end result will be suboptimial, or there will have been significant extra work without any gain.