Hacker News Reader

Comment by marenkay | Hacker News Reader

Be a little more relaxed about this. Legacy code often looks like a big elephant which needs lots of fixes. Look to the tiny things instead:

- just make the function / class you're working on nicer, preferably just a small function. Apply some common quality standards to it, clean code, nice docs. - repeat this for a while, and you will have a nice set of examples and guidance for the other team members by setting an example.

Personally I am a huge fan of making that one place where you found the bug nice, adding a simple test case and moving on to the next thing. It adds up over time and does not hurt in terms of time involvement/budget since you already had to invest a larger amount fo time to find the place bugging out.

View on HN

If there’s literally no structure in place for running tests, then OP cannot just add “a simple test case.” OP also needs to build the test runner. That requires convincing his manager, who is likely the one responsible for this mess (by claiming maintainable code is not a priority).

Personally I think it’s irresponsible to hire new employees before having a maintainable project. It’s much easier to onboard employees and delegate to them when they have a safe dev environment and testable projects to break while they learn.

You don't necessarily have to convince the manager, given a few prerequisites: it's possible to get at the code and build it locally, and you're willing to go around the team and do testing on your local machine. Not an easy task, unsupported, but it can be chipped away at over time, and if the project really is as stuck as it's made out to be, there will be parts of it that aren't changing rapidly and make for good low-hanging fruit.

Gradually that test suite will accumulate enough stuff that all OP has to do is walk into work, pull the latest, and make a few easy fixes before they finish coffee. They will look like either a hero or a monster, depending on how the politics work out. It's risky, but either way something will have been stirred up.

Personally I think it’s irresponsible to hire new employees before having a maintainable project.

Have you ever been in a situation where you think "Gee, this is a mess but we are swamped here! Let's hire more people to help fix this" and then the new hire(s) joins the team and proceeds to bad mouth everything instead of helping to make things better? I have and it wasn't lack of communication or openness.

It's an attitude I can't empathize with.

- test infrastructure in every language is really a matter of minutes these days. Being able to run it locally is sufficient for a first step.

- hiring people for unmaintainable projects is literally the default for the majority of companies as everyone starts out small without directions and either fails or becomes something big. Legacy code is basically everywhere, clean code is the minority.

"Be a little more relaxed about this" is probably the best advice haha. I think I just freaked out when I saw their code/had to debug it. But, as @pascalxus said, this is probably very common in many places.

It is much more common than decent code that just lets you iterate and implement good stuff. Also the lesson to take away: code like this is everywhere and often it powers the things you really do not want to be run by something like that.

Considering that you will face this probably with your next employer again, deep breath and just enjoy the actual engineering work!

Reply on news.ycombinator.com