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 think

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