For me programming (and game development) is all about solving problems. When I proceed in the project the difficult things are always also the hardest problems. Sometimes problems are algorithms like a FOV algorithm or some kind of level generation algorithm. Another type of problem is what I call logic problems. In my projects they are often in the flow of the program: something is happening in wrong time or wrong order.
An example is when you start to write some kind of walking or pathfinding routine. Here usually the game loop is static and can't be used directly in multiple step loops. You need to separate the individual routines and make them stop if some conditions are met. Most automatic routines are like that, they need extra stuff to find out things which typically are found by the player as human component of the logic chain.
I think it's important to solve these difficult problems as soon as possible, but another aspect of it is not only asking how to solve the problem but what is the problem. It's perfectly possible to create "artificial" problems by overthinking, when a simple solution is often the best one. As a micro-managing tool in programming I think it's extremely useful trying to give a clear definition to a problem and also try to find out solutions to it even before programming a single line of code.
Another example of overthinking is the quest for "perfect" routine or way to implement something. It can be fine when you are not planning to release the game any time soon, but in most cases you want to create something that roughly works and then move on to next problem as soon as possible.
One of the annoying things about problems is that sometimes they feel so difficult that you just want to go away and not even try to solve them. It's almost like problems in real life. And like there some people try to solve the problems no matter what while others just ignore them and leave unsolved for a long time, sometimes even many years.