Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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: