Thoughts on new job with huge technical debt
Posted by its-not-you-its-you@reddit | ExperiencedDevs | View on Reddit | 51 comments
Hi everyone, I’m a full-stack dev with a bit over 7 years of experience. I left a big tech job recently because I realized FAANG just wasn’t for me. A couple of months ago, I joined a US-based startup. During the interviews, things looked good — the team seemed nice, the company had a good vibe, and the tech stack was something I liked. But once I actually got into the codebase, I was pretty disappointed.
There’s no consistent naming convention (some files are kebab-case, others PascalCase or camelCase). The GraphQL implementation is messy and inconsistent, which makes it hard to follow how data flows through the system. On the frontend side, there are React components with 500+ lines of code, combining rendering and business logic in one place. No hooks, no clear structure.
Because of all these inconsistencies and lack of structure, I feel like I’m not nearly as productive as I could be. I spend most of my time just trying to figure out what’s going on, rather than building or improving things.
The good thing is my manager does care about good practices. He’s pushing for improvements like the current migration to TypeScript, and I feel like there’s an opportunity to help lead some positive changes. At the same time, part of me wonders if it’s worth the effort — or if I’d be better off looking for a place that already has better foundations.
Has anyone been in a similar situation? Did you try to fix things from the inside, or decide it was better to just move on?
SlightAddress@reddit
One of my most favoured and relaxing tasks is refactoring code..
Visual_Structure_269@reddit
Sounds like a great opportunity to make an impact.
dogo_fren@reddit
A bit off topic, but why would this be “technical debt”? Seems like just plain old bad engineering.
PsychologicalCell928@reddit
You have the opportunity to play the "New Guy with Outside Perspective" card.
First, you are not criticizing - you are making observations based on "Best Practices I've seen Elsewhere".
For each observation you should write down what the benefit is and, where possible, cite some papers/studies that back you up.
An answer that is just personal preference is not very persuasive.
You should try and quantify the short term and long term benefits.
(For example, bringing on new people takes longer when the code and documentation isn't standardized. Support costs tend to be higher. And there is less fungibility among the team. )
Second, if people agree, you need a plan for getting everything into compliance.
Usually that starts with tools that allow you to define standards and then highlight any non-compliant code.
Since you're the new guy - volunteer to get a lint program installed, running, and take a first pass through the code base.
Advocate for the integration of the lint program into the development process so that when a piece of code is extracted ( e.g. for a bug fix ) that developer making the fix also makes it compliant.
Alternatively, advocate for a sprint focused on code standards, or hire some temps to de-lint the code.
My advice is don't be overly dogmatic. Confrontation is not a winner in this case.
Having encountered this situation I also recommend that you adopt tools that help you and your colleagues migrate code to the standards.
If you can use scripts or code formatting tools to reduce the percentage of non-compliant code you'll win over some allies.
Third, help people from making the same mistakes again.
Put the effort in to tailoring your editors and other tools to enforce compliance. This can include using prototype files when creating new routines.
Programmers generally like to follow the easiest path.
Another good strategy. if your management is supportive of your effort, is to create a compliance release or compliance releases.
These are small releases that fit between larger releases. They are especially helpful right after a big push.
Right after a big release programmers are generally taxed and they are going to be facing a slew of bugs and bug fixes.
Once the pressure of the current release is off rather than jumping right into the next big release have a 2-4 week compliance release.
The programmers can address the things that are not compliant with the standards. Often it's a lot of formatting, renaming, etc. This is productive work that can be stopped at any point to address any problems found in the current release.
Meanwhile your code base gets cleaner and cleaner.
Another strategy that was used successfully was rewarding de-linted code.
A programmer that took on a sizable enough module or set of modules and got it to the point where lint didn't complain, i.e. the code adhered to all standards - got Friday off.
Best of luck!
Complex-Magazine6690@reddit
This describes every start up I have worked at. In fact yours doesn't even sound as bad as the average
thehuffomatic@reddit
This is normal so did their big tech company not have legacy code?
Abadabadon@reddit
Been there done that. In my case, no unit tests or code reviews or release management.
I tried to make change, but didnt get very far as the majority of my team were lazy and my leaders were absent and incompetent.
Eventually decided to leave for unrelated reasons. My biggest tip is find the 1 most important thing to change, and hammer away at that until everyone is on board. Don't bring up anything else.
Far_Round8617@reddit
The major problem is the huge quantum entanglement these code nada have. It’s not a function that is inefficient, it’s the sheer combination of mixed layers, huge files, unstructured naming and so on.
It depends on you. Do you want to feel productive, or you want to suffer and maybe get some recognition?
bgeeky@reddit
I think the key deciding factor is whether the leadership in place understands the limitations of having tech debt and is willing to invest in fixing it. If not, then you gotta go. The business will eventually suffer.
turmoiltinfoil@reddit
This is key also in my opinion. You need to have leaders and teammates who give a shit about making things better, otherwise GTFO. Maybe you can win hearts and minds and get folks on board but if it's just you and that's a battle run away.
DaRubyRacer@reddit
Man I'm in the same exact position where the source code I work on is often lacking any real supervision, just cowboy coding. I recently broke the deployment because it depended on some development generated files.
This, I guess, is my fault for not thinking far enough on the change. I just feel like touching anything in that codebase, in any of the codebases here, is like taking a toy from a child.
thefragfest@reddit
I’d look at it as an opportunity. Most codebases are a bunch of hot garbage anyways, cause customers never like/use anything we meticulously plan out in advance anyways lol. Everything that ends up successful was something one dev initially slapped together as a lark but it ended up being popular, hence why those things always end up pretty messy after a few years of customers liking it and asking for more features and improvements.
I jest of course (kinda), but seriously, learning how to improve as you go is a hugely valuable skill! And it will mean you can work anywhere cause you won’t have such high standards to start with, meaning you have more job security.
Phonomorgue@reddit
I currently hold a job where I'm basically rearchitecting the entire infrastructure and code from the ground up.
Pros: management loves me. They see me as mission critical and will throw money at the problem to get it done
Cons: I am working a lot. I expect this to be an initial cost that eases with time as it becomes more stable.
It's not for the weak of heart, for sure. I don't have distractions like kids and can just focus on this heavily. I don't think I could do this otherwise.
TooMuchTaurine@reddit
Working in underwhelming codebases and improving them is a skill in itself. A very valuable skill since 90% of code bases in companies that have been around long enough to be succesful are a dogs breakfast.
Edward05losingmoney@reddit
When we switched to typescript we had to rewrite all code because it was such a mess. Taken the team 1 year for 90% of business logic to operate on typescript and another 6 months for all edge cases we had.
thashepherd@reddit
Phew, I thought I was the only one who used that term
grandeherisson@reddit
This is the job, right here. Improve as you go.
Alpheus2@reddit
This is my jam too. #oneofus
ilikeaffection@reddit
Yep. This sort of thing has been my wheelhouse for over a decade.
binaryodyssey@reddit
I’m at year four at my startup and finally feel like I’ve accomplished the vast majority of the refactoring I set out to do when I first started. It feels good! It felt pretty overwhelming at the start though.
darkstar3333@reddit
You may think it's bad but frankly your current situation doesn't sound so bad.
Naming inconsistencies are easy fixes and GraphQL is way too easy to make a mess.
You've got it pretty good and very fixable.
Atlos@reddit
I don’t think you are cut out for a startup if this is the stuff you’re worrying about. Mixing business logic and rendering? React components over 500 lines? The horrors! Not that I disagree about those things being annoying, but fixing these at a startup really serves little purpose/value. Set up a linter and move on to things that actually give value. The worst thing you can do is continually try to refactor and spin your wheels on code that might be thrown out.
Northbank75@reddit
Me me! Been here five years, picked my battles and just started working at implementing better practices, better process and now and things are finally shaping up in a real way…. It depends what motivates you, turning this around is one of the best work experiences I’ve had .. it hasn’t been fast, but sometimes I just sit back and looking at the PRs and smile. It looks just how I wanted it to :)
The most important factor is your willingness to lead, to compromise when you still need to get things out the door on time, and to have buy in from your management.
AlertString7493@reddit
It’s weird how people see this as a problem…
If the app was a straight forward latest version of react you wouldn’t have a job because of LLM’s.
No_Quit_5301@reddit
This is your chance to go to from mid level to senior. Senior devs can push features while improving the code base at large
drguid@reddit
Doesn't sound that bad. I'm trying to keep a Visual Basic 6.0 app on life support.
SOLID principles? What are those?
MugenTwo@reddit
From experience,
Try to take control, and try to make people to have some standards and slowly improve different components of the system.
If you can’t: 1. If it pays well, then just live with it. 2. If it doesn’t, then leave.
It’s not a good idea to play the bad guy that forces people to adopt some standards. People are gonna dislike you.
bonisaur@reddit
There will be a lot of good advice from others but one thing I like to point out as an optimist is often at a new job technical debt means you will have a job for a while.
DeterminedQuokka@reddit
Can I come play? I love fixing stuff like this.
Huge positive your boss is on your side.
Step one is to get stuff in place going forward. Make rules for what new code needs to look like. Pass prettier, have tests whatever. Start adding those as acceptance criteria.
Then start applying that if you edit code. When you update code step 1 is to make it meet standards.
Step 3 is technically to fix all the old code. Basically you don’t do this step. Who cares is the code you never touch looks like trash.
lambdalord26@reddit
I'll add that as much of this as possible needs to be automated. Take people's opinions out of it. Establish a set of rules, automation enforces them, no changes get merged unless it passes those rules.
morosis1982@reddit
To be clear, it can be beneficial to get people on side by getting the team to agree on these standards. Their opinions matter here. They don't need to be ultra high on day 1, but they need to be regularly reviewed and there's a process for team members to promote change, even if it's simply a comment in retro that a specific rule is too restrictive.
CanIhazCooKIenOw@reddit
Prefacing these steps with delete unused code. Remove unused dependencies.
Not used and no one knows what it is? Gone. Not used but might be helpful? Gone and here’s the PR link in case you want to bring it back (no one need it though)
Odds are there’s a bunch of unused code and that will simplify future use cases you’ll have to support.
Idea-Aggressive@reddit
Have you ever read the source code of your favourite libs, for example, let’s say react? You’re up for a big surprise.
Oakw00dy@reddit
For startups, cranking out shit quickly with little attention to quality is often a matter of survival. What's the founders' exit plan? If they plan on growing the business quickly and then selling it, they probably won't give a crap about code quality as long as it limps to the point where they can cash out. If they want to keep it as an ongoing business, then you would do well to make them understand the risks and if there's no trajectory to deal with tech debt and establish good habits, draw your own conclusions.
Teh_Original@reddit
If you are allowed to fix the tech debt as you encounter it that's great. If you aren't and its just "feature first" then be ready for disappointment and frustration. =(
Far_Archer_4234@reddit
Honestly, Goldilocks, maybe it's time for you to persue a different career path. Getting bent out of shape because of differently cased variables suggests to me that maybe you're not ready for brownfield application development.
Ps... Most IDE's have a hotkey for renaming variables. In VS it's F2.
the300bros@reddit
Think what happens is the early startup hires people who were less experienced OR they hire someone who says, “i need 5 people to achieve your goals by the deadline” and instead of getting people they just get pressured to work harder. Now not everyone will cut corners in that situation but…. Something is going to give.
SoggyGrayDuck@reddit
Fuck them lol every company is dealing with this and I think it's HUGE factor of the offshoring trend. They ignored recommendations and pushed off tech debt to the point entire systems need to be redesigned
mattgrave@reddit
I would try to enforce an standard with linters and custom rules (if necessary).
meisteronimo@reddit
Linting and build tools is the only way to enforce rules in multi team codebases.
sneaky-pizza@reddit
Job security
OntarioGarth@reddit
Welcome to the real world! My assigned task count is 107. I closed a four year old ticket last week.
JimDabell@reddit
If you aren’t willing to roll your sleeves up and get stuck in, and only want to work places where somebody else has done it for you already, then this is going to end up limiting your skills and opportunities. You aren’t always going to have the luxury of a pristine codebase. What’s your plan, to just turn tail and run every time things are inconvenient for you? Somebody has to solve these problems, and there’s not much value in a developer who just wants other people to solve them.
cougaranddark@reddit
What a great opportunity to make an impact. It's all about mindset and the people you work with. That's just real life. I'd take that over spectacular code and a toxic team. I've done that...you don't want it.
ZukowskiHardware@reddit
Yes it is worth it. You will end up making yourself and others faster.
boring_pants@reddit
I think this is the key part of your post. There is a willingness to make improvements. That's what makes it interesting. Do you want to be part of this effort? No doubt it'll take time and you'll have to swallow a lot of compromises along the way, but you also get to help make a real difference and make the code base better. For some, this would be a dream role. For others, it'd suck.
You have to decide which camp you're in.
There's no right or wrong there, just a question of whether you want to be part of an effort to improve processes and the code base, and getting to influence and shape the process, or if you'd rather be in a team that has already figured this stuff out (but also, where you won't get to have this kind of impact)
For me, this sounds exciting. But it won't be everyone's cup of tea.
Sulleyy@reddit
My company has 600 or so employees and has been around 20+ years. We have tons of technical debt in some solutions, but the important ones are well-maintained. We invest into the products that give us revenue. When we are making a proof of concept or trying something new for a customer we really do it as quickly and cheaply as possible until we see it can bring in money. I think for a startup it makes sense to just do stuff quickly until you know what is worth investing in. And maybe you have a heap of garbage code written 2 years ago that now has customers lining up and suddenly you need to fix/refactor things while adding features and deploying to new customers... That's a good problem to have.
Would it be better to design it properly from the beginning? Yes, if you know exactly what the end product will look like and what future customers want. But the reality is you'll make 10 products, and 2 of them will bring in 80% of the cash. You may not know which ones those are and over-engineering is a problem in that case. Complexity should be avoided. So my mindset has changed and I actually agree with the quick and dirty approach even if it is painful at times.
I do think my company would have problems scaling into billions+ of dollars in revenue though. But I don't think the space we operate in really has billions of dollars to spend anyways. A company like Microsoft I'm guessing will also do things quick and dirty but not to the same extent.
warmans@reddit
I think you're going into it with the wrong mindset. Startups are always messy. The reason they grow the team is often to solve these sorts of problems. But this stuff doesn't magically get fixed - it takes someone to make it their problem, build consensus and figure out a plan.
Those big tech companies had all the same issues until someone came along and established the processes to solve them.
Kemilio@reddit
Welcome to the non-FAANG world my friend.
iMissMichigan269@reddit
I've come into a similar situation and have had a lot of satisfaction doing refactoring and helping others refactor. The downside is you'll likely have to refactor components to even understand them.
If business doesn't understand the value of minding tech debt, they likely won't understand your value when delivering their features slowly until you get traction in the codebase.
If the devs who wrote it are still employed and have some sort of ego about their mess, you could have that drama to deal with.
On the other hand, you could be the hero they need and find a rewarding career there.
gingimli@reddit
I fix things from the inside if I’m allowed to and there is an agreement with management that I’m spending time fixing things instead of working on features. I don’t go above and beyond to fix things as a side project in addition to the feature work.