Trying things that might work is a reasonable strategy in many situations. Not every problem merits contemplation. Eg you're in a new language and you need the sum of the numbers, I'd advocate you just try typing num1 + num2, b/c lets be honest, it's probably that. Maybe you gotta guess at how to tweak it for some new language (+ num1 num2), but same thing. Predicting and verifying are more effective than many docs and blogs. But yeah, there are times when it's better to understand how things work: if you guess wrong several times in a row, or if you can't find a way to cheaply try out the possibilities, or if you get it right, but don't understand why.
Also, it's a mistake to require understanding before beginning. In part, it means you can never do something unless you understand it. Many problems do not have this attribute. Eg "what should the product be?" For many domains, you cannot know the answer until you start working on the problem (or you hit "analysis paralysis"), the feedback cycle is incredibly important.
Also, the described approach requires you to invest in understanding and then planning before you begin. But not all things are worth investing in. It's hugely advantageous to be able to start something you don't understand, to drive in a direction that you know is progress, even if you can't see how it gets you to the solution that you aren't sure what it is. Not saying you should do that for every problem, just that it's the right approach to many types of problems.
Number 3 is legit. Breaking a problem out of its complex context and solving it in isolation is the best way to understand, usually the path of least resistance (though figuring out how to break it out can be difficult, depending on the domain), and it's the quickest way to get feedback on an idea.
Another useful thing to do when stuck is to confirm your premises. Eg if the thing isn't making sense, maybe it's because your understanding is wrong, so you need to question and verify those things.
And another useful thing to do when you get stuck is to approach the problem from the opposite end. Eg if you're building up from the bottom (composing new functionality out of existing functionality), then try switching to the top (writing what you ultimately want, even though the things you're using don't exist yet), and vice versa. Sometimes you have to switch back and forth multiple times before you finally see how / where they connect.
Another good way to practice is to re-solve problems you previously solved. It probably takes me three to 5 times, re-solving a really difficult problem, before I feel like I've gotten 80% of the insights it had to offer. What's especially nice about this is that it gets easier with each iteration. So the cost of re-solving goes down, but the value stays high for quite a while.
Anyway, nice post. Despite being numbered, the list is best traversed nonlinearly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Trying things that might work is a reasonable strategy in many situations. Not every problem merits contemplation. Eg you're in a new language and you need the sum of the numbers, I'd advocate you just try typing
num1 + num2, b/c lets be honest, it's probably that. Maybe you gotta guess at how to tweak it for some new language(+ num1 num2), but same thing. Predicting and verifying are more effective than many docs and blogs. But yeah, there are times when it's better to understand how things work: if you guess wrong several times in a row, or if you can't find a way to cheaply try out the possibilities, or if you get it right, but don't understand why.Also, it's a mistake to require understanding before beginning. In part, it means you can never do something unless you understand it. Many problems do not have this attribute. Eg "what should the product be?" For many domains, you cannot know the answer until you start working on the problem (or you hit "analysis paralysis"), the feedback cycle is incredibly important.
Also, the described approach requires you to invest in understanding and then planning before you begin. But not all things are worth investing in. It's hugely advantageous to be able to start something you don't understand, to drive in a direction that you know is progress, even if you can't see how it gets you to the solution that you aren't sure what it is. Not saying you should do that for every problem, just that it's the right approach to many types of problems.
Number 3 is legit. Breaking a problem out of its complex context and solving it in isolation is the best way to understand, usually the path of least resistance (though figuring out how to break it out can be difficult, depending on the domain), and it's the quickest way to get feedback on an idea.
Another useful thing to do when stuck is to confirm your premises. Eg if the thing isn't making sense, maybe it's because your understanding is wrong, so you need to question and verify those things.
And another useful thing to do when you get stuck is to approach the problem from the opposite end. Eg if you're building up from the bottom (composing new functionality out of existing functionality), then try switching to the top (writing what you ultimately want, even though the things you're using don't exist yet), and vice versa. Sometimes you have to switch back and forth multiple times before you finally see how / where they connect.
Another good way to practice is to re-solve problems you previously solved. It probably takes me three to 5 times, re-solving a really difficult problem, before I feel like I've gotten 80% of the insights it had to offer. What's especially nice about this is that it gets easier with each iteration. So the cost of re-solving goes down, but the value stays high for quite a while.
Anyway, nice post. Despite being numbered, the list is best traversed nonlinearly.