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.