I've read many times in many different places written by many different people that learning the programming trade means that when you look back at previous code you wrote, you'll wince and go 'Eeeeewwwwww!'. Well, I've read something to that effect, maybe not exactly that. Various people (like Jeff Atwood) have written on the notable differences in coding style between me-thenand me-now. Examples:

• Telling a story in the comments (i.e. over explaining) vs. to the point comments
• Coding as much as possible vs. trying to keep it to a minimum
• Using things (like patterns) for their own reason vs. using them because they work

In itself, I don't find this a very noteworthy thing. To be sure, on a personal level, it's something to marvel at: 'Look! I've evolved! I've learned! I'm not at the same level as before! I'm better now'. But I think that this particular way of looking at your progress makes sense only as anecdotes - telling the story of how you've been looking at old code and had a laughing fit. There is another, more important side to consider if you ask me:

Being able to judge code better

An unhelpful metaphor: when you start playing chess, you have no idea what you're doing. Pretty much no matter who you're playing, they'll be better than you and their moves will seem smarter in comparison to yours. As you learn to play the game and get better, you'll be able to recognize better or worse moves and strategies. You'll be able to recognize people that play better or worse than you with a bigger degree of accuracy: you'll know not just that your opponent is better but that he's only slightly better than you, not the genius you thought he was a month ago. It's the same in all areas of learning: as you get a better grasp of the subject, you get a better overall knowledge and you gain skills that are not directly related to the task at hand (in chess: winning, in development: finishing your project).

The skills connected to what you're learning can be very valuable as well, is my point. In development, being able to judge code, i.e. being able to measure what standard it lives up to, how error-prone it is, how easy it will be to maintain, etc, are incredibly useful skills when you're evaluating contributions to a project. They're also very useful skills for judging the capability of others: which is why, in an interview situation, it is pointless to ask a person that doesn't have some sort of proficiency in development to conduct the interview. It also shows a proper way of conducting interviews: based on something the person has actually done as opposed to weird questions that have no relation to the real world.

In short: make the most of experience. When you've reached that point where you can look at some code and have an idea about the standards of it, you've gained valuable insights.