42 ms·

Four months is a very short time, but can feel very long. You need at least six months to really understand a complex codebase. I'm in a similar situation as yo

Four months is a very short time, but can feel very long. You need at least six months to really understand a complex codebase. I'm in a similar situation as you, our code is terrible and ugly but after digging deep I've started to see some of the reasons why the code is the way it is. My approach has been to pick the most difficult problems that nobody else can fix, and fix them. It's painful but the payoff is pretty good.

lowercased 8y ago
> You need at least six months to really understand a complex codebase. This might depend on the definition of 'complex', but I don't agree in all cases. I'm in a project right now with one other team member - we hit the ground running with 'new' (to us) code. It's been just over 10 weeks, and we have a pretty deep understanding of what's there. Honestly, it's not terribly huge, but there were 6(?) other developers before us over the course of 4 years, and each one left things progressively worse. In 2 months we have a better understanding of how the code fits together than everyone else who came before - which you can mostly tell via the commit log (and scant comments). Now... I may be out of line saying they didn't "understand" things - they may have understood and just been too lazy to bother to not break things. But 6 months is a long time. What you can learn in 1-2 months is just how bad things are, and what the most effective triage techniques can be. What's helped in this case is that... I've come in as a contractor, and there is no one else to answer to (except the client). There is no one refusing commits because of code style conflicts. No one arguing about db schema changes, or asking for my time in meetings that have nothing to do with this project. So, in that respect, the 10 weeks has been fairly productive. It's come down to experience, autonomy, lack of politics, and a focus on getting some architecture and tooling in place to allow for repeatable builds, tests and sample data. Not been smooth sailing by any means, and we're still uncovering bugs (big bugs) that date back 16 months or more. I've been in other situations where fixing the difficult problems would a) uncover bigger issues that b) cause other folks to nix the whole effort, because it rocked too many boats, and my work was rolled back. Disheartening, and if you can't get buy-in, or at least free reign to fix something, it's time to move on.

lowercased 8y ago

> You need at least six months to really understand a complex codebase. This might depend on the definition of 'complex', but I don't agree in all cases. I'm in a project right now with one other team member - we hit the ground running with 'new' (to us) code. It's been just over 10 weeks, and we have a pretty deep understanding of what's there. Honestly, it's not terribly huge, but there were 6(?) other developers before us over the course of 4 years, and each one left things progressively worse. In 2 months we have a better understanding of how the code fits together than everyone else who came before - which you can mostly tell via the commit log (and scant comments). Now... I may be out of line saying they didn't "understand" things - they may have understood and just been too lazy to bother to not break things. But 6 months is a long time. What you can learn in 1-2 months is just how bad things are, and what the most effective triage techniques can be. What's helped in this case is that... I've come in as a contractor, and there is no one else to answer to (except the client). There is no one refusing commits because of code style conflicts. No one arguing about db schema changes, or asking for my time in meetings that have nothing to do with this project. So, in that respect, the 10 weeks has been fairly productive. It's come down to experience, autonomy, lack of politics, and a focus on getting some architecture and tooling in place to allow for repeatable builds, tests and sample data. Not been smooth sailing by any means, and we're still uncovering bugs (big bugs) that date back 16 months or more. I've been in other situations where fixing the difficult problems would a) uncover bigger issues that b) cause other folks to nix the whole effort, because it rocked too many boats, and my work was rolled back. Disheartening, and if you can't get buy-in, or at least free reign to fix something, it's time to move on.