Code. Build something. Figure out something you'd like to build, then figure out out to build it. You can't help but learn if you take that route. If that's not your cup of tea, then start contributing to open source projects. Learn Git and Subversion, then start taking tickets for Firefox or Chrome. Start off with the easy things, then work your way up. There's lots out there that needs attention, and being able to…
I think the most significant thing to learn at the OP's stage is dealing with bigger codebases. Anyone can program something in 1000 LOC. 10000 is already harder, but I think there is a guenuine difference when it goes to the next level, because at that point, you cannot do everything, and you are forced to spend more time reading than writing. Contributing to open source projects is the obvious thing to do there. Tr…
10 = Sam's Learn Java in 24 hours
100 = did some programming courses at highschool / university
1000 = baseline professional programmer. Has already understood the basics of writing reasonable code at the function level
10000 = experienced programmer - will stand out in a corporate environment, probably the minimum that you want working on a startup. Understands architectural issues and mastering the environment outside the application
100000 = star programmer. That said, I don't see a big difference between the last two categories in terms of pure programming skills. The difference is more in that the 100000 LOC programmer is capable of directing a team, explaining the system architecture to others, making the code more modularisable and accessible to others (doing the necessary makefile magic so that code will compile as C or C++ for example, or providing a plugin architecture, or adding bindings for a scripting language etc)
To go back to the original question, if you find that you are limited to 1000 LOC programs, looking at the list, you need to look a bit more at architectural issues - encapsulation, OO, functional style programming, that sort of stuff, to get you to a level where your code won't descend into an unholy mess when it starts getting bigger.
I actually use the size of codebases written entirely by the candidate as an indicator in job interviews - it gives a good feeling of where the person is at.