My answer is going to be very book-centric. Some people don't take well to reading about this sort of thing, and do better in practical situations with other people. I don't have much of value to offer there other than consider tertiary education.
Anyway, the short answer: pick a reasonably popular language that supports basic OO design (C++, Java, Python, C#, etc) and start working through some basic online tutorials.
I know next to nothing about it, but don't some universities offer free online courses nowadays? I can't vouch for their value, but look into it. I've heard good things about "
Dive Into Python" (available for free online).
Pick your poison, basically.
It's hard to understand early on, but the language you're using is secondary to actually thinking algorithmically or architecturally. Books like "
The Mythical Man Month" and "
Peopleware" are (still!) invaluable. After you've spent some time working on some projects, books like "
Design Patterns" and "
Refactoring" --- when read as guidelines rather than gospel --- help you
think about your design.
Failing all this, find a friend and work through some problems together. It sounds obvious, even with a team of two, you'll start to butt up against some of the interesting problems working with other people ensue.
Once you have a solid understanding of a language, come back to this and follow up with some of the books mentioned here, or feel free to ask more questions. There's so many employer-specific intricacies when it comes to work environment, configuration/issue management, team process and so on that it's impossible to point to something and say "this is where you should start"*. Again, these books are useful, but the thing that makes you most attractive to employers will always be demonstrable experience. Well, that's broad. Evidence of constant, genuine critical thinking is probably the thing I'm most excited by, but if you have a good way of gauging that on a resume/interview, I'd love to hear it.
*: I can point you toward the wikipedia pages for, say,
the waterfall model (which, warts and all, at least gives you a decent overview of the broad steps most project faces at one time or another) or
an agile methodology, but don't get too hung up on them to start with. If you're interested, feel free to ask or have a look around yourself.