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. Try to pick up a project which reacts relatively quickly to patches and which of course is of some interest to you :)

I'm glad to see that I'm not the only person that uses the x10 LOC as a way of judging a programmer's skills. I generally think of it like this:

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.

I don't know about saying 1000 LOC is a baseline for a junior developer. I did second year software engineering last semester and our final project was about 1000 LOC. Granted, that was C, which tends to be... verbose. Even our python implementation of something similar averaged 450. Point is, I don't think 90% of the people in that class, myself included, could start as a junior developer today and be expected to succeed.

It's not clear in my original post, but I was talking explicitly about what a programmer can achieve by themself, without any aid from peers/mentors. I don't think your example contradicts that. How many of your classmates actually did the project by themself, without getting aid from tutors/lecturers, discussing ideas with classmates, etc? And even if they did, the problem still isn't directly comparable, because you've presumably been discussing the ideas that you are using in your projects during the course. The ideas are fresh in people's heads. This is not true in the real world, where you can be assigned to working on a project that uses skills that you haven't touched for years.

Anyhow, our discussion is a little theoretical. In practice, I can say that what I described is really truly what you find when you work in a large corporation writing code. I know it's hard to believe, but have a look around at the horror recruiting stories on this site, or stories talking about how enterprises do software development. It's not a pretty picture. It's not just that your baseline programmer can only write a project of about 1000 LOC, but also that there are a significant number of "developers" that can't even do that. Hard to believe, until you've seen it for yourself, but true nonetheless.

I'd like to add a quirk to that requirement. You have to be able to build something large and ship it (and maintain it). Anybody can continue to build and build and build and you end up with a really large codebase that's bloated/duplicated/buggy and that never work in production.

Building something doesn't teach you much about quality if you don't have someone to review/assist every now and then.

I'd say, having never really thought about it, you learn quality by coding the same thing repeatedly and optimizing it each time. So you can learn in that way.

And having a friendly reviewer is excellent!

Where to find friends who can review my code? All of my friends don't know anything about programming or they don't code in there spare times like I do.

It is really hard to find someone who can explain what is bad about code design and what should I do about it or what should be "best".

That is when joining a OS project makes same. Then you will have a whole mailing list reviewing your patches, and discussing all kind of architecture decisions.

Or it teaches you more about quality because you own the product, set the schedule, and build exactly what you want.

It is possible to build an app that does exactly what you want and is completely unmaintainable in the future. If you don't know anything about code quality, it is rather hard to pick up on your own. It helps if you have someone more experienced to look at your code and go "No, you're doing it wrong. You don't need to subclass for x, just use y instead."