I just wrote a book on startups that touches on tech debt, and in your shoes I wouldn't freak out. All startups/companies acquire tech debt until they really find product market fit and something I call GTM fit. At some point you have to go back and fix it, but until your business trajectory is clear refactoring can be the wrong allocation of resources.
Ask HN: Started a new job and their existing code sucks. What to do?
31–40 of 66 posts
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#32Sounds normal. How many jobs have you had previously?
It's so normal that I'm actively looking for a new career. I'm tired of being paid to write and maintain garbage code for garbage people.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#33First at all, something akin to Chesterton's fence applies. Somebody new to an organization rarely understands all the factors that go into a code base, and even if they're right that the code base is bad, they are generally not yet equipped to safely fix it.
Second, this might be a first for you, but a new person coming in and deciding that the current code base is unsalvageable and needs to be completely rewritten is pretty much a cliché in our industry.
So what would I do? Like cheshireoctopus said, you can leave each bit of code you touch a bit cleaner than you encountered it. You can also try to get approval to start writing tests — having a test suite in place will first help you understand the existing code through and through, and then provide a safety net once you get around to proceeding to the actual refactor.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#34Been there. One of my more-recent companies was like this. So few tests, 200+ line methods, no style guides, etc.
The problem isn't going to be the code - you can fix that. It's if management is actually ok with things changing. So often there's resistance to change for a variety of reasons, some good - some bad. Bad ones include "it's too hard" or "Well, this guy wrote it this way and we don't want to hurt his feelings".
At least they are into bug fixing. I've been at companies that were feature-focused 99% of the time, because the CEO and VP of Product had overpromised so much to clients and investors that we were always chasing some overly ambitious fairy tale. Quantity ruled over quality. When things broke or didn't scale, they acted like they had no idea why. It was always more more more. These situations are the ones that can't be fixed. Run as fast as you can.
But, if they are amenable to getting a plan in place and working on this stuff slowly, then it surely can be fixed. Bug fixing is important though, as I don't want to try to refactor broken code, only to break it more.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#35Be 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…
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…
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.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#36Be 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…
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…
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.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#37I find the Boy Scout Rule to be helpful: > The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try an…
> No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result?
People would stop being willing to review his PRs, because they'd always contain off-topic changes?
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#38You gotta understand that this is pretty much the case at a LOT of places. In the beginning, you should be humble, at least for the first few years. Once you're the most senior person there, say in 5 years, you'll have a lot more political power to do the things you think are right. And as far as refactoring goes, take things 1 part at a time. Don't try to refactor everything all at once.
Few people stay that long in a company nowadays.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#39First at all, something akin to Chesterton's fence applies. Somebody new to an organization rarely understands all the factors that go into a code base, and even if they're right that the code base is bad, they are generally not yet equipped to safely fix it. Second, this might be a first for you, but a new person coming in and deciding that the current code base is unsalvageable and needs to be completely rewritten…
I agree but sometimes the whole thing is so clown shoes from the ground up it just plain isn't going to work as is. That does happen.
Re: Ask HN: Started a new job and their existing code sucks. What to do?
#40I find the Boy Scout Rule to be helpful: > The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try an…
> No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result? People would stop being willing to review his PRs, because they'd always contain off-topic changes?
Being a good source steward seems to always be 'on-topic'. The only time I've seen gentle improvements rejected is during hotfix releases.