As someone that writes code on a regular basis, you must view a lot (if not all) of your work as problem-solving. After all, that’s often what you’re hired for. Someone has a problem and you solve it using the code that you write. It’s like having a superpower. It’s great! (Who wouldn’t want a superpower!?)
You start doing the same with your own problems. You break them down into smaller micro-problems. You then try to find solutions to them.
Explained like this, you’d think that this a great strategy. And you’d be right! But where you have to be careful is how it affects your mindset. You start focusing on only searching for solutions to these micro-problems.
That’s why so many coding questions follow the formula “How do I do X with Y?” You want a solution to your problem so you can move on to the next one. You continue this pattern of searching, finding and copying solutions until you’re done.
This puts a lot of pressure on the online learning material as well. They need to answer these questions to stay relevant. That’s why you can boil down so many tutorials to “How to do X with Y”
That’s why this relentless focus on problem-solving can come at a cost (after all no superpower comes for free). You become so addicted to finding solutions that you’re not writing code anymore. You’re just integrating (or duck taping) these solutions that you found online together.
But there’s a creative aspect to coding. You’re not just an integrator, a problem solver. You’re also a writer, a painter, an architect. It’s important to never forget that when teaching programming.