Comment by cool-RR | Hacker News Reader

Comment by cool-RR | Hacker News Reader

Parent Full thread

Lots of people are giving advice on how to fix the code piecemeal. First put it on Git, then add tests, then, carefully and gradually, start fixing the issues. Depending on the project, this could take a year or several years, which isn't bad.

The problem with this plan is corporate politics. Say that OP takes on this challenge. He makes a plan and carefully and patiently executes it. Say that in six months he's already fixed 30% of the problem, and by doing do he meaningfully improved the team's productivity.

The executives are happy. The distaster was averted, and now they can ask for more features and get them more quickly, which they do.

Congratulations, OP. You are now the team lead of a mediocre software project. You want to continue fixing the code beyond the 30%? Management will be happy for you to take it as a personal project. After all, you probably don't have anything to do on the weekend anyway.

You could stand strong and refuse to improve the infrastructure until the company explicitly prioritizes it. But then why would that job be better than just taking a random position in a FAANG company? The code quality will be better and so will the pay.

A lot of people see this as a technical challenge, but it is a political one. The road the business took to get to this point is crucial, and understanding whether the business want to fix it is key.

In my experience once businesses get into this sort of mess they will never work their way out of it. To use an analogy, there is a point where people who make terrible lifestyle choices (smoking, obesity etc) where the damage is too far gone.

A company I used to work for had a horrendous codebase that was making them a ton of revenue. It wasn't as bad as the OP's codebase, but it was pretty terrible. It was wedded to a framework that was abandoned 8 years ago. Everything was strongly coupled to everything else, meaning it was brittle. Every release they'd have to have an army of QA testers go through it and they'd find 100's of new bugs. Every bug that got fixed introduced another.

The lesson I learned? Find these things out during an interview. Ask about their CI, ask about QA and automated testing and really push them on details. If they give vague answers or something doesn't smell right, walk away.

> But then why would that job be better than just taking a random position in a FAANG company? The code quality will be better and so will the pay.

Exactly the thing people are missing here. It's a lot of work at a very high skill level with lot of political burning ground if refactoring break things or suddenly slow down at a mediocre shop.

This is more reason for the gradual approach. Bringing source control, testing, and separation of dev and prod environments, makes things safer and will speed up work pretty soon by making the people much more comfortable to actually try things.

For what benefit in the end for the individual?

I've done that progressively over two years as a junior and I'm basically unofficial tech lead now. Managers listen to me and I can plan and influence several projects. I have other goals so I won't become official team lead by choice, but that's probably valuable to OP if he can pull that off.

Big fish in a small pond.

Speed of development.

Once you have these things in place, you can make changes much more quickly, and much more confidently.

Yes, because it's famously easy to just go grab a FAANG job whenever you feel like it, wherever you are in the world.

Not easy, but easier in my opinion than the multi-year project that OP is planning to undertake.

This architecture is not a MAANG architecture and the fix is unlikely to yield experience that will land you a job at MAANG.

If MAANG is your goal, finding yourself a C-Suite sold on a tech modernization initiative whose hired ex-MAANG throughout their org chart will accelerate your MAANG transition.

If your goal is to learn how to solve business problems for medium-to-large sized non-MAANG companies, this company is probably going to yield good experience.

Two different career tracks.

at which point you leave, having spent a satisfying six months improving things for the other devs

Reply on news.ycombinator.com