Hacker News Reader

Comment by farseer | Hacker News Reader

If you inherit a large code base that is badly written AND you are planning to stick around in that company. I would strongly suggest to immediately start re-writing that legacy code even if you have to burn extra hours. Otherwise you would be doing nothing but firefighting in that job with limited control over your situation.

View on HN

Unless you're communicating all of this with your managers/supervisor/team, this is a fool's errand.

I would most definitely discourage this advice, in my opinion it's dangerous. Instead, I would focus on slowly and "casually" refactoring bad parts (without putting significant extra hours at all), while making sure that the code is actually badly written, and it's not just "not written your way" or "code I can't understand because I didn't study it enough". I have seen many engineers being victims of these two points. Sometimes the code just appears badly written because you don't have enough context to see that it's not.

I would stress that rewriting it only to discover oh, so that's why they did it that way is one of the most disheartening exercises in our industry. Documentation is what clarifies the 'wtf' moments in reading code since even initially pristine architecture will become contaminated by edge cases over time.

I give 100% that after you did your re-write and then left for another company next set of developers will think exactly the same thing about your codebase. 100%.

Reply on news.ycombinator.com