How often do you check to see if you're getting better at coding?
stochasticgeometry.ie
stochasticgeometry.ie
More importantly, it also reinforces a mantra that you only need to build things that are "good enough" for your use case.
That's why I no longer subscribe to that mantra.
Also, there's the possibility that the horrid mess of buggy legacy code (been there, I feel your pain) wasn't someone's idea of "good enough" in a technical sense but rather "good enough so that my boss doesn't notice." I've had the displeasure of working with those individuals before. They don't care about getting better at coding—they care about flying under the radar and collecting their biweekly paycheck.
As for finding bad code, I wrote something today I was not proud of (doing it right would be a large rewrite of a common component... too big a job for today) and knew if I look back on it in the future I would be embarrassed about it, so I wrote myself an apology in the comments.
I wish there were more people in my office who thought like you and I.
Does anyone have a more concrete approach to metrics of improvement? Or a better way to articulate this concept?
Even over the course of 12 months I can see improvements in my approaches problem solving, code structure, and where I got lazy, haha.