How do I get better at problem-solving in programming?

You've identified the single biggest gap in most self-taught programmers: 'tutorial knowledge' (following someone else's solution) is completely different from 'problem-solving ability' (creating your own), and the freeze at the blank editor is the symptom. The good news — problem-solving is a trainable skill with a concrete method, not a talent you either have or don't. Here's how to build it: The core method — decomposition (this is THE skill): the reason you freeze is you're trying to solve the whole problem at once, which is overwhelming. Expert programmers don't do this; they break big problems into tiny, solvable pieces. Practice this explicitly: 1. Before writing any code, restate the problem in your own words. If you can't explain what you're solving, you can't solve it. Half of freezing is not actually understanding the problem. 2. Write the steps in plain English/pseudocode FIRST. 'Get the input, loop through each item, check if it matches, collect the matches, return them.' No syntax — just logic. This separates 'what do I need to do' (thinking) from 'how do I write it' (syntax), so you're not fighting both at once. Most beginners skip this and try to think in code, which is why they freeze. 3. Solve ONE piece at a time. Get the input working. Then just the loop. Then the check. Build up in tiny verified steps rather than writing everything and hoping. Small wins compound and the blank-editor terror disappears when you're only ever solving one small thing. How to actually train it (deliberate practice): 1. Solve problems WITHOUT looking at solutions first. This is uncomfortable and slow and it's exactly where the learning happens — the struggle IS the skill-building. Give every problem a real attempt (20-30 min) before looking anything up. Tutorial-following builds recognition; solo struggling builds ability. 2. When stuck, look up CONCEPTS, not the answer. Google 'how to loop through a dictionary' (a tool), not 'solution to [exact problem]' (the answer). You want to assemble the solution yourself from pieces. 3. After solving, study better solutions and REDO it later. A problem isn't learned when it works once — it's learned when you can solve it again cold a week later. Redoing is where patterns get internalized. 4. Start absurdly small. Don't jump to hard problems. Tiny ones (reverse a string, find the largest number, count vowels) build the decomposition muscle without overwhelming you. Volume of small solved problems > a few hard ones you looked up. The mindset shifts that matter: - Being stuck is normal and productive, not a sign you're bad. Every programmer, including seniors, spends much of their time stuck — the difference is they're comfortable there and have a process for it. Reframe 'stuck' as 'currently doing the actual work.' - Debug systematically instead of randomly changing things: read the error, form a hypothesis about the cause, test it, repeat. Random flailing is a sign of not having a process; systematic narrowing is the skill. - Build your OWN projects, not just tutorials. Nothing forces problem-solving like a project with no tutorial to follow — you HAVE to figure it out, which is precisely the muscle you're missing. Even a small original project teaches more problem-solving than ten tutorials. The uncomfortable truth: you get better at problem-solving by solving problems while stuck, not by watching solutions. Every tutorial you follow builds almost zero problem-solving ability; every problem you wrestle to the ground yourself builds a lot. Shift your ratio from consuming to struggling, embrace the discomfort of the blank editor as the actual gym, and it will steadily stop being scary. The freeze isn't a permanent trait — it's just an undertrained skill, and it trains up faster than you'd expect once you practice decomposition deliberately.