^this. "I was really really wrong when I started using blocks. I don't do this now" is something I had to say about a project that got put on hold shortly after I got to start using block based networking in Objective-C
I have only been programming for about 2 years, but already in that time I have noticed an incredible amount of changes when I look back at my old code. Some of the things that I did back then were so dumb I'm not sure how it ever worked. In general though every time I look back at my old code I realize how far I have come and it encourages me to keep pushing myself to write better code with good style. It also really is, as the article says, a humbling experience. Even though I am still relatively new to coding it shows that I still have a lot more to learn and that I wasn't quite as good as I thought I was back then.
Often I get surprised at seeing old projects (mostly websites) still live, get by and work well, but inspecting the code will show the backend is dreadful.
More importantly, it also reinforces a mantra that you only need to build things that are "good enough" for your use case.
I think it's still a valid viewpoint. "Good enough" is an opinion and just like all opinions, some are more valid than others. There's a range between "good enough" and "perfect" where plenty of very good products exist.
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.
That's true. "Good enough" can range from "it runs" to "written in a well-structured, maintainable manner". Most people choose to stop at #1, and that's fine. Until you have to fix the damn thing.
There is something reassuring about looking back and seeing how much you have improved over time. I think it is in our nature to keep optimising and trying new ideas. My coding style is constantly changing over time. I hope I never stop improving because in a way that is what drives me to keep programming.
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.
Today was the inaugural meeting of a software craftsmanship group at my company. One of our members had a strong concern about metrics for measuring improvement. My response was that "improvement" or "getting better" is too nebulous a concept, so it depends on how you measure adherence to a set of values.
Does anyone have a more concrete approach to metrics of improvement? Or a better way to articulate this concept?
It's not so easy to tell. In the early '90s I did a lot of x86 assembly. I haven't done any assembly in at least 15 years or so. Looking back I can't really tell if it's good or not. And if I tried to do any assembly at this point I'm sure it would be awful. On the flip side, back then I didn't know any javascript so I supposed I've improved 100% in that area.
15 comments
[ 4.3 ms ] story [ 45.0 ms ] threadMore 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.
Even over the course of 12 months I can see improvements in my approaches problem solving, code structure, and where I got lazy, haha.
Does anyone have a more concrete approach to metrics of improvement? Or a better way to articulate this concept?