re: How satisfied are you with the code quality of your current project? VIEW POST

FULL DISCUSSION
 

For me, happiness with (my) code-quality on a given project is inversely-proportional to the length of a given project. The longer the project, the greater the probability that I will have learned new techniques or improved on existing techniques. Further, if a project is longer, I'm more likely to have reason to revisit earlier code — even if I'm not accorded the time to fix said code. Thus, the longer a project goes on, the more-glaring the poorer quality of the earlier code becomes.

A real exacerbator of the preceeding is that the longer a program goes on, the more the project demands, change:

  • Often, I'm the first thrown onto a given project because a project has a high (opening) urgency and I tend to be very quick to figure out how to get initial functionality worked out. On the plus side, being able to crank out functionality to meet the initial urgency is often the difference between a project receiving full-authorization rather than suffering from infant-death. On the minus side, a lot of that "quick" code is, objectively, "garbage" that needs to be refactored if not whole-sale replaced. Getting bounced from infant-saving to infant-saving project makes it often feel like the only coding I'm capable of is garbage-coding ...which is, for obvious reasons, kind of discouraging (not to mention, "how do you even put that on a résumé?").
  • Related: early project-involvement often means you're dealing with a project that doesn't have a lot of specification behind it. So, you're writing to meet a nebulous end-stand. This isn't often a recipe for terribly "solid" code.
code of conduct - report abuse