4 ms·

1. Stop "repairing" it because you're guaranteed to introduce bugs and regressions. You haven't learned it well enough and can already sense the fragility, whic

1. Stop "repairing" it because you're guaranteed to introduce bugs and regressions. You haven't learned it well enough and can already sense the fragility, which is why you're anxious. 2. Relate your impressions to the person in charge: "The code doesn't seem to follow best practice and appears fragile. You think there may be technical debt that needs to be addressed sooner than later." 3. Until you're confident enough that you can pitch a comprehensive redesign and rewrite, wait for the person in charge to direct you towards specific repairs. When they direct you towards these specific repairs, they will anticipate regressions and instability. They'll see you as working through issues, not causing them. 4. Repeat step 2 periodically and with greater detail until you're ready to make the pitch in Step 3. Don't rush it. The alternate solution: leave and let somebody else deal with the problem. Some people are comfortable working around fragile and wonky code; some people get really stressed out. You don't need to work in a job that's going to perpetually stress you out.

theossuary 8y ago
I love your answer because it calls out the perception of what you're doing. It's so important to frame what you're doing in a positive light, otherwise you'll fail, whether or not you make the codebase better.
tluyben2 8y ago
> Some people are comfortable working around fragile and wonky code Yep, because I have worked with very bad codebases over the past 25 years, I actually enjoy the challenge. For me it is more rewarding than working with pristine and well managed code bases.
- james-skemp 8y ago
  Ditto. I was explaining greenfield vs. brownfield to a co-worker (non-developer) between periods of fixing a previous, junior, developers code that was essentially creating a seemingly infinite number of pages on our site. Keeping in mind the above, I also know that deadlines, changing requirements, and lack of a clear goal (due to the previously mentioned items), lead to this. Had I not worked with them, my decade and a half of experience would have strongly suggested that such was the case. When it comes down to it, some people prefer working on new projects, and some people prefer supporting and polishing those once-new projects. But to really succeed you've got to be able to do both, to some extent.

theossuary 8y ago

I love your answer because it calls out the perception of what you're doing. It's so important to frame what you're doing in a positive light, otherwise you'll fail, whether or not you make the codebase better.

tluyben2 8y ago

> Some people are comfortable working around fragile and wonky code Yep, because I have worked with very bad codebases over the past 25 years, I actually enjoy the challenge. For me it is more rewarding than working with pristine and well managed code bases.

james-skemp 8y ago
Ditto. I was explaining greenfield vs. brownfield to a co-worker (non-developer) between periods of fixing a previous, junior, developers code that was essentially creating a seemingly infinite number of pages on our site. Keeping in mind the above, I also know that deadlines, changing requirements, and lack of a clear goal (due to the previously mentioned items), lead to this. Had I not worked with them, my decade and a half of experience would have strongly suggested that such was the case. When it comes down to it, some people prefer working on new projects, and some people prefer supporting and polishing those once-new projects. But to really succeed you've got to be able to do both, to some extent.