Ask HN: I got duped into working on legacy code, should I leave?
Its legacy code dating back more than 20 years. I'm afraid that my skills will rot if I stay too long. The code quality is also horrible and its making me hate coding.
The company talks about how we're just around the corner transitioning to newer stuff. After talking to some veterans, apparently it's been "right around the corner" for years.
I was hired for my React and Typescript skills/interest and it's been months with no signs of being able to use them. I'm not good with their current stack but I have no interest in learning it because its so obsolete. I'm beginning to think that they mislead new employees because otherwise they would ask for a lot more money or walk away.
I'm torn about my best course of action. I'm not good at my job because I don't know their tech. I'm not good with their tech because I hate it and I'm bitter that I was lied to. I can't mentally force myself to learn this ancient shit. On the other hand, they're paying me, so I owe them something right?
The best solution for me is definitely to just get a job somewhere else, but I've only been at my current job for a few months. Should I just stick it out and hope I don't get fired for underperforming?
125 comments
[ 5.7 ms ] story [ 270 ms ] threadLike another person said, there are people who enjoy modernizing codebases (I sometimes do myself), but if you are hating your job, do everyone a favor and make a change.
You should probably start with your manager, and explain why you are considering leaving.
Chalk it all up to career learning... Try not to get too personally invested or discouraged.
I'm amazed the code works at all. The stack traces are more than twenty deep sometimes. I can't stand to look at it for more than 20 minutes without a break.
I need to be more careful next time I'm looking for a job
Haven't counted but I think this is totally not unusual when I work on Java which I consider a modern stack.
The overarching problem is trying to reinvent the wheel because the management thinks we can do things better than the language designers.
The end result is a buggy and generally bad reimplementation of core libraries. ORM, math, dates, full text search. There's a half-baked custom version of everything.
Only noobs like myself years ago would go ahead and refactor a lot of code during work hours without a good reason.
However when you stumble through something and finally understand the idea behind it (good or bad) then it might be a good time to add a couple of tests.
And when you have a few tests that covers nearby code you can hopefully find the courage to make a few surgical cuts to remove the worst tumors. ;-)
Also consider that "the fastest way which is usually a bad hack" is sometime the correct pragmatic approach for a legacy codebase that's in the process of being replaced. Giving them the benefit of the doubt, think about whether the elegant design is really necessary if there's a ground-up rewrite about to happen.
Even if it's demonstrably true that they've been "claiming" a rewrite is "just about to start" for a _long_ time, sometime's that's just as frustrating a thing for management as it os for the coders - management may well honestly have always believed this rewrite was supposed to have started 12-18 months ago, and that it genuinely is only weeks away from starting... Just like they believed last month and six months ago... I've _been_ "that manager" before (and I'm sure I will be again).
And why do you agree?
One of the differences between professionals and other workers is that professionals are experts in how to do their work. If I tell my doctor to just write me a prescription because I said so, she'll just scoff. I can make requests, but she decides what will happen and how.
Especially if you're already likely to quit this job, then you don't have much to lose by insisting on using best practices. Sure, you have to honor their desire to do things reasonably quickly. But you don't have to keep digging the hole deeper if you feel it is professionally negligent to do so.
When you or I break our collar bone, the doctor will immobilise it in a sling for 4-8 weeks while it heals.
If you're chasing a motorcycle world championship though, they'll go in and screw it back together with titanium support and get you back to top-level performance in 2 days: http://www.autosport.com/news/report.php/id/108388
Sometimes you need to cut your code open, jam in some temporary scaffolding or duct tape, then stitch it back closed again - promising yourself you'll go back in and take the kludged fix back out when deadlines and circumstances are less critical...
This person is in a place where they have spent years piling kludge on kludge. They never go back and fix anything, which is why they have such a mess. And here there was no emergency mentioned; he was describing their normal practice. It's duct tape all the way down.
At some point you have to draw the line and say, "No, from now on, we'll treat normal circumstances like normal circumstances, and save the duct tape for real emergencies." I am suggesting he start drawing the line. Either they'll give in or they'll negotiate his exit, and either outcome is good for him. As the Agile people say, "Either change your organization or change your organization."
Then he would critique it to exactly what he wanted me to know about what I should have gotten out of the meeting. I'd say I spent about 3 or 4 hours a day coding and the other 4 was pretty much dedicated to putting up with his antics. Every time he would come bother me, I'd lose my focus and spend 10 or 20 minutes just trying to get into that mindset again.
You can read more about that experience here if you are interested: http://www.confessionsoftheprofessions.com/the-opportunity/
Long story short: I ended up applying to other jobs because with $40k of student loan debt and being paid $12/hr, I just wasn't ever going to move out of my mom's house. When I told him I was going to be getting another job, he offered me double my salary to stay. I thought about it and knew that he was going to hold it against me for everything.
Towards the end of my time working there, he did give me a raise for what would last a week and allowed me to work nights, so I could work in silence, as a way to try and lure me to stay and give me the "experience" of making $24/hr. Unfortunately, he also installed spy software on my computer, and questioned me about why I was on YouTube all night (I had a playlist in the background) instead of doing my job. After that, I pretty much told him it wasn't going to work out because of his mistrust of me, and I cut my final 2 weeks short.
Anyways, I ended up getting another job and this one too -- I worked on a "cold client base" that was at least 2 years old -- basically, the company sold contracts in advance and never delivered, so I was hired to help them catch up. Managed to take their "cold client base" from about 140 accounts all the way down to about 32 accounts remaining. It involved some software and collecting data. We worked in Flash. Other companies were working in HTML5.
We had an in-house programmer working on an HTML5-based platform and it was amazing. Unfortunately, I got laid off before I got to learn the new program, but apparently, after 6 months, so did everyone else and the company went out of business. Had they just released that program and pushed it, I'm pretty sure they would have been able to stay in business, but such is life.
I currently work as a web developer for a large media corporation. No regrets and I've definitely earned my salary and raises over the years. If you aren't feeling it anymore, than start looking for a new job and go for it. You have programming knowledge so it is likely you can get a job in many different places. When you go, they'll probably find someone else. We're all replaceable, for the most part.
Go do something you enjoy and get paid to do it. No sense in wasting your life away not doing something you don't really enjoy.
Did they pay for your relocation expenses? If so, is there a clause in your employment contract to pay it back if you leave within a given period of time?
Do you want to stay in your new city?
If you are unhappy enough to leave, then why not bail up the manager who hired you, tell them point-blank that they lied to you and you know that the "round the corner" talk is just window dressing. Demand more money for your pain, etc. You should only do this if you are willing to get fired on the spot. But it is what I would do.
Immediately start looking for a new job. I would not put this one on my CV. Just mark the time as time-off to do a bit of travelling and relocating to your great new city and now that you have settled in, you are looking for work.
Don't worry about it being shitty legacy stuff. I have even worked on mainframe Cobol for a while and although I hated it, I ended up learning about a new industry and then getting a job with one of their competitors. Every silver lining has a cloud.
I was thinking I could just apply to other places and be honest with them... But some may also frown upon me saying bad things about my current employer
I'll transcribe your voicemail, I'll answer emails, whatever.
I won't let you down.
I'd be looking for some insinuation that you gave it an honest effort and tried to work with your previous company to make it better, but in the end if you got hired for a certain role or stack and it was clearly not what you were going to be doing there's no fault (in my opinion) in you being dissatisfied.
There are certainly times when people can come across as chasing only the shiny and new tech, which is a bit of a turnoff if I'm trying to build a product, but not a deal breaker either. I don't feel like this is the kind of situation that would make me feel that, you weren't getting what you signed up for.
If a prospective new employer already has concerns about employee retention or that they're also overpromising on their stack, they may pass on you- but I think we'd agree that would be best for everyone in that case.
I would also make it a point to let your manager know, as well as HR during your exit interview, how you felt you got bait and switched. It's entirely possible it was unintentional- in which case they could use it as a way to improve and clarify how they're positioning the role. Or, if they're actually lying about it and already know- they won't really care, but it could put the manager or team on notice with someone who does to get their shit straightened out. It might be a long shot, but it might make it better for the next person.
Do they still do those these days? The places I've left never bothered.
This. One of my specialities is unpicking and debugging legacy code bases, often 20+ year old mud balls. It isn't glamorous work, but you do get a few decent war stories out of it to recall in the pub.
My preference is to hire devs who've put in the hours in these environments. I see it as something of a right of passage and indicates to me you've got the experience and self-assurance to work with these gnarly and often fragile code bases (hopefully) without breaking it, fixing bugs and generally trying to make it better.
I'm not suggesting you make a career out of this, though it can be lucrative, but a year or so doing this kind of work does no harm to your CV/resume in my eyes.
[0] https://www.snellman.net/blog/archive/2015-09-01-the-most-ob...
The webforms stuff isn't much better because the code quality is the worst I've ever seen. Adding features and fixing bugs is a stochastic process because you never know what will break.
Usually fixing a bug will expose an old fix that was done improperly for the original even older bug, forcing you to undo multiple levels of hacks to implement your own. It's nightmarish
Legacy codebases suck, but it doesn't stop newer codebases from sucking just as much. I've learnt that the hard way.
It's the culture more than the tech that causes this to happen. Every time I offer to refactor I'm told to fix it the fastest way and that's how we've been doing it for 10+years.
Ok, as someone with a strong dislike for modern js I still feel sorry about this.
Get yourself into the right mindset for interviewing and demoing your side projects, line up some interviews, and go. When you've got an offer on the table, make the jump.
Alternatively, if you have several months of living expenses as a cushion in the bank, you could find some freelance clients and then quit.
Focus on the future, stay hopeful, and get out of there. If it's only been a few months, consider not even listing this job on your resume.
According to OP this company has been around for 10+ years. It'd be a miracle if they didn't have legacy code.
After working in this business I don't think I'll ever be able to return to a "normal" type of business, although stress can be quite high and often there is overtime to meet a deadline.
2. I don't necessarily agree with the premise, he's not looking for a greenfields project, he's looking to use the toolset he was sold on during the interview process. There's plenty of established companies that have moved from xyz -> React in the past year or so.
This seems a classic case of being either deceptive or self-deluded from the interviewing side, with classic results. Its foolish, it rarely results in good things, and it's a huge waste of time for everyone when interviewers are not straightforward with candidates. Don't do it, and I would not feel bad for a second leaving a place that pulled that.
You make a mistake by taking the job but what is done is done. Now you know what questions to ask in interviews to make sure this never happens again. So, if you are unhappy put in the hours you are paid for and start looking. Thats the only way to get another job and change your situation. When you find an offer you like put in your notice and say thank you for the opportunity and keep it professional. Don't tell your boss that you're going to quit ahead of time, thats a great way to get fired because they wont want to train you anymore.
Some folks might say "no way dude, they'll can you" but I doubt it. I think most bosses would appreciate the honesty. And if they do you wrong, you still have your integrity and that's better than one more paycheck.
What kind of passive language and thinking is that?
Everything is legacy once it is written.
Imagine you, the trailblazer, only having to write new code and not having to maintain the crap you wrote.
The actual problem here is your attitude and way of seeing things. Legacy? Sucks?
Fucking write a better version and show some initiative instead of just hoping of being granted the opportunity to work on "new shit".
Millenials these days.
The code isn't just old, it's very badly written and has zero documentation.
- Says everyone
Now you learned 2 valuable lessons:
- There's a lot of shitty code that you sometimes have to deal with
- Never put yourself into a state of dependency on a single income source, unless you wish to have the emotions you are feeling now
Start documenting those requirements and create a plan to map those to technologies that you prefer. Understanding how to successfully migrate platforms is a learned skill, and it's going to become useful again when React is no longer en vogue.
Also, OP's story is currently colored by how upset he is so I'm sure the interviewers made the job sound more appealing than necessary but I'm sure there is also some revisionist history happening.
This applies particularly to aspirational projects that a company "wants" to start. It hits a chicken-and-egg problem of that it needs to hire skills for that project, but can't start on that project until it hires those skills, many people don't want to be hired unless that project is already off the ground, and in the meantime existing projects still need to be maintained...
Certainly it would have been better for the interviewers to more accurately describe how aspirational their goals and not imply that things were more off the ground than they were. It's a bad way to start a relationship by selling goals as reality. It's also a sadly common way for companies to start relationships.
If you want to try to contribute change, figure out what the roadblocks are to that aspirational project. See if you can find ways to apply your skills to the aspirational project. Sometimes companies forget the bootstrap step in that chicken/egg problem and forget to check if they've added enough resources to start pitching into the new work. Goals continue to be delayed because the company is uncertain and being deliberately conservative about if it has the resources it needs to meet its goals.
Sometimes an aspirational project is looking for a leader to step up, someone with enough passion about the future to get the work started and get prototypes out the door. There's a possibility that can be you, if want to apply for that pressure/responsibility. There's a possibility that in hiring you your managers hope it might be you.
As much as anything, there's a chance here to introspect and figure out if it can be you. Figure out if you can make that pressure/responsibility work for you, if you can make the work/life balance you need, if you can find a way to balance work's existing responsibilities on you (help maintain current systems) with potential new responsibilities (help lead new project). In some companies you might be very well rewarded if you can strike that balance, if you can lead the company onward to meet its goals while helping it survive with its existing needs. It's up to you to assess if the rewards are worth the risks. Your company might be one of the very many that aren't that loyal to its employees and you would be better off elsewhere, but that's something you probably need to judge for yourself.
I guess I'm rambling, but there are ways to make your situation work, if you are looking for them. It's as much on you to discover if you have that capability as it is for the company to solve its own paths to its goals. Starting that conversation with a lie of omission might be an indication of bad faith and disloyalty from the company immediately off the bat... or it might be a sign from the company that it really wants someone/anyone, and that someone could be you, to step up to bat and try to knock something/anything over the plate. It's rare that a company wants a new hire to strike out. Maybe if you can hit a home run you might be rewarded for it, and it might be worth swinging for the fences. Have the conversations you need to figure out if it's worth the pain of swinging for the fences versus playing it safe and bunting until you get the next job offer.
Yes, you can step away, in the figurative and literal sense. In many possible worlds this may even be the best plan, if you have no real agency over the code. And you got lied to. It'd hardly be the first time someone has been convinced that the work would be cooler than it is.
But -- you also have to decide if this is an opportunity in disguise. Stories of folks who gradually build ownership over the creaky "legacy" codebase and polish it up with Sisyphean refactoring, until it shames the "rewrite", are out there, and they're real.
On the other hand, fixing the legacy code may be one of the hardest things you can do in software architecture. There's no sense of joyous freedom to it, just correcting of old mistakes. But if you did that, and published documentation to evidence what you did and how, lots of folks would want you - and not necessarily for the task of fixing their own crusty code.
So there is an opportunity here, if you can find a way to sneak it through the management, which has surely decided on the balance sheet that the code is a "deprecated asset" and will not want to hear about new ideas. In fact, to maintain it you don't want to present anything as a "new" - you have the much harder task of justifying every small change as an opportunity to improve the debuggability - to get the callstack down from 20 deep to 19 deep, to remove a superfluous parameter, to improve turnaround times, to reduce the code size by a few lines, or something similarly miniscule, but which might add up over time into real understanding.
Never seen it in practice. Is this a real thing?
If it's not that you guess is as good as mine :)