For actual programming mindset, I think this a learnable skill that I'd love to see a good article on. I see a lot of intermediate programmers try to "abstract"

For actual programming mindset, I think this a learnable skill that I'd love to see a good article on. I see a lot of intermediate programmers try to "abstract" by kitchen-sinking things, such that they end up with a perfect machine that is fairly inscrutable. And then when a change is needed, the machine falls apart and needs to be rewritten entirely. I think abstraction is about recognizing patterns, but also about recognizing what elements are more likely to change - you don't want to abstract away the changing aspects. In that sense, it becomes similar to creating a model that depends on parameters. Also, generally, when you are implementing a solution, that solution exists within a context of a problem. If we are simply told to implement a solution, there is a temptation to just trust that the solution will solve the problem - and sometimes we are told to trust that. But if we take a step back in abstraction and fully understand the problem ourselves, we can derive our way to the correct solution, freeing us from having to "trust" that the solution is correct. Abstraction is just continuing from there. Understand the larger context of the problem, why it is a problem. Maybe you'll discover it isn't, and that the solution isn't actually needed. And so on, if you ask another Why you can discover that maybe another problem is more important to solve, which would make this problem irrelevant.