Don't start by trying to solve a problem. That way lies madness.
(The problem is that your mind, your approach, needs to change, and that change comes with practice and time. And practice always starts with the simple, the controlled, the repeatable, not the full fury of all skills brought together in a high pressure win-or-lose moment.)
Computers are nothing more than repetition machines. Start by writing code to do things that you yourself now do multiple times per unit time.
Start small. Simple things. Let the computer handle the repetition for you, no matter how simplistic and rude and hacky your solution.
Then notice how program A and program B, written to repeat different procedures, have similar processes or structures.
Generalize A and B to make a C that does both.
Do this again for other processes. Over time, your approach will shift. You will notice patterns: Patterns of process, patterns of structure, patterns of relation.
Then you will start solving problems. Only afterwards will you realize you have done so.
(I started coding shell scripts for anything I had to do more than twice - or anything that required "too many characters". I got tired of typing "ls -alt *|head" so I wrote nwst to do it for me. Then I added a numeric option to nwst to control how much head wrote. I got tired of writing "find . -iname" so I wrote fndi. Etc. Etc.)
I don't know why this got downvoted, it is very intelligent and I completely agree. Especially for kids, the most effective way to learn coding is to have complete visibility over all the underlying components.
True. But my read of the OP is that they learned for the pleasure and interest of it. They want to "solve problems" for the intellectual satisfaction and joy of doing so, not because someone is paying them or anticipating doing so.
We have to master the skills before we get rewarded for them.
Thank you very, very much for your main comment. I am actually a member of both academia and the realm of "regular people/programmers/hackers/whatever." I'm a college student, so a lot of my work is for the most part free (despite what most people think about academia). However, I also want to do programming for a living, and know I will have to conform eventually.
That said, you're absolutely right in saying that I want to "solve problems" (that's just the best term I could come up with after months of trying to convey my meaning to many people--I have no attachment to it) for the intellectual satisfaction and joy of doing so. I really just love what I have done with writing code. It's really fulfilling and the structure of it resonates with me at a deep level.
So, your comment is very helpful. There's no end to the small problems or ideas that I have, especially within my work writing code. You may have answered this and I didn't understand, but the main thing I'm getting at with my OP is that I don't have the skill set to actually solve the problems. I know it probably sounds completely ridiculous, but I've approached many small problems and have always produced the absolute barest skeleton of the program which solves the problem I have. I then draw a blank on what I need to do next to continue solving the problem--the structure and the logic don't exist in my brain yet. That's what I really want to get from this thread, and I think there are some excellent responses that help with that, including yours.
I don't know your career ambitions and goals, but there is a lot to be said for the technician/mechanic/custodian (not really sure of the best word) who solves one problem and moves on.
If you are at all inclined to system administration, your approach (notice problem, solve problem quickly and effectively, move on to next problem) can translate to solid work.
Now I speculate: As an employee, this will probably lead to low to medium pay positions - at least until you start seeing and solving larger scale problems. As a consultant, however, if you can get a stable of repeat clients, preferably under retainer, you may actually do quite well.
Back to reality. How to make progress? Find an OSS project or two that you quite like, preferably ones with really good communities. Go through the lists of current bugs. Find and fix those you can.
Heck, just start finding flaws in people's code and documentation on GitHub, fix, and issue pull requests.
You will get a reputation in the community as a reliable, dependable problem solver. After a while, reach out to people who seem both approachable and a step or two above you. Ask if you might be able to help them with a larger problem, one which they need assistance with and on which they would be willing to mentor you.
That's one approach, at least.
Your academic environment may also have code that needs maintaining, patching, repairing, refactoring. Food for thought.
Keep at it, the penny will drop, things will click into place.
(The problem is that your mind, your approach, needs to change, and that change comes with practice and time. And practice always starts with the simple, the controlled, the repeatable, not the full fury of all skills brought together in a high pressure win-or-lose moment.)
Computers are nothing more than repetition machines. Start by writing code to do things that you yourself now do multiple times per unit time.
Start small. Simple things. Let the computer handle the repetition for you, no matter how simplistic and rude and hacky your solution.
Then notice how program A and program B, written to repeat different procedures, have similar processes or structures.
Generalize A and B to make a C that does both.
Do this again for other processes. Over time, your approach will shift. You will notice patterns: Patterns of process, patterns of structure, patterns of relation.
Then you will start solving problems. Only afterwards will you realize you have done so.
(I started coding shell scripts for anything I had to do more than twice - or anything that required "too many characters". I got tired of typing "ls -alt *|head" so I wrote nwst to do it for me. Then I added a numeric option to nwst to control how much head wrote. I got tired of writing "find . -iname" so I wrote fndi. Etc. Etc.)