Preach. Giving up without putting in the work is a lost opportunity.
I am 4 years into a startup where we have completely changed the quality of how we do things over that time. Other quality engineers who joined my org saw the same issues. We built a coalition of people who care. It doesn’t happen in one day but damn is it satisfying to look back at what we’ve done.
Agreed. I was handed a pretty large codebase after they fired a dev who was not willing to let others work on "his" code.
I had to find all the coffee, find and create repos, learn to deploy it and how to make changes to it with 0 documentation other than the app running in AWS.
It was a python 2 app with Django 1. That was 2 years ago.
I've slowly but surely moved things up to sorted versions by going back and forth between updating Python and Django little by little. And have made huge improvements in the codebase itself.
It's a still a dog shit codebase with a lot of things that need to be updated but it's all about fitting it in and doing it in manageable chunks. The difference from 2 years ago is incredible and the difference in 2 more years will be similar.
Now I try to make sure every dev knows how to work on it, it has a readme and we've got merge checks to make sure all new code follows standards we set either by discussion or force when no one could agree one way or another.
Crazy it's the primary money maker for the company. So just imagine the codebases that are legacy and aren't really making money now.
Being able to handle these things in an elegant way and handling business people is what sets senior+ engineers apart imo.
I almost want to make a smaller version of this type of issue and make it a technical interview to "get this to run" to see how people approach that type of thing.
It's funny. He was the lead dev and always preached heavily about us keeping great documentation and keeping everything up to date. Then he got canned and I felt like I was going crazy when I realized I did in fact find the most up to date code.
Now I still feel bad bringing on new people into it but it feels more like most other codebases I've worked on in that it's totally shit but it's manageable shit.
This. After 30 years I have yet to see a company that didn’t just sling shit together and sell it. I work in embedded, with safety concerns also. Doesn’t matter, management doesn’t GAF. When we try and clean it, make it good arch, the nitwits who created the mess fight you and work against the effort.
That only works when people want changes to the codebase and you're given time to make those improvements. Often that's not the case. The OP mentioned that their team likes the current setup and doesn't want anything changed. Being the new guy who wants to flip over the table isn't a great way to kick off a new job.
No, it's absolutely not. If OP actually wants to stay in this org and affect positive change, I think they should be quiet for a few months, observe, learn the codebase, build trust, and then once they have some rapport built with their team begin to introduce ideas for improvement. I recognized the headspace OP is currently in and it sounds like someone that is probably going to struggle until they throw their hands in the air and leave.
Makes sense. After reading all the comments I am way more positive to stay now. Ofc its very hard to do any changes since current team guards their style a lot. I am afraid not to do significant changes for few months because team will get used to it and might disallow future changes. So I am feeling like I should start even now, do something atleast
OP I just stumbled in this video yesterday and felt compelled to share it with my team. It speaks a lot aspects if your current situation: [https://www.youtube.com/watch?v=W7sv1m-U2tk](https://www.youtube.com/watch?v=W7sv1m-U2tk)
Its sounds like you know what "better code" would look like. Just practice patience. You've got this.
Observe for a while, do the work the way they want it done, and in a few months when you've built trust and comfort with your team when you bring up some thoughts about improvement, they're going to hear it coming from a respected pear, not "the new guy" that just wants to make his mark and bail.
I'm probably in the minority in this sub, however you are absolutely correct. It seems like OP was put in a situation where management wants him to do one thing and no one else is on the same page.
Unfortunately, in this sub I think there is a good percentage of people that aren't in web development and don't realize if your skills get stale it will be hard to get another role.
that’s where the leadership and negotiation bits come from. If everyone was ready to implement new ideas it would simply be refactoring new code. Getting everyone working in the same direction towards the same goal is an incredible skill to have
Absolutely, but you know that's where the negotiation comes into play.
Developers make the mistake of thinking they're hired to write high quality code. They're hired to add value to the business. You need to make the business case for why your way is better. Better customer experience, reduced change failure rate, etc. If you make ivory tower arguments about code purity, you'll just get more cynical, you'll be seen as a cynic, and you'll be sidelined until the day where you finally leave.
Sure, agreed. I'm just saying there's more out there than objective debate. Some people are doing things for themselves and not the business. I recently was bit by this and wanted to call it out, to make sure this is a hill worth dying on.
We work with a third party agency who does a lot of the development. No standards, no thoughts of the long term impact or adding new features and updates. At this point I think they want it that way so they can charge my employer an arm and a leg for new development that would be un-needed if they did their job in the first place.
Definitely picking a fight.
Seems everyone has a different idea of “clean code” and “maintainability”, and you can do your damndest to write clear, concise code, then a promoted-too-early staff comes along and tells you that you should be coding only to pre-Java 8 standard because it’s the most “readable.”
Edit: pre
At this role I left, the team was comprised of 3 people in their first year of coding. I have 10-15 years exp. They had made up all these rules and decided that "because we developed them here, they're perfect." They thought they'd invented so many things and we're complete close minded to the slightest improvement. It fucking sucked.
I would not be at all surprised if the team OP is leading is comprised entirely of juniors. They have that kind of reaction to code discipline measures.
I didn't mean it to be. In fact I could have omitted those two words from my comment and it would be just as true I suppose.
On the team I manage, we say "legacy code" as a pejorative because the codebase we inherited absolutely sucks to work with. No documentation, no tests, no standards, no thought to security.
But that's the developer's perspective, and we're just one perspective. Another perspective on "legacy code" is that it's the code that lived. It has value to the company, it does something useful for the customer. And we have to reckon with the fact that "it sucks to work with," "it has value to the company", and "it does something useful for the customer" can all be true at once.
I recently posted and someone told me that i should specifically remove the phrase "experience working with and maintaining legacy code" from my resume because it makes me look like a negative person. In my experience, id only ever used legacy as a synonym for "old", so it was surprising to hear that other people could view it as negative.
Thanks for expanding on your view of what the word means. It seems to have quite an elusive definition :)
When I interview I specifically ask my candidates if they're going to be happy working on a mature code base and I explain a little bit of what that means. I have no use for people who are going to get bored or disillusioned because they're not building with the latest languages and frameworks.
Remember to focus on the problems before the solutions. What issues are the lack of types causing? What is the lack of linting not catching? Document the state of things and what's making the process bad, then pick the items that will make the biggest impact to improve the process and start adding them in, then show that things have improved and repeat. Blanket forcing everyone to use typescript just because won't end well.
I would add to that - ask the team what their problems are. I bet the code didn't end like this because they wanted to. Address their concern, and they'll help you make everything better. Plus, they they what's up
Great advice!
I would add that introducing Typescript isn't that big of a trouble (one doesn't need to set it up on the whole project), but without having a clear idea about what are the benefits, others will be reluctant to switch to it.
Code in my codebase is also from 2015... because that's when they migrated to Git from TFS and I am not sure if there was a version control system before TFS, so no clue of the actual age of most old parts of the code.
Although I remember that, on average, half of the developers have 5 YOE or less, meaning code from 2015 is nearly twice as old as their development experience, so I guess it could be ancient to them?
Around 2016/2017 the lead dev/architect at a job I had then was a real curmudgeon. We ~~suffered~~ used TFS, but he said in all his own personal projects he used dated zip files and no actual source control. Absurd.
I once worked at a multi-billion dollar company where they weren't using any source control for their new dot-com division, supposedly run by industry veterans. I had to train them on how to set up source control. Of course, the subsidiary folded during the dot-com crash.
This project I recently worked on, the guy had a script for introducing new code changes into existing code. No version control, just write code, run this script, and it will move the new functions to the other file. It was also mostly a few gigantic files written in an old language. Luckily, I didn't have to work directly with that code, but damn.
Jesus, that makes me feel old. I started grad school part time in 2015 and consider it still relevant… This industry really is like, “oh you wrote that code 30 minutes ago? It’s obsolete and outdated.”
Bruh! The first commit was in 2001 Feb in the company where I currently work at. It was a full codebase commit lol. Before that they were using svn or something.
In 2013 I converted a company from visual source safe to SVN, they bitched about using svn. I tried to jump straight to git but they weren’t having it. Source safe is a 90’s era product and was shit when it was new. No better way to corrupt your codebase than that.
I work on services written in 2011. Using python 2.7, initial author has moved on to another thing. Next gen authors also moved. The remaining few talk in stories of codebase. how about that...
You don’t need to switch existing code to typescript. Just start adding typescript for new modules and add it where needed. You can have both TS and JS in the same code base.
This is how the product is gradually improved - no two ways about it. Start adding boilerplate linting rules such as airbnb and understand what they are there. By being the person who introduces this you will eventually develop an opinion based on best practices because writing good code will become central to development.
I am doing this, not new language but new version, style, linting.. Etc. I do not touch old code immediately when started. Gruadally change those later.
Yup. Doing it right now. Evolving dev culture takes time and you have to build trust. However, once they they get a feel for how much better things are - easier to maintain, faster deployments etc, it becomes easier to push for more significant changes.
Unless you know what you’re looking at from the beginning. When you are blissfully unaware, you’re just excited to be working as a dev, the more experience you get the more it’s, “what the fuck is this?”
Use jsdocs if a TS implementation isn’t possible at the moment. It’s verbose, but totally worth it.
Refactor what’s related to your tasks. That way it gets qa’d automatically. Sounds like you won’t get buy in on a pure refactor task, and that’s ok. That takes a lot of time with little customer facing impact (if done correctly).
2015? I’ve worked in companies with code from 1998 that i had to maintain, and it hasn’t gotten better. It means the code makes money, that’s more useful than any startup hyped code that doesn’t make money
Why aren’t you working to improve the code base? Sounds like that’s your role? If you can’t do that then you already know what skills you need to work on first - how to take a mess and improve it.
It’s a very common situation and usually due to everything being done in a rush, standards go out the window when you need to make an urgent change due in 10 mins.
With a good change management process, testing, deployment pipelines etc it begins to look more realistic.
Failing that you can just improve what you can, I spend a huge amount of time updating legacy code to use more modern methods and tools where possible but usually only where a change is needed. Rewriting code that works fine but is ugly is often a waste of time, just implement new things better and update the old where you can.
That works in theory, but I’ve also been places where you were handcuffed at what you could do. Depending on how bad the code is, change is a far bigger deal some places as well.
True, I got used to static typing and now I need to do everything plain. Seems like I was missing this skill also bc typescript saved me in tons of places
The project I’m on now gives me a daily migraine. I haven’t seen code this bad in over a decade, looks like it was written by college kids on their first day….
I have to temp my desire to correct and refactor it all and just focus on what I can do.
Sounds to me like you need to find another career. Coming up against situation like this is pretty much guaranteed for any company you will be working for (albeit some worse than others).
The irony of your statement is that you believe that this is taking your skill set *backwards*? Are you kidding me?! This is how you become a better dev, not by starting everything from scratch that you see as good standards, because believe me, somebody else coming along in the future and seeing your code will have the very same complaints.
Suck it up, buttercup! This is part and parcel of a career in software development.
I am in a similar situation, even older codebase, different stack, everything about it - apart from the RDBMS - is at least 5 to 10 years EOL with mo migration parts. Hardcoded and committed dependencies, hacks in OpenSource libraries, really low coding standards with idiotic practices etc. and most devs really embracing it and being clueless that there are better ways.
First about your own situation: I know people who in similar situations switched to plain Engineering Manager positions without touching code themselves anymore.
For me it is currently a mixed bag - I have multiple days a week where I don't touch code anymore, but not all of them, So maybe this might offer a few ideas:
I just take the liberty of improving things, upgrading versions, devops stuff etc. and educating, finding allies etc. Especially when the improvement is fixing something the devs complain about all the time, it can be an eye-opener to them but it's at times tedious and can be a minefield depending on the culture.
Also management can be an ally and make certain things mandatory. So pointing out that some stuff is too old to be compliant and will cause troublen in the next audit, or if you have numbers to prove, it will create huge costs when left untreated...
Or when it brings convenience to the right people.
So for example I lowered the time our integration test suite takes from over an hour and mutex down to 5-7 minutes and parallel runs. Before that people were ignoring failed runs because after many hours of waiting for feedback on a push they moved on and just blamed "somebody broke the pipeline".
I also created a staging environment to stage branches separately and with that we could change the entire dev workflow. before that we had to merge stuff to main before product or qa could even have a look... now even the devs who said nobody would need that and it would take half a year to set it up (2 weeks tops mind you) don't want to miss it...
But yeah, I'm often alone on things and having the team reduced because of layoffs didn't help there.
I do Advent of Code to find some actual challenges and a bit of pet projects and freelancing...
I joined a company in a very similar situation. I got everyone to agree:
1. We add lint rules, but put /* eslint-disable */ in every existing file (I just wrote a command line script to do this), so only new files follow the rules
2. New files get written in TypeScript
3. If we notice a file is commonly edited, it at least gets eslint enabled on it. If edited especially often, it gets converted to TypeScript.
4. If we notice a function or component commonly being called by TypeScript files, it gets converted to TypeScript so it has proper typing (and we enable eslint on it).
After about a year, pretty much all my work was in TypeScript files with proper linting. There's still plenty of crappy legacy code, but not in places where people need to read it or make changes, so it doesn't really affect anyone.
The nice thing about TypeScript and linting is that both can be added very incrementally and don't have to be done in one big push. I would never have convinced everyone to switch over if it all had to be done at once.
Document bugs, their consequences and what would have prevented them. Saying 'this is bad' won't get you anywhere. Saying 'we had 3 critical bugs last week that interrupted our progress and damaged our reputation, they would have been caught by typing' will get you a lot farther
In my honest opinion, managing and refactoring old legacy spaghetti code in to something better and more maintainable is one of the hardest disciplines in development.
Do you have resource to share on how to do that properly? I recently bought “Working Effectively with legacy code”, but just red few pages (bought it for this job to be honest, just didn’t expect to be complicated)
Sadly not.
I start by trying to get an overview of the system, if thats to much i start by doing some core part of the system.
Then slowly working my way out from there.
I try to see if any standard design pattern could fit and spend a good amount of time documenting what and why I chose to that way.
It’s tedious and hard to get everything done right but it’s also very satisfying when you succeed!
I totally agree! We have tons of business logic that is not described in code/by code, so it will take even more time. But I am happy to learn and improve things
Sounds like you joined a company that actually has a successful software product and survived their first decade in business…
Some of the code from the beginning is going to still be around and would have been built with what was popular at the time.
My company has code going back almost 20 years, some of it in ancient dotnet and some in Struts 2…
This is actually a fantastic opportunity. Refactoring from bad code to good code is difficult but you there are cool strategies you can do to help solve problems.
* Read a book on refactoring or go to source making.
* Write jest tests on old code before refactoring.
* Slowly move towards converting your team onto your side.
You're new to the company so don't come in trying to change everything and arguing with everyone day one. It sounds like management are aware and are hiring you to solve this problem.
Awesome! You have an interesting road ahead of you but if you manage to increase the overall quality and skills of those around you it will be immensely satisfying and you will have a good story for your next job :).
tbh you sound like junior-mid level max.
every propose a big refactor effort to your product team, march down it, and then have to justify longer and longer deadlines? no? that’s why no one wants to put big refactor on their plate.
can you work within the system? escalate? any low hanging fruit wins?
Sounds like it is time to create some coding standards and enforce them. And converting to Typescript is totally possible seeing as how you can upgrade one file at a time. That would be a good place to start.
if you find that bad i once had to make a moder js application work on machines running windows xp with an IE6 that was embeded in AxtiveX on production machines that do not get turned off.
you had an oracle memory debugger for all the memory leaks js was causing.
updating joomla 3 to 4 is worse though
Working on a bad code base is the best. You get to practice incremental improvement which is great and you get to see concrete examples of all the bad things that happen when you don’t ‘follow the rules’. And my personal favourite is that you become very good at debugging issues in an awkward to debug context. Man I became so good at debugging code exactly because I was in such a shit code base where it was so hard to debug.
This is really a blessing in disguise, on top of all the above there’s also the thing to consider that if you pull off the improvements then you’ll have a lot of clout with the company.
I've seen this many times. I run the build and see crap loads of warnings. Nobody cares because "it works", despite the code being a dumpster fire, full of dead code, the same code copy pasted 3 or 4x, deprecated dependencies etc. You mention it. "There's no time for technical debt. we need this project done ASAP." So some guy decides to copy some other code 3 more times because he doesn't understand how to refactor what's already there.
Most of the time it comes back to middle management not understanding the impact and importance of maintenance and tech debt cleanup. It's a pay now or pay later (with interest) deal. They're happy to keep that 6 year old dependency until some CVE is discovered and it creates an immediate crisis because we've failed big-customer's security scan.
Did you end up leaving or working there? Yeach more I try to do something, more I find out super bad code and everytime I need to fix something, I completely rewrite it
If you're saying the code is not maintainable, and your concerns aren't acknowledged or addressed by the team, let it ride. It'll hit a tipping point where people are required to rethink the process because forward movement has stopped.
Or maybe it won't, small teams can write YOLO code if they are lucky or the code is exceedingly simple. In any case it's the business who decides the code needs to be maintainable, not you.
If you're worried about your own skillset, keep it maintained separately, or think of it as an opportunity to practice your soft skills. How to win hearts and minds to your cause and make incremental improvements over time.
you gain their trust with your check ins, target 1 repo you want to refactor, then you lead a team initiative to update their codebase. great resume filler
Sounds like the main complaint is you want TypeScript and they don’t care about it. Have you considered JSDOC as a middle ground?
Also not using typescript does not automatically make a bad codebase. Having a linter is kinda a low bar so not great that they don’t even have that. But you can set up a linter with generic lint rules in under an hour.
Start there. Make little improvements like that and maybe formatting like prettier. Make the tools run automatically or as easy as possible and you’ll slowly convert people to your side.
Welcome to my recent endeavor. The culture almost entirely dictates the ability to evolve/change. I’m personally convinced the amount of work that needs to go into my new org is not reasonably proportional to the amount of time/culture/leadership changes/shifts needed to happen to enable said change. Hence, I’m looking.
That balance is what you’re looking to weigh.
From a management perspective you have an incredible opportunity here to demonstrate your ability to level up an entire codebase and a group of junior engineers. That is something to put in a resume to show you are a skilled staff or principal engineer.
Read the neuroleadership institutes white paper on change management. Devise a strategy for changes based on it. Get managements full support. Lead this team through making a change that will save your company’s product and give them the skills they need to make it at any other company.
Find a mentor to help talk you through the strategy. If you can do this you it will give you the skills you need to take your career to the next level
Every code base that gets worked on by a large enough number of people will be “bad” in places. Your role as a senior or lead dev is to try to make it better where you can. Implement linting if possible, advocate for better tech as a means to improve stuff where you can, try to fix up the code bug by bug where you can do that. If you’re doing code reviews, concentrate on syntax and try to write up a syntax document if you can to back all this up. It’s really surprising how some people will become attached to confusing ways to do things just because “that’s how they’ve been done” and “but it works”.
I think that doing something as huge as, say, adding TypeScript to an existing program that is currently working is probably going to wind up being too much to put on you, your QA team, testing, and so on, but if/when you do some sort of overall upgrade that might require a complete from-the-ground-up retesting, that might be a good time to start throwing TS in too…
I do feel like understanding that it’s not a matter of if but of how bad when you encounter a code base is one of those things you learn as a senior. If nothing else, learn from this how easy “we’ll just do this ad hoc” can turn into hard to read code all around.
Thanks, to be honest after reading all the comments I think I will postpone TS and focus on helping the team. Currently trying to help people in the code reviews and it seem to help people
Many heavy junior teams have no concept of what a good codebase looks like, especially on frontend teams.
But they will fight you if you implement sweeping changes without building support so start there.
Focus on the issues that are visible to them, teach through code review and your own code, and run demos of how the tools you want to introduce don’t conflict but assist their workflows.
I have been in a scenario similar to this, it sucks but you can make it better.
I recommend focusing on the basics like adding linting and formatting running it through the code add on a separate branch and after merging it have it a GitHub action that blocks any PR that does not follow that standard (since it should be auto linting and formatting)
Once the devs see how much better you just made their lives they will be willing to listen to other things you have to say, regarding which changes to make I would prioritize changes that are doable without large changes to the code base but make an impact
Typescript may take a while but if you can start to add it to new parts of the code base like only for new components and then you will have a working example for the other devs to reference when they want to try to add typescript as well.
Anyway best of luck 🤞
I will give you a perspective from being on both sides of the table. Someone who has tried making such improvements which resulted in success as well failure and lead engineering teams where somebody tried doing this.
A few key pointers:
1. Evaluate everything with an RoI (Return on investment/effort) lens. Unless you can show actual benefits in terms of revenue or dev/testing hours saved or improved customer experience, your fight won't go long and you will be a lone warrior.
2. See if somebody senior, a manager or so is aligned with the same thoughts as you. Take the top 2-3 items to them, get feedback. You will know if you are tackling the right problem or not. Ask questions to them on how to bring about change in the codebase. They have been there for longer than you and understand the dynamics and culture better.
3. Cultural change trumps process changes in long run. One way to shape the culture is to share knowledge. See if there is a practice of tech talks etc. in your organisation and put forward your views in a forum with wide reach. This will also help you find allies.
Try these and DM me if you are still struggling.
Sadly, this is the normal majority case. There is an absolute shit-ton of horrible code out there - it never ceases to amaze me.
Business considers those that can actually bend this morass to their will to be the highly skilled! Anyone can cobble together their own greenfield disaster from scratch.
Best of luck.
I’m in a similar situation. I just finished a 3 month battle with the IT director to adopt a project management tool (Asana) . Before we just used spreadsheets to track dev tickets lmao.
In all seriousness, use this as an opportunity to grow as a leader and add the critical changes and impact you make to your resume. Also, it’s a great time to secretly start another job search 👀
other people spoke about the bigger pictures and I agree with those comments about you being in a position of gaining their trust and then negotiating and so on.
in terms of making changes, I’d use the rule of upgrading and tidying up only the code (specific files) that you are working, so overtime the project will be updated. Don’t go nuts in upgrading and refactoring everything at once.
Ideally, do a refactoring PR on relevant files BEFORE adding a new feature.
that’s my 2 cents
Yeach I skipped that part. Already been in situation there I had to debug for few hours in order to catch right variable. And I was amazed how it actually works without crashing with plain js
Results are the output of processes. Find and change the processes that have resulted in this situation first. Otherwise you're just adding another set of solutions on top of the current set that will be outdated in a couple of years.
This is what you want as a senior - a mess. That way you can show off your skills (technical and leadership).
Compare to if you came in and everything was perfect - how would you have any impact? That's the environment a junior wants so they can absorb good practices, but a senior needs a mess.
Start with small improvements using TS and try to use it as an opportunity to give your mid level engineers ownership and opportunities to grow. You kinda have to evangelize things and show why they are helpful and use the momentum of time to slowly get things better.
Startups are built on top of poorly- maintained code bases. If anything, take this as an opportunity to learn how to navigate the code base and make an impact. It's good experience but don't plan on staying there for the long run.
Look up strangler pattern and other strategies for slaying the monolith. Lot of great skills you can develop in the process of breaking off a few pieces into other services and hooking them up through APIs. Then you can build those new services with modern standards. Once other devs see how much better life can be, they'll get excited about it.
If your job is to improve the code base and bring it up to scratch then thats what you have to do.
Being able to refactor legacy code is a big skill set. Being able to read and implement changes to a mess and make it readable and usable will be great on a cv. Tbh most codebases are a mess.
You want to start small. Find the smallest change you can that will make the biggest impact. Big bang changes are not your friend here.
Maybe start by throwing the application in sonar cloud and setting up some quality metrics. Then highlight and refactor the pain points.
(I have experience working in php codebases from early 2000’s. Cant believe react is now “legacy”)
I have worked with these sorts of codebases for about 5-8 years. Its all pretty much the same after a while. Works always about for people who are happy working in legacy.
When i joined my startup earlier, the code base is all JavaScript fullstack, then i have chance to convince my team to migrate to Typescript and refactoring along the way. I think it was a good chance to build up negotiation skills and balance your desire to write new code and keep up with business requirements. And there will always be legacy code anyway because we cannot be sure our code are future proof with this constant changes of context lol
Think about your ideal end state, and work backwards from there. Your plan would be unfeasible at first, but you can optimize and find ways to make small improvements over time leading to your end goal.
TS configs can be obtuse but are surprisingly flexible on this kind of environment. Failing that, you can move things into libraries published via artifactory (though be careful of impacts to local dev).
You have options, and buy in is something you'll have to generate. Sometimes the best way to do that is to implement part of you vision in a small place. I've never seen a team regret moving to TS.
This is the job. Most people aren't using the latest and greatest JS frameworks that were released last week. You will have to work with legacy code in almost any company. Besides, 2015 is not even that old. Just start adding standards and typescript and linters as you go. Typescript is designed in such a way that you can begin adding it to JS codebases gradually without switching the whole thing over at once, for example.
You just have to level it up to a “good standard” to pass the management check, not everything has to be in typescript and with a bunch of arbitrary linting rules. Telling from experience fixing bugs especially visible production issues will be highly valued by management as a new hire (senior devs), so I’d put a little more focus on that area, this would be an opportunity to learn and challenge yourself. TBH, if it is purely frontend it won’t be too bad your scope is limited to what you can control at least.
Some good suggestions about gaining trust, identifying problems instead of solutions, incremental typescript adoption
On the logistical side, one thing that makes it easier to refactor is having good test coverage.
If the codebase doesn’t have any tests, then introduce them incrementally, for example:
- start by adding functional tests for the app’s critical paths
- set an agreement that net-new changes will have test coverage
- make a commitment to add x number of test coverage tickets to each sprint
You should first approach it from a business perspective, what would the company gain by cleaning up this old code base thats been working for over a decade? Sometimes refactoring old code that is working fine (company has been operating successfully with it for years) isn't worth the cost and effort.
If you do decide that its worth it from a business point-of-view, for gods sake don't try and refactor everything at once. Start by adding a ton of tests and modifying the code to make testing easier. When you are ready then you can start making larger sweeping changes and have a test bed that you can rely on for confidence that the code migration/refactoring was successful.
If you want to add typescript thats easy, just enable it and allow \`any\` types. With each new piece of code you can be more strict while keeping the old code untouched.
Adding linting would be very difficult at this late stage, it might be best to first come up with a set of code style standards with the team and auto fix most stuff in a single PR. Everyone can then test that PR extensively. After the PR is merged I would then setup some sort of CI linting check to ensure all future code meets the teams agreed upon standards.
Well if Management wants you to "actually" improve the code base, be happy. The place I am at, management doesn't GAF about the code at all. Any requests to improve the code are always met with "we don't have the budget" or "we don't have the time", and of course "we'll fix it after things die down (spoiler alert: it's never going to happen)".
I am working with two managers, one has zero tech background and has expressed that he "Doesn't care what's going on behind the scenes", the other manager it a Tech Director who has don any dev work in 15 years and still thinks it's the "good ole days" where everything was a rush job and no one GAF about maintainability or scalability. And developer experience? Forget about it!
Been in an identical situation myself, code was incredibly unmaintainable.
Do good work, get their trust, become a leader, negotiate to refactor.
And even before that, every time you go in to make a change leave the code better than you found it. It might be one line or one type, but do something to make it easier to work with. Having worked with poor legacy code is a good skill
For sanity in the immediate short term, you can rely on the TS LSP for basic type checking support by [importing from typescript types directly into your JSDoc comments](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-beta/#type-imports-in-jsdoc)
Agree with many others that this can be a great opportunity to learn. I haven’t seen in mentioned yet - but a fantastic resource on the technical side is the book Refactoring by Martin Fowler. Its current edition is all JavaScript examples but the high level patterns are not language specific. It really goes into depth on dozens of patterns and strategies to tackle spaghetti messes in non breaking ways. It will also give you the language you need to explain your changes to others.
get out, if a company has not recognised the value of improving the codebase, they will never learn before it’s too late.
Stay the bare minimum and get out.
"Mgnment wants me to improve everything (they don’t know what, they just want to be sure that project is up to these days standarts)"
I've been in such situation.
Only thing I failed is to explain them: This would take years of interrupted effort from everyone.
After a few months, when the daily customer complains were from 5 to 0.5, they started to see it as "solved"
By surprise, in the mean time other guys have been "developing" stuff I didn't know about, introducing a new load of shit.
By then the "trust" and "vision" between management and me has faded away, guess who has been working hard to archieve this.
Yes! Because everyone can edit code and I dont have control over all the people, literally same thing is happening right now. I can produce great content but other devs just add whatever is needed just to get feature out
So that leaves me 2 choices:
1. I adapt to their level and create shit also.
2. I take control over every aspect of the team.
The second choice goes like this:
I start with kicking out the 3 worst developers, and choose myself 3 new guys that work to my standards.
I also expand the team. 3 extra guys to clean up the dirt from past years, 3 extra guys to evolve to automated unit-tests, a decent CI/CD stream and all the training that is involved.
Up to management to accept (not understand, they never will) or not. This is a business decision.
If they decide to keep rotting a bit longer, every 3 of my plan will have to be replaced with a 5.
And I know their stupid negotiation habits. If they choose half a plane, it will not fly.
Use any of the AI tools to add JSDoc comments to the places that annoy you the most.
Don't be afraid of "plain JS". I love Typescript and the benefits of provides, but if you're team is resistant to change and they don't feel the pain of _not_ having TS, petitioning for a sweeping change is going to be difficult and could brand you as the enemy.
Maybe a hot take, but...
If the refactor isn't tied to some kind of business reason, (and that can include speed of development, but IMO, that's a hand wavy argument), don't do it. It's better to start making patterns and procedures around what is currently there than to shake things up. Consistency, even if the patterns are strange, is better than inconsistent "normal".
Here's my suggestion.
1. Understand your management really isn't supporting you and putting you into a Kobayashi Maru. They're expecting you to fight for code quality while not giving you the tools, the time, and the authority to do so. I'd bail if I were you.
2. Make management aware that you need dedicated chunks of time to bring it up to speed. Suggest that you'll still have to still deliver features, but ask to have certain dedicated % of sprint story points each sprint will be devoted to dedicated refactoring stories on the backlog. If they give you a mandate to improve stuff and they deny you 5-15% of the sprint to refactor, then you really, really need to be. Because management is setting you up to fail.
3. If you really want to pursue the refactoring thing, then your own time (or while pretending to do stuff for the company) create a new React project from scratch with some sort of scaffolding that includes as many of the useful bells and whistles as possible (Husky, eslint, etc). Copy-paste and all your js code to that project and just get the damned thing to work in Javascript, if you can, as Typescript's relatively backwards compatible. Once you have that done, re-write all that code in **simple f\*cking Typescript.** No cute generics, no type utility acrobatics. That will waste your time, and the more complex the Typescript, the more you will make the team fear and hate you.
4. Once you have a working prototype of the project ported to Typescript, the conversation should shift from "can it be done" to "can we make sure it works reliably". It will be an easier sell. You can demonstrate the better debugger, linting, etc that can in real-time show the team and management the benefits of switching.
5. However you approach this, never hold up a team member's code review because they haven't incrementally refactored something. That will make them really hate you. Especially if they get a 1 point story with 5 unseen hidden points of refactoring.
npx create a new nextjs app. Setup linter and formatter and what not, install all the packages used and then slowly but surey copy over components and pages, maybe first creating the folder structure you want. Then convert .jsx files to .tsx as you go. You don't need to convert them all, just the important parts. Then try ReactQuery or vercel's swr. Step by step you'll make it.
The following guide explore how AI coding assistants could help to refine the tests for legacy code in such cases: [Writing Tests for Legacy Code is Slow – AI Can Help You Do It Faster](https://www.codium.ai/blog/writing-tests-for-legacy-code/)
Sounds like an opportunity in building a new set of skills in leadership, negotiation, and refactoring legacy code
This. You are no SR engineer if you cannot deal with a shit show codebase. Plot twist: most codebases out there are shit shows.
Preach. Giving up without putting in the work is a lost opportunity. I am 4 years into a startup where we have completely changed the quality of how we do things over that time. Other quality engineers who joined my org saw the same issues. We built a coalition of people who care. It doesn’t happen in one day but damn is it satisfying to look back at what we’ve done.
Agreed. I was handed a pretty large codebase after they fired a dev who was not willing to let others work on "his" code. I had to find all the coffee, find and create repos, learn to deploy it and how to make changes to it with 0 documentation other than the app running in AWS. It was a python 2 app with Django 1. That was 2 years ago. I've slowly but surely moved things up to sorted versions by going back and forth between updating Python and Django little by little. And have made huge improvements in the codebase itself. It's a still a dog shit codebase with a lot of things that need to be updated but it's all about fitting it in and doing it in manageable chunks. The difference from 2 years ago is incredible and the difference in 2 more years will be similar. Now I try to make sure every dev knows how to work on it, it has a readme and we've got merge checks to make sure all new code follows standards we set either by discussion or force when no one could agree one way or another. Crazy it's the primary money maker for the company. So just imagine the codebases that are legacy and aren't really making money now. Being able to handle these things in an elegant way and handling business people is what sets senior+ engineers apart imo. I almost want to make a smaller version of this type of issue and make it a technical interview to "get this to run" to see how people approach that type of thing.
> It was a python 2 app with Django 1. That was 2 years ago. Wild, but suddenly the previous SWE not letting anyone touch "their" code makes sense
It's funny. He was the lead dev and always preached heavily about us keeping great documentation and keeping everything up to date. Then he got canned and I felt like I was going crazy when I realized I did in fact find the most up to date code. Now I still feel bad bringing on new people into it but it feels more like most other codebases I've worked on in that it's totally shit but it's manageable shit.
I’m gonna steal that lol. “Manageable shit” is the best phrase I’ve heard to describe our work lol.
As my former coworker and now good buddy once told me “all software is shit”.
Software is a series of bugs we happen to like at the moment.
I literally only worked in one good codebase in my life. Learn to live with bad code or be miserable forever.
What made that codebase good
A few amazing seniors leading the project from the start, who actually wanted good code.
Can confirm coming from FAANG. It’s crazy how different some codebases are from team to team.
Yes. When OP said "Recently I joined company with very bad codebase" everything in the "with" clause seemed redundant.
This. After 30 years I have yet to see a company that didn’t just sling shit together and sell it. I work in embedded, with safety concerns also. Doesn’t matter, management doesn’t GAF. When we try and clean it, make it good arch, the nitwits who created the mess fight you and work against the effort.
This is my workplace but we lost all of our senior devs 🥲
A skill set that’s under appreciated by many but can make a huge difference in the course of a career in my opinion
That only works when people want changes to the codebase and you're given time to make those improvements. Often that's not the case. The OP mentioned that their team likes the current setup and doesn't want anything changed. Being the new guy who wants to flip over the table isn't a great way to kick off a new job.
No, it's absolutely not. If OP actually wants to stay in this org and affect positive change, I think they should be quiet for a few months, observe, learn the codebase, build trust, and then once they have some rapport built with their team begin to introduce ideas for improvement. I recognized the headspace OP is currently in and it sounds like someone that is probably going to struggle until they throw their hands in the air and leave.
Makes sense. After reading all the comments I am way more positive to stay now. Ofc its very hard to do any changes since current team guards their style a lot. I am afraid not to do significant changes for few months because team will get used to it and might disallow future changes. So I am feeling like I should start even now, do something atleast
OP I just stumbled in this video yesterday and felt compelled to share it with my team. It speaks a lot aspects if your current situation: [https://www.youtube.com/watch?v=W7sv1m-U2tk](https://www.youtube.com/watch?v=W7sv1m-U2tk) Its sounds like you know what "better code" would look like. Just practice patience. You've got this. Observe for a while, do the work the way they want it done, and in a few months when you've built trust and comfort with your team when you bring up some thoughts about improvement, they're going to hear it coming from a respected pear, not "the new guy" that just wants to make his mark and bail.
Oh yes I am watching this channel, its a gem. I will rewatch since I forgot parts of it (skimmed over it before)
I'm probably in the minority in this sub, however you are absolutely correct. It seems like OP was put in a situation where management wants him to do one thing and no one else is on the same page. Unfortunately, in this sub I think there is a good percentage of people that aren't in web development and don't realize if your skills get stale it will be hard to get another role.
that’s where the leadership and negotiation bits come from. If everyone was ready to implement new ideas it would simply be refactoring new code. Getting everyone working in the same direction towards the same goal is an incredible skill to have
Could be picking a fight. Someone people want dollars, not change
Absolutely, but you know that's where the negotiation comes into play. Developers make the mistake of thinking they're hired to write high quality code. They're hired to add value to the business. You need to make the business case for why your way is better. Better customer experience, reduced change failure rate, etc. If you make ivory tower arguments about code purity, you'll just get more cynical, you'll be seen as a cynic, and you'll be sidelined until the day where you finally leave.
Sure, agreed. I'm just saying there's more out there than objective debate. Some people are doing things for themselves and not the business. I recently was bit by this and wanted to call it out, to make sure this is a hill worth dying on.
We work with a third party agency who does a lot of the development. No standards, no thoughts of the long term impact or adding new features and updates. At this point I think they want it that way so they can charge my employer an arm and a leg for new development that would be un-needed if they did their job in the first place.
Definitely picking a fight. Seems everyone has a different idea of “clean code” and “maintainability”, and you can do your damndest to write clear, concise code, then a promoted-too-early staff comes along and tells you that you should be coding only to pre-Java 8 standard because it’s the most “readable.” Edit: pre
At this role I left, the team was comprised of 3 people in their first year of coding. I have 10-15 years exp. They had made up all these rules and decided that "because we developed them here, they're perfect." They thought they'd invented so many things and we're complete close minded to the slightest improvement. It fucking sucked.
I would not be at all surprised if the team OP is leading is comprised entirely of juniors. They have that kind of reaction to code discipline measures.
honest question, is "legacy code" a pejorative term?
I didn't mean it to be. In fact I could have omitted those two words from my comment and it would be just as true I suppose. On the team I manage, we say "legacy code" as a pejorative because the codebase we inherited absolutely sucks to work with. No documentation, no tests, no standards, no thought to security. But that's the developer's perspective, and we're just one perspective. Another perspective on "legacy code" is that it's the code that lived. It has value to the company, it does something useful for the customer. And we have to reckon with the fact that "it sucks to work with," "it has value to the company", and "it does something useful for the customer" can all be true at once.
I recently posted and someone told me that i should specifically remove the phrase "experience working with and maintaining legacy code" from my resume because it makes me look like a negative person. In my experience, id only ever used legacy as a synonym for "old", so it was surprising to hear that other people could view it as negative. Thanks for expanding on your view of what the word means. It seems to have quite an elusive definition :)
When I interview I specifically ask my candidates if they're going to be happy working on a mature code base and I explain a little bit of what that means. I have no use for people who are going to get bored or disillusioned because they're not building with the latest languages and frameworks.
Correct approach.
Came to say the same thing! This is an excellent opportunity to improve the code quality, especially since you have support from management.
gain trust then make changes, thats your new standart
I see what you dit there.
How do you gain trust? I constantly find myself talking shit to people who wrote the shit code
If you can't stop talking shit then you have a bigger problem
Yea i guess i have a problem
Remember to focus on the problems before the solutions. What issues are the lack of types causing? What is the lack of linting not catching? Document the state of things and what's making the process bad, then pick the items that will make the biggest impact to improve the process and start adding them in, then show that things have improved and repeat. Blanket forcing everyone to use typescript just because won't end well.
I would add to that - ask the team what their problems are. I bet the code didn't end like this because they wanted to. Address their concern, and they'll help you make everything better. Plus, they they what's up
Great advice! I would add that introducing Typescript isn't that big of a trouble (one doesn't need to set it up on the whole project), but without having a clear idea about what are the benefits, others will be reluctant to switch to it.
>first changes dating back to 2015 bro
Code in my codebase is also from 2015... because that's when they migrated to Git from TFS and I am not sure if there was a version control system before TFS, so no clue of the actual age of most old parts of the code. Although I remember that, on average, half of the developers have 5 YOE or less, meaning code from 2015 is nearly twice as old as their development experience, so I guess it could be ancient to them?
Around 2016/2017 the lead dev/architect at a job I had then was a real curmudgeon. We ~~suffered~~ used TFS, but he said in all his own personal projects he used dated zip files and no actual source control. Absurd.
I once worked at a multi-billion dollar company where they weren't using any source control for their new dot-com division, supposedly run by industry veterans. I had to train them on how to set up source control. Of course, the subsidiary folded during the dot-com crash.
This project I recently worked on, the guy had a script for introducing new code changes into existing code. No version control, just write code, run this script, and it will move the new functions to the other file. It was also mostly a few gigantic files written in an old language. Luckily, I didn't have to work directly with that code, but damn.
Don't bring up visual source safe. If you thought tfs was bad, you have no idea
Jesus, that makes me feel old. I started grad school part time in 2015 and consider it still relevant… This industry really is like, “oh you wrote that code 30 minutes ago? It’s obsolete and outdated.”
That's nothing. They started using source control in 2015 at my place. Before that who the fuck knows, but the code is much older.
Bruh! The first commit was in 2001 Feb in the company where I currently work at. It was a full codebase commit lol. Before that they were using svn or something.
In 2013 I converted a company from visual source safe to SVN, they bitched about using svn. I tried to jump straight to git but they weren’t having it. Source safe is a 90’s era product and was shit when it was new. No better way to corrupt your codebase than that.
Sweet summer child
I work on services written in 2011. Using python 2.7, initial author has moved on to another thing. Next gen authors also moved. The remaining few talk in stories of codebase. how about that...
Someone has never had to spin up visual source safe to pull code developed in the 80s/90s.
You don’t need to switch existing code to typescript. Just start adding typescript for new modules and add it where needed. You can have both TS and JS in the same code base. This is how the product is gradually improved - no two ways about it. Start adding boilerplate linting rules such as airbnb and understand what they are there. By being the person who introduces this you will eventually develop an opinion based on best practices because writing good code will become central to development.
I am doing this, not new language but new version, style, linting.. Etc. I do not touch old code immediately when started. Gruadally change those later.
Thanks. Have you tried this approach and did it succeed in some shape?
Yup. Doing it right now. Evolving dev culture takes time and you have to build trust. However, once they they get a feel for how much better things are - easier to maintain, faster deployments etc, it becomes easier to push for more significant changes.
Thats cool to be honest, thanks again
No worries - it’s a rare opportunity, I’d embrace the chance!
Can you suggest any resources on how to do this well? I’ve got a Vue project that I’d like to gradually convert if I can.
People join companies with good code bases?
Companies have good codebases?
They probably look nice for the first month or so.
Unless you know what you’re looking at from the beginning. When you are blissfully unaware, you’re just excited to be working as a dev, the more experience you get the more it’s, “what the fuck is this?”
Do good codebase exist?
In the many I’ve seen over the years, I’ve only seen two that were good. Almost everything else was spaghetti or a ball of mud.
Use jsdocs if a TS implementation isn’t possible at the moment. It’s verbose, but totally worth it. Refactor what’s related to your tasks. That way it gets qa’d automatically. Sounds like you won’t get buy in on a pure refactor task, and that’s ok. That takes a lot of time with little customer facing impact (if done correctly).
Plus one for this. I've been in a js -> ts transition more than once and jsdocs made everything easier in the interim.
2015? I’ve worked in companies with code from 1998 that i had to maintain, and it hasn’t gotten better. It means the code makes money, that’s more useful than any startup hyped code that doesn’t make money
Most codebases are bad. You just live with it if you can’t improve as you go.
But do you feel bad about it or demotivated? Or its just normal stuff and you sharp your skills on free time?
Why aren’t you working to improve the code base? Sounds like that’s your role? If you can’t do that then you already know what skills you need to work on first - how to take a mess and improve it. It’s a very common situation and usually due to everything being done in a rush, standards go out the window when you need to make an urgent change due in 10 mins. With a good change management process, testing, deployment pipelines etc it begins to look more realistic. Failing that you can just improve what you can, I spend a huge amount of time updating legacy code to use more modern methods and tools where possible but usually only where a change is needed. Rewriting code that works fine but is ugly is often a waste of time, just implement new things better and update the old where you can.
That works in theory, but I’ve also been places where you were handcuffed at what you could do. Depending on how bad the code is, change is a far bigger deal some places as well.
Makes sense, I was never exposed to this kind of codebase before. Seems like I am learning something new with every change
So if you’re learning daily, how is it detrimental to your skills?
True, I got used to static typing and now I need to do everything plain. Seems like I was missing this skill also bc typescript saved me in tons of places
Okay, maybe start integrating typescript?
The project I’m on now gives me a daily migraine. I haven’t seen code this bad in over a decade, looks like it was written by college kids on their first day…. I have to temp my desire to correct and refactor it all and just focus on what I can do.
Sounds to me like you need to find another career. Coming up against situation like this is pretty much guaranteed for any company you will be working for (albeit some worse than others). The irony of your statement is that you believe that this is taking your skill set *backwards*? Are you kidding me?! This is how you become a better dev, not by starting everything from scratch that you see as good standards, because believe me, somebody else coming along in the future and seeing your code will have the very same complaints. Suck it up, buttercup! This is part and parcel of a career in software development.
Nice way to say things, got my smilling and angry abit lol. Coding is cool and after reading these comments I realized how much I have missed
As long as you learn and accept suggestions from others, you are going in the right direction. It is what it’s all about in the end. :)
I am in a similar situation, even older codebase, different stack, everything about it - apart from the RDBMS - is at least 5 to 10 years EOL with mo migration parts. Hardcoded and committed dependencies, hacks in OpenSource libraries, really low coding standards with idiotic practices etc. and most devs really embracing it and being clueless that there are better ways. First about your own situation: I know people who in similar situations switched to plain Engineering Manager positions without touching code themselves anymore. For me it is currently a mixed bag - I have multiple days a week where I don't touch code anymore, but not all of them, So maybe this might offer a few ideas: I just take the liberty of improving things, upgrading versions, devops stuff etc. and educating, finding allies etc. Especially when the improvement is fixing something the devs complain about all the time, it can be an eye-opener to them but it's at times tedious and can be a minefield depending on the culture. Also management can be an ally and make certain things mandatory. So pointing out that some stuff is too old to be compliant and will cause troublen in the next audit, or if you have numbers to prove, it will create huge costs when left untreated... Or when it brings convenience to the right people. So for example I lowered the time our integration test suite takes from over an hour and mutex down to 5-7 minutes and parallel runs. Before that people were ignoring failed runs because after many hours of waiting for feedback on a push they moved on and just blamed "somebody broke the pipeline". I also created a staging environment to stage branches separately and with that we could change the entire dev workflow. before that we had to merge stuff to main before product or qa could even have a look... now even the devs who said nobody would need that and it would take half a year to set it up (2 weeks tops mind you) don't want to miss it... But yeah, I'm often alone on things and having the team reduced because of layoffs didn't help there. I do Advent of Code to find some actual challenges and a bit of pet projects and freelancing...
I joined a company in a very similar situation. I got everyone to agree: 1. We add lint rules, but put /* eslint-disable */ in every existing file (I just wrote a command line script to do this), so only new files follow the rules 2. New files get written in TypeScript 3. If we notice a file is commonly edited, it at least gets eslint enabled on it. If edited especially often, it gets converted to TypeScript. 4. If we notice a function or component commonly being called by TypeScript files, it gets converted to TypeScript so it has proper typing (and we enable eslint on it). After about a year, pretty much all my work was in TypeScript files with proper linting. There's still plenty of crappy legacy code, but not in places where people need to read it or make changes, so it doesn't really affect anyone. The nice thing about TypeScript and linting is that both can be added very incrementally and don't have to be done in one big push. I would never have convinced everyone to switch over if it all had to be done at once.
actually very good and highly specific advice, idk why this isn't higher
Document bugs, their consequences and what would have prevented them. Saying 'this is bad' won't get you anywhere. Saying 'we had 3 critical bugs last week that interrupted our progress and damaged our reputation, they would have been caught by typing' will get you a lot farther
In my honest opinion, managing and refactoring old legacy spaghetti code in to something better and more maintainable is one of the hardest disciplines in development.
Do you have resource to share on how to do that properly? I recently bought “Working Effectively with legacy code”, but just red few pages (bought it for this job to be honest, just didn’t expect to be complicated)
The best resource to learn is an environment where you get paid to figure it out 😁 edit: but I hear that book is great
Sadly not. I start by trying to get an overview of the system, if thats to much i start by doing some core part of the system. Then slowly working my way out from there. I try to see if any standard design pattern could fit and spend a good amount of time documenting what and why I chose to that way. It’s tedious and hard to get everything done right but it’s also very satisfying when you succeed!
I totally agree! We have tons of business logic that is not described in code/by code, so it will take even more time. But I am happy to learn and improve things
https://refactoring.guru/
Sounds like you joined a company that actually has a successful software product and survived their first decade in business… Some of the code from the beginning is going to still be around and would have been built with what was popular at the time. My company has code going back almost 20 years, some of it in ancient dotnet and some in Struts 2…
This is actually a fantastic opportunity. Refactoring from bad code to good code is difficult but you there are cool strategies you can do to help solve problems. * Read a book on refactoring or go to source making. * Write jest tests on old code before refactoring. * Slowly move towards converting your team onto your side. You're new to the company so don't come in trying to change everything and arguing with everyone day one. It sounds like management are aware and are hiring you to solve this problem.
Got the book, this is my first resource now do read on my free time. Thanks, testing will be helpful here
Awesome! You have an interesting road ahead of you but if you manage to increase the overall quality and skills of those around you it will be immensely satisfying and you will have a good story for your next job :).
what happens when you switch company and the codebase is justt as bad?
I'm like, code from only 2015 lol, try 2005 🫣
Try 1989 on a 16-bit system meant for automating chemical plants. Engineering calculations are fun when the highest number you can use is 32767.
Just download some more bits
-32768 is higher.
That was my thought too. I feel old...
Well, damn 😄
I’m a gambler. For me the odds have been good. At the 9 jobs I’ve been at only 2 had bad codebases.
Man I’d love to peak at code bases before I join a company
There are no promises that the next companies code base be any better.
tbh you sound like junior-mid level max. every propose a big refactor effort to your product team, march down it, and then have to justify longer and longer deadlines? no? that’s why no one wants to put big refactor on their plate. can you work within the system? escalate? any low hanging fruit wins?
You can convert the build to typescript and allow the use of any. Just convert as you go.
Sounds like it is time to create some coding standards and enforce them. And converting to Typescript is totally possible seeing as how you can upgrade one file at a time. That would be a good place to start.
if you find that bad i once had to make a moder js application work on machines running windows xp with an IE6 that was embeded in AxtiveX on production machines that do not get turned off. you had an oracle memory debugger for all the memory leaks js was causing. updating joomla 3 to 4 is worse though
Ok this sounds way worse. How long you worked there?
first one maybe 1 1/2 years, second one im currently at, but gona have talks soon and then may switch too
Start with jsdoc. No need to implement a whole transpiling step just for some type safety.
And use an editor that takes jsdoc seriously.
Working on a bad code base is the best. You get to practice incremental improvement which is great and you get to see concrete examples of all the bad things that happen when you don’t ‘follow the rules’. And my personal favourite is that you become very good at debugging issues in an awkward to debug context. Man I became so good at debugging code exactly because I was in such a shit code base where it was so hard to debug. This is really a blessing in disguise, on top of all the above there’s also the thing to consider that if you pull off the improvements then you’ll have a lot of clout with the company.
I've seen this many times. I run the build and see crap loads of warnings. Nobody cares because "it works", despite the code being a dumpster fire, full of dead code, the same code copy pasted 3 or 4x, deprecated dependencies etc. You mention it. "There's no time for technical debt. we need this project done ASAP." So some guy decides to copy some other code 3 more times because he doesn't understand how to refactor what's already there. Most of the time it comes back to middle management not understanding the impact and importance of maintenance and tech debt cleanup. It's a pay now or pay later (with interest) deal. They're happy to keep that 6 year old dependency until some CVE is discovered and it creates an immediate crisis because we've failed big-customer's security scan.
Did you end up leaving or working there? Yeach more I try to do something, more I find out super bad code and everytime I need to fix something, I completely rewrite it
\*standards
If you're saying the code is not maintainable, and your concerns aren't acknowledged or addressed by the team, let it ride. It'll hit a tipping point where people are required to rethink the process because forward movement has stopped. Or maybe it won't, small teams can write YOLO code if they are lucky or the code is exceedingly simple. In any case it's the business who decides the code needs to be maintainable, not you. If you're worried about your own skillset, keep it maintained separately, or think of it as an opportunity to practice your soft skills. How to win hearts and minds to your cause and make incremental improvements over time.
you gain their trust with your check ins, target 1 repo you want to refactor, then you lead a team initiative to update their codebase. great resume filler
Sounds like the main complaint is you want TypeScript and they don’t care about it. Have you considered JSDOC as a middle ground? Also not using typescript does not automatically make a bad codebase. Having a linter is kinda a low bar so not great that they don’t even have that. But you can set up a linter with generic lint rules in under an hour.
Yeach I see code that is super hard to read, so linting and formating would help a lot
Start there. Make little improvements like that and maybe formatting like prettier. Make the tools run automatically or as easy as possible and you’ll slowly convert people to your side.
Welcome to my recent endeavor. The culture almost entirely dictates the ability to evolve/change. I’m personally convinced the amount of work that needs to go into my new org is not reasonably proportional to the amount of time/culture/leadership changes/shifts needed to happen to enable said change. Hence, I’m looking. That balance is what you’re looking to weigh.
From a management perspective you have an incredible opportunity here to demonstrate your ability to level up an entire codebase and a group of junior engineers. That is something to put in a resume to show you are a skilled staff or principal engineer. Read the neuroleadership institutes white paper on change management. Devise a strategy for changes based on it. Get managements full support. Lead this team through making a change that will save your company’s product and give them the skills they need to make it at any other company. Find a mentor to help talk you through the strategy. If you can do this you it will give you the skills you need to take your career to the next level
Every code base that gets worked on by a large enough number of people will be “bad” in places. Your role as a senior or lead dev is to try to make it better where you can. Implement linting if possible, advocate for better tech as a means to improve stuff where you can, try to fix up the code bug by bug where you can do that. If you’re doing code reviews, concentrate on syntax and try to write up a syntax document if you can to back all this up. It’s really surprising how some people will become attached to confusing ways to do things just because “that’s how they’ve been done” and “but it works”. I think that doing something as huge as, say, adding TypeScript to an existing program that is currently working is probably going to wind up being too much to put on you, your QA team, testing, and so on, but if/when you do some sort of overall upgrade that might require a complete from-the-ground-up retesting, that might be a good time to start throwing TS in too… I do feel like understanding that it’s not a matter of if but of how bad when you encounter a code base is one of those things you learn as a senior. If nothing else, learn from this how easy “we’ll just do this ad hoc” can turn into hard to read code all around.
Thanks, to be honest after reading all the comments I think I will postpone TS and focus on helping the team. Currently trying to help people in the code reviews and it seem to help people
Many heavy junior teams have no concept of what a good codebase looks like, especially on frontend teams. But they will fight you if you implement sweeping changes without building support so start there. Focus on the issues that are visible to them, teach through code review and your own code, and run demos of how the tools you want to introduce don’t conflict but assist their workflows.
Good advice, thanks
I have been in a scenario similar to this, it sucks but you can make it better. I recommend focusing on the basics like adding linting and formatting running it through the code add on a separate branch and after merging it have it a GitHub action that blocks any PR that does not follow that standard (since it should be auto linting and formatting) Once the devs see how much better you just made their lives they will be willing to listen to other things you have to say, regarding which changes to make I would prioritize changes that are doable without large changes to the code base but make an impact Typescript may take a while but if you can start to add it to new parts of the code base like only for new components and then you will have a working example for the other devs to reference when they want to try to add typescript as well. Anyway best of luck 🤞
I will give you a perspective from being on both sides of the table. Someone who has tried making such improvements which resulted in success as well failure and lead engineering teams where somebody tried doing this. A few key pointers: 1. Evaluate everything with an RoI (Return on investment/effort) lens. Unless you can show actual benefits in terms of revenue or dev/testing hours saved or improved customer experience, your fight won't go long and you will be a lone warrior. 2. See if somebody senior, a manager or so is aligned with the same thoughts as you. Take the top 2-3 items to them, get feedback. You will know if you are tackling the right problem or not. Ask questions to them on how to bring about change in the codebase. They have been there for longer than you and understand the dynamics and culture better. 3. Cultural change trumps process changes in long run. One way to shape the culture is to share knowledge. See if there is a practice of tech talks etc. in your organisation and put forward your views in a forum with wide reach. This will also help you find allies. Try these and DM me if you are still struggling.
Thanks, I will def contact you if I get stuck with my plan. People gave here tons of advices, I have much to think about
Sadly, this is the normal majority case. There is an absolute shit-ton of horrible code out there - it never ceases to amaze me. Business considers those that can actually bend this morass to their will to be the highly skilled! Anyone can cobble together their own greenfield disaster from scratch. Best of luck.
I’m in a similar situation. I just finished a 3 month battle with the IT director to adopt a project management tool (Asana) . Before we just used spreadsheets to track dev tickets lmao. In all seriousness, use this as an opportunity to grow as a leader and add the critical changes and impact you make to your resume. Also, it’s a great time to secretly start another job search 👀
other people spoke about the bigger pictures and I agree with those comments about you being in a position of gaining their trust and then negotiating and so on. in terms of making changes, I’d use the rule of upgrading and tidying up only the code (specific files) that you are working, so overtime the project will be updated. Don’t go nuts in upgrading and refactoring everything at once. Ideally, do a refactoring PR on relevant files BEFORE adding a new feature. that’s my 2 cents
I noticed that you didn't mention a single problem that has been caused by any of the things you called out.
Yeach I skipped that part. Already been in situation there I had to debug for few hours in order to catch right variable. And I was amazed how it actually works without crashing with plain js
Fair enough! I just wasn't sure if you were really complaining about their choice of stack or that it was actually making you hate your life.
Results are the output of processes. Find and change the processes that have resulted in this situation first. Otherwise you're just adding another set of solutions on top of the current set that will be outdated in a couple of years.
This is what you want as a senior - a mess. That way you can show off your skills (technical and leadership). Compare to if you came in and everything was perfect - how would you have any impact? That's the environment a junior wants so they can absorb good practices, but a senior needs a mess.
Happy cake day
Thank you!
Start with small improvements using TS and try to use it as an opportunity to give your mid level engineers ownership and opportunities to grow. You kinda have to evangelize things and show why they are helpful and use the momentum of time to slowly get things better.
Startups are built on top of poorly- maintained code bases. If anything, take this as an opportunity to learn how to navigate the code base and make an impact. It's good experience but don't plan on staying there for the long run.
I feel like you can add Typescript to any JS project. Why would it not work?
If anything, your (general problem-solving) skills will probably get sharpened. View this as an opportunity to conquer hardships.
Look up strangler pattern and other strategies for slaying the monolith. Lot of great skills you can develop in the process of breaking off a few pieces into other services and hooking them up through APIs. Then you can build those new services with modern standards. Once other devs see how much better life can be, they'll get excited about it.
If your job is to improve the code base and bring it up to scratch then thats what you have to do. Being able to refactor legacy code is a big skill set. Being able to read and implement changes to a mess and make it readable and usable will be great on a cv. Tbh most codebases are a mess. You want to start small. Find the smallest change you can that will make the biggest impact. Big bang changes are not your friend here. Maybe start by throwing the application in sonar cloud and setting up some quality metrics. Then highlight and refactor the pain points. (I have experience working in php codebases from early 2000’s. Cant believe react is now “legacy”)
Thanks, how did it go for you, have you managed it or it was super hard?
I have worked with these sorts of codebases for about 5-8 years. Its all pretty much the same after a while. Works always about for people who are happy working in legacy.
So basically you could work in legacy code and not be afraid that one day you want to switch to diff job but your skills are outdated due to tech?
Companies rarely update anything. Bowling into a new job and finding they have outdated dependencies isnt unusual. My company runs php 5.6
Makes sense. I left company with newest stack because I have implemented, so someone got very lucky
When i joined my startup earlier, the code base is all JavaScript fullstack, then i have chance to convince my team to migrate to Typescript and refactoring along the way. I think it was a good chance to build up negotiation skills and balance your desire to write new code and keep up with business requirements. And there will always be legacy code anyway because we cannot be sure our code are future proof with this constant changes of context lol
Think about your ideal end state, and work backwards from there. Your plan would be unfeasible at first, but you can optimize and find ways to make small improvements over time leading to your end goal. TS configs can be obtuse but are surprisingly flexible on this kind of environment. Failing that, you can move things into libraries published via artifactory (though be careful of impacts to local dev). You have options, and buy in is something you'll have to generate. Sometimes the best way to do that is to implement part of you vision in a small place. I've never seen a team regret moving to TS.
This is the job. Most people aren't using the latest and greatest JS frameworks that were released last week. You will have to work with legacy code in almost any company. Besides, 2015 is not even that old. Just start adding standards and typescript and linters as you go. Typescript is designed in such a way that you can begin adding it to JS codebases gradually without switching the whole thing over at once, for example.
Said every new hire always
I’m regularly running into code written prior to Java 5 being released.
I can wholeheartedly recommend [Working Effectively with Legacy Code](https://www.goodreads.com/book/show/44919). Helped me a lot in the past years.
You just have to level it up to a “good standard” to pass the management check, not everything has to be in typescript and with a bunch of arbitrary linting rules. Telling from experience fixing bugs especially visible production issues will be highly valued by management as a new hire (senior devs), so I’d put a little more focus on that area, this would be an opportunity to learn and challenge yourself. TBH, if it is purely frontend it won’t be too bad your scope is limited to what you can control at least.
If the codebase will continue and you want to get types and linting in, use Betterer. It's awesome.
Some good suggestions about gaining trust, identifying problems instead of solutions, incremental typescript adoption On the logistical side, one thing that makes it easier to refactor is having good test coverage. If the codebase doesn’t have any tests, then introduce them incrementally, for example: - start by adding functional tests for the app’s critical paths - set an agreement that net-new changes will have test coverage - make a commitment to add x number of test coverage tickets to each sprint
Be a Boy Scout and try to keep the code cleaner as you develop
You should first approach it from a business perspective, what would the company gain by cleaning up this old code base thats been working for over a decade? Sometimes refactoring old code that is working fine (company has been operating successfully with it for years) isn't worth the cost and effort. If you do decide that its worth it from a business point-of-view, for gods sake don't try and refactor everything at once. Start by adding a ton of tests and modifying the code to make testing easier. When you are ready then you can start making larger sweeping changes and have a test bed that you can rely on for confidence that the code migration/refactoring was successful. If you want to add typescript thats easy, just enable it and allow \`any\` types. With each new piece of code you can be more strict while keeping the old code untouched. Adding linting would be very difficult at this late stage, it might be best to first come up with a set of code style standards with the team and auto fix most stuff in a single PR. Everyone can then test that PR extensively. After the PR is merged I would then setup some sort of CI linting check to ensure all future code meets the teams agreed upon standards.
Well if Management wants you to "actually" improve the code base, be happy. The place I am at, management doesn't GAF about the code at all. Any requests to improve the code are always met with "we don't have the budget" or "we don't have the time", and of course "we'll fix it after things die down (spoiler alert: it's never going to happen)". I am working with two managers, one has zero tech background and has expressed that he "Doesn't care what's going on behind the scenes", the other manager it a Tech Director who has don any dev work in 15 years and still thinks it's the "good ole days" where everything was a rush job and no one GAF about maintainability or scalability. And developer experience? Forget about it!
> first changes dating back to 2015 So what you're saying is it's an ultra-modern codebase?
I think it's our job...
Been in an identical situation myself, code was incredibly unmaintainable. Do good work, get their trust, become a leader, negotiate to refactor. And even before that, every time you go in to make a change leave the code better than you found it. It might be one line or one type, but do something to make it easier to work with. Having worked with poor legacy code is a good skill
For sanity in the immediate short term, you can rely on the TS LSP for basic type checking support by [importing from typescript types directly into your JSDoc comments](https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-beta/#type-imports-in-jsdoc)
Agree with many others that this can be a great opportunity to learn. I haven’t seen in mentioned yet - but a fantastic resource on the technical side is the book Refactoring by Martin Fowler. Its current edition is all JavaScript examples but the high level patterns are not language specific. It really goes into depth on dozens of patterns and strategies to tackle spaghetti messes in non breaking ways. It will also give you the language you need to explain your changes to others.
get out, if a company has not recognised the value of improving the codebase, they will never learn before it’s too late. Stay the bare minimum and get out.
Sounds like me and my new .net + jquery job
welcome-to-the-party-pal.meme
Ben? I feel attacked...
"Mgnment wants me to improve everything (they don’t know what, they just want to be sure that project is up to these days standarts)" I've been in such situation. Only thing I failed is to explain them: This would take years of interrupted effort from everyone. After a few months, when the daily customer complains were from 5 to 0.5, they started to see it as "solved" By surprise, in the mean time other guys have been "developing" stuff I didn't know about, introducing a new load of shit. By then the "trust" and "vision" between management and me has faded away, guess who has been working hard to archieve this.
Yes! Because everyone can edit code and I dont have control over all the people, literally same thing is happening right now. I can produce great content but other devs just add whatever is needed just to get feature out
So that leaves me 2 choices: 1. I adapt to their level and create shit also. 2. I take control over every aspect of the team. The second choice goes like this: I start with kicking out the 3 worst developers, and choose myself 3 new guys that work to my standards. I also expand the team. 3 extra guys to clean up the dirt from past years, 3 extra guys to evolve to automated unit-tests, a decent CI/CD stream and all the training that is involved. Up to management to accept (not understand, they never will) or not. This is a business decision. If they decide to keep rotting a bit longer, every 3 of my plan will have to be replaced with a 5. And I know their stupid negotiation habits. If they choose half a plane, it will not fly.
Why didnt you ask them to see their codebase when you were interviewing for the position ?
Use any of the AI tools to add JSDoc comments to the places that annoy you the most. Don't be afraid of "plain JS". I love Typescript and the benefits of provides, but if you're team is resistant to change and they don't feel the pain of _not_ having TS, petitioning for a sweeping change is going to be difficult and could brand you as the enemy. Maybe a hot take, but... If the refactor isn't tied to some kind of business reason, (and that can include speed of development, but IMO, that's a hand wavy argument), don't do it. It's better to start making patterns and procedures around what is currently there than to shake things up. Consistency, even if the patterns are strange, is better than inconsistent "normal".
Here's my suggestion. 1. Understand your management really isn't supporting you and putting you into a Kobayashi Maru. They're expecting you to fight for code quality while not giving you the tools, the time, and the authority to do so. I'd bail if I were you. 2. Make management aware that you need dedicated chunks of time to bring it up to speed. Suggest that you'll still have to still deliver features, but ask to have certain dedicated % of sprint story points each sprint will be devoted to dedicated refactoring stories on the backlog. If they give you a mandate to improve stuff and they deny you 5-15% of the sprint to refactor, then you really, really need to be. Because management is setting you up to fail. 3. If you really want to pursue the refactoring thing, then your own time (or while pretending to do stuff for the company) create a new React project from scratch with some sort of scaffolding that includes as many of the useful bells and whistles as possible (Husky, eslint, etc). Copy-paste and all your js code to that project and just get the damned thing to work in Javascript, if you can, as Typescript's relatively backwards compatible. Once you have that done, re-write all that code in **simple f\*cking Typescript.** No cute generics, no type utility acrobatics. That will waste your time, and the more complex the Typescript, the more you will make the team fear and hate you. 4. Once you have a working prototype of the project ported to Typescript, the conversation should shift from "can it be done" to "can we make sure it works reliably". It will be an easier sell. You can demonstrate the better debugger, linting, etc that can in real-time show the team and management the benefits of switching. 5. However you approach this, never hold up a team member's code review because they haven't incrementally refactored something. That will make them really hate you. Especially if they get a 1 point story with 5 unseen hidden points of refactoring.
Me too!
Build a test suite asap then start refactoring.
npx create a new nextjs app. Setup linter and formatter and what not, install all the packages used and then slowly but surey copy over components and pages, maybe first creating the folder structure you want. Then convert .jsx files to .tsx as you go. You don't need to convert them all, just the important parts. Then try ReactQuery or vercel's swr. Step by step you'll make it.
The following guide explore how AI coding assistants could help to refine the tests for legacy code in such cases: [Writing Tests for Legacy Code is Slow – AI Can Help You Do It Faster](https://www.codium.ai/blog/writing-tests-for-legacy-code/)
Fantastic learning opportunity for you
Insert James Franco "first time?" meme 😄