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.
