I heard a saying once: "all developers should be embarrassed about code they wrote more than a year ago" as a (cheeky) measure of ongoing growth and development. :-)
Interestingly, I recently looked back at an old disk drive with my first "real" unfinished side-project which I started as a teen learning to code.
And, to my surprise, it was not _that_ bad.
Sure, it was full of naively implemented stuff that could have been implemented way better. But, even a decade and a half after, it was pretty clear to read, and it was decently organized.
And, in some ways, I preferred this code to the one I'm writing professionally. I was honestly prouder of myself as a teen than myself as a professional programmer.
The difference, I think, is that I had a clear idea of what I wanted to achieve for this project to be considered as definitely finished. Since I started working on code (for money) I've always been working on never ending projects. This industry (and me, as a professional) is obsessed in writing code for long term maintenance and evolution instead of effectively finishing products.
So, to get back on topic, I'm not sure you really write better code with time. I mean, yes, you totally do, but it's not as important as learning how to code for others to be able to understand and modify it with constraints you can't even imagine.
And I saw a lot of people writing super nice open source side project and then, when you work with them on some professional level, well, they still write the same shitty code as everyone else.
I think you progress mainly by learning the type of code not to write. There is a large permutation of valid program terms that can achieve your desired result, and it takes time to know what sorts of permutations are unnatural or express "awkward" programs with undesirable properties.
Like when you learn a natural language's vocabulary, but you still need to figure what conjunctions of words are not intelligible or natural phrases to fluent speakers. Phrases that have ambiguous meanings or otherwise generate confusion.
I think there's a comparable notion of fluency in programming that goes what most people mean they say they're fluent in a programming language.
The code you wrote a year ago should have good points and bad. If it is just bad, then you either started programming a year ago, or should perhaps start thinking about changing jobs.
If you are actually improving then there should be some good in there (you got better from two years ago right?). If you can't identify that good, then either you are just chasing fashion (that perfectly good construct from two years ago is now out of fashion so it is "bad"), or you haven't improved your ability to tell good code from bad and just calling it bad because you are unfamiliar with it.
If you want to actually get better at code then you should do a real review of the code you wrote a year ago. Where did bugs occur in the code you wrote? Is there something that you could have done to make it less error prone? Is there code you wrote that is easy to understand? What design choices can you make so that more code ends up in the good code camp? How were the bugs detected? Can I integrate that in to what I do for testing? Then actively practice moving your code in the good direction and away from the bad.
Anything less is chasing fashion and using familiarity as a good and unfamiliarity as bad. "As is" it is a pithy blog post for Coding Horror, but won't get you there. Pursuing greatness requires directed improvement
Pretty funny, about 15 years ago I started looking back at myself a year ago and decided that until that dude from a year ago looks like an idiot then all is well with my life. Hasn't failed yet.
I honestly find that kindof frustrating. I look at code I wrote a year ago and think - why didn't I do it this (better) way. And I also think - haven't I learned to write decent code by now? Why do I keep writing code like that when I should know how to write it better.
I don't mean this sarcastically, you're probably an better coder than this comment implies, but what you described is the mind's mental content that should motivate you to write "decent" code.
Do you only feel this motivation when you look back at old projects? Perhaps the improvement could be in organization (code-level or otherwise) such that you do not feel lost or confused looking at your old stuff.
I've read that and think the saying is fundamentally wrong. If you're constantly embarrassed at code that is only a year old, I think it's much more likely that you are chasing fads rather than actually improving your code quality.
I would go as far as to say that it's a negative signal, because instead of improving code quality you are just changing things that don't really matter.
I've seriously considered removing some of the older semi-popular projects from my github solely because I would be embarrassed to show them to a prospective employer, or even other developers.
In the end I think it's actually kind of fun to look back through the code though, and think "surely I should have known about X back then... Why didn't I just do that instead."
As someone who looks at GitHub accounts as a resume, I can tell you that improvement over time is amazing to see. Assuming it’s clear what’s most interesting or recent.
