Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: I got duped into working on legacy code, should I leave?
62 points by throwawaysbdi on Mar 20, 2017 | hide | past | web | favorite | 119 comments
I recently moved cross country to work on what was supposed to be a fairly nice, new stack. I love my new city but the job is killing me.

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?




I worked on legacy code in my initial years. And when I say legacy, it was truly legacy. COBOL/JCL/REXX on a mainframe.

I now develop web apps using NodeJS and occasionally build UI using Angular and get to evaluate some of the "shiny-est", "cutting-edge" code/frameworks.

Do I think I wasted my initial years? NO. I worked on side projects which eventually helped me move to the tech I've always wanted to work on.

Did I do a shitty job on the legacy code? NO. On the contrary, I won many accolades for automating several processes and improving the performance.

Did I learn anything from working on legacy code? YES. A lot. I believe the experience of working on legacy code made me a much better developer.

Why do I think so? Working on legacy code means you READ more code than you WRITE. I am of the opinion that there are 2 things that are very difficult in software :

1. Reading code written by others. 2. Writing code that can be easily read by others.

Coding is one-time read, many-time read activity.

So, my advise - work on the code, stay in touch with what you like, but move if it's really bad. (No point in doing what you don't enjoy doing).

Just remember, the code that you write today will become legacy code one day. :)

P.S.: Also, beware of taking advice from a comment from a stranger on the Internet. :)


Such an excellent post and advice. Working with legacy code makes you learn mistakes of your predecessors, and not to make them in the future.


That is excellent advise sterex!


I find it impossible to replace a legacy system without first understanding the legacy system. It's easy to say "X is old" or "X sucks at Y" but keep in mind that applications have a strong survivor bias. Ask yourself, "what does X do that is awesome" or "how has X lived this long" and you'll find a lot of hidden scars and requirements.

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.


Yes. Thats what the college-lecturer tells you. But in the real world you should not stay longer than necessary in a company which lied so hard into your face.


Always several sides to a story and during interviews everyone is on their best behavior. I have yet to be in an interview where I get the full and complete picture without any embellishments. It's only after you have been on the ground floor for a few months that you see things for what they are.

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.


It was a lie of omission but I'm not sure if that makes it any better. I was hired to work on a new project but it wasn't disclosed that the project hadn't been started yet and has already been delayed for years


Sounds like said project will never be started. Your employer is probably coasting on a thing they have done once and were successful with.


To some extent hiring is always aspirational: a reason a company wants to add more people is to get better at skills it thinks it lacks.

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.


Couple of questions to focus your decision making:

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.


> Don't worry about it being shitty legacy stuff.

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.


Agreed! Seeing it done wrong provides lessons in how to do it right. Probably one of reasons why we read DailyWtf.com.


Relo isn't a problem and I definitely want to stay in this town. I can't really mark it as time off because I already did that a while back, I don't want to end up with a lot of gaps :)

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


As a hiring manager, if you tell me the reason you left after such a short time was as you describe in this post, I would have no real issues with it.

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.


>I would also make it a point to let your manager know, as well as HR during your exit interview

Do they still do those these days? The places I've left never bothered.


Not necessarily. If you haven't been there for long (and it's not on your resume) it might not even be necessary to mention them directly. It could take a bit of linguistic technique, but if you frame things in such a way that describes what role you were hired for and what role you were given, I don't think anyone could fault you for being dissatisfied.


I'm looking for a React guy. Remote work is fine as long as you're on USA timezone.


What about remote that will work USA time zone hours? (I work serious question. Considering doing remote next year and wondered if people consider that cos I work better at night time anyway.)


How about someone with no accredited skills or accomplishments?

I'll transcribe your voicemail, I'll answer emails, whatever.

I won't let you down.


All code is legacy code. Use it as a proving ground for learning how to deal with legacy code. Otherwise you will always be bitter and upset no matter where you go. The only way to work on greenfield projects is to start something from scratch on your own.


1. There's shades of legacy code, 20 years of rot is way different than 5 years. There's also different states of legacy code, and it sounds like this is not in the good state. So being sold on one universe where the real universe is so far off, that's a special case of embitterment that's maybe more justified than lesser lies.

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.


No, no.


No, no what? Do you have counterexamples where established businesses don't have to deal or interface with legacy code? If so I want to work at this magical enterprise.

According to OP this company has been around for 10+ years. It'd be a miracle if they didn't have legacy code.


Agency work, for one.


Really? Which agency is that?


Ad agency business (not adtech). I work for a digital production agency that caters to ad agencies, doing digital campaigns (vr, mobile games/apps, websites, webgl, anything digital really). My time on a project (code, frontend) rarely exceeds 2 months, and after that I get a fresh new project to work on from scratch. I rarely work with legacy code and usually the tech stack for these projects are quite cutting edge, too.

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.


I actually enjoy working on legacy code and improving it. I'm not suggesting you should enjoy it, it's just there's all kinds of engineers. The company should be hiring someone who does enjoy that sort of thing, and I suggest you look for another job that is closer to things you enjoy doing.


I've been in a similar situation once [0], though it was really my own fault rather than being duped. Quitting fairly soon (after 7 months, IIRC) was definitely the right thing to do. I did it without arranging for a new job first, which was probably not the smart thing to do.

[0] https://www.snellman.net/blog/archive/2015-09-01-the-most-ob...


My first thought when I read the title was "no, don't leave. Working on legacy code will teach you the number one thing about programming, that no one else will teach you... Writing good code is about writing maintainable code." It is hard to fix hacky code, but do your best to not write hacky code. Another lesson to learn... To ahead and learn more about the attack they are using. Yes, you may never use that attack again, but it will actually make it easier to learn a new stack later on. 20 years is really not all that ancient either. JavaScript is over 20 years old... It might help you to learn some of the older technologies. Now, that being said, I don't know the extent you were promised to work on new things, and how much you were lied to and how bad the culture is.

I suggest you start looking for a new job, but in the meantime work hard on your current job. Take pride in your work. No matter where you go there will always be a legacy system you will have to work with. New or different technologies to learn.


I think the basic truth to work off of here is: "Shit got real."

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.


> 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.

Never seen it in practice. Is this a real thing?


Put in an amount of effort that you consider professional at work (by which I mean, put in enough effort that you're proud of yourself, even if you're less productive than you'd consider ideal for someone specialising in what they need). Use React on side projects. Look for better opportunities, and be more picky and curious about the actual work you'll be doing. You owe them no more loyalty or accommodation than they've shown you by misleadingly recruiting you.

Chalk it all up to career learning... Try not to get too personally invested or discouraged.


It's difficult to be proud of anything I'm doing :). Whenever I propose a design for something, I'm told to do it the fastest way which is usually a bad hack.

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


Not "proud of what you're doing", but "proud of how you're conducting yourself". Make sure you can walk out at 5pm holding your head high thinking "All things considered, I gave them good value for what they paid me today".

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).


Below link helped me to carry on while I was still there: https://www.joelonsoftware.com/2001/12/25/getting-things-don...


> Whenever I propose a design for something, I'm told to do it the fastest way which is usually a bad hack.

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.


Even doctors understand that sometimes it's necessary to meet unrealistic deadline by doing quick and dirty hacks.

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...


You write this like I don't know that. I of course do, because like most people here I have written a lot of production code.

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."


The stack traces are more than twenty deep sometimes.

Haven't counted but I think this is totally not unusual when I work on Java which I consider a modern stack.


I should clarify that's over 20 deep of our code , not counting all the framework stuff.


The depth of the stack is not a very good metric for code quality.


Why is everyone quibbling with him about that. He just wants to express his opinion that the codebase is very bad in a more colorful way than by simply calling it doubleplusbad. Let's just take his word for it and move on.


Because we are trying to tell OP in a nice way something we think he will benefit a mot from rather than just what he seems to be wanting?


It's bad in a lot of specific ways but I'm trying not to out myself since it's a fairly small company.

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.


Add regression tests, replace with your own code. or quit.


That's the worst thing to do: doesn't provide any value at the part that matters. It may worth to improve code quality where it matters (the business logic), but to improve it where it doesn't matter is a waste of time to both the employee and the employer


I would think this was implied:

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. ;-)


Welcome to the real world. If you want to write elegant code using the tools of your choice I suggest building your own product or service on your time. The business NEVER cares about tools, languages, or best practices. Expecting the business to value this stuff will cause you to burn out and be unhappy. They employ you to add value. So add value.


The problem is the business thinking he is buying value when he's really getting in debt.


Quit... Have been through this. If it you cannot apply anything you learn in this company in your next jobs, it's a waste of your time.


Tough place to be in, and it sounds like you need to extract yourself as quickly as you can mindfully do so.

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.


I'd go to your boss and respectfully say what you've said here regarding your interview and intentions. "Sir/ma'am I was hired to do job X and I find myself doing job Y. Is job X still a realistic goal here? If so, when do I start? [a date should be the response]. If not, I'll start looking for job X. I don't want to burn the company, so I'll continue to work hard here until I find the job, and I'll keep you posted on the progress."

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.


Leave.

The bottom line is that you're unhappy with your job and there are plenty of shops where you can use the technologies you love.

You're under no obligation to stay - your employer is not your family. You're in a contractual relationship where you exchange your time for money.


Walk away, please. It's clear that you hate your job. Do it now before you regret it anymore.


My expenses are too high to walk away and there's nothing I can do about it for a couple years. Otherwise I would have walked out several times over.


Talk openly about the specific issue with your boss. Tell him/her exactly how much time you give them (3 month is a okayisch thing) to improve on it or you will leave based on that issue.

Offer them a way of migrating to your stack like 'hey we can migrate this peace and this peace to typescript' Its an easy start, low risk.

If they don't care, or don't change, leave.


>Tell him/her exactly how much time you give them (3 month is a okayisch thing) to improve on it or you will leave based on that issue.

This seems like pretty terrible advice. You seem to be assuming that the OP is independently wealthy and doesn't really need to work for a living, and can go for many months without a new job. If he were to follow your advice, what makes you think he can just walk out at that time and have a new job that week? He's moved to a new city, which most likely isn't some giant tech city, so it'll take him time to apply for, interview, and secure a new job. If he's allowing the old employer time to meet his conditions, then he cannot ethically start this process until they don't, and either fire him outright (because they don't like being given an ultimatum) or simply don't bother to change and start secretly looking for his replacement. Even if he decided to act unethically, accepting a job offer and then backing out is a good way to get on a company's black-list, and in a smaller city that means you now have one important employer that you can never work for again, and if they share this info with other local employers you're really screwed.

The only rational way to handle this is to make a decision based on the current information.


Unless they paid for your relocation you don't owe them anything. MORALLY you definitely don't owe them anything. They lied. You agreed to do one thing... this is something else. You're only morally liable to do the work you agreed to.

At the very least you should talk to your manager / hr about this situation. Hopefully there's some other role that uses your skills that they can put you in. If not they need to know that this is BS and you're looking for a new job (NEVER BLUFF ABOUT LEAVING. They may call you on it). If nothing else this will, hopefully prevent them from doing it to someone else. Hiring someone is expensive, and the time cost of spinning up a new person is expensive. It's not in their best interests to lie to people. It costs them money.

On the other hand, legacy code isn't necessarily a bad thing. The work of bringing it up to modern standards can be rewarding (if they'll let you do it).


If all you've got are React and Typescript, you may be better off learning how to modernize old code. There's a glut of Javascript-only programmers. What's the old code written in?


Some webforms but the majority is in a much more ancient and niche language I won't name because it's too specific to this company.


Must be Wasabi


It's literally so ancient that we bought the remains of the company that designed the language when they went under


Oh you web people. That code has aged like a fine wine.

Consider the emacs developer. He works on legacy code dating back 41 years, to 1976.

Consider the BRL-CAD developer. He works on legacy code dating back 33 years, to 1983.

Consider the gcc developer. He works with legacy code dating back 29 years, to 1988.

Consider the SPICE developer. He works with legacy code dating back more than 44 years, to 1973 or earlier.

Consider the Windows developer. He works with legacy code dating back more than 32 years, to 1985 or earlier.

Do you happen to be younger than all of the above? These projects are all still actively used and developed. At least the first three are thought to still have full source control revision history. Any of them would look great on a resume. All of them are written in languages that were designed prior to 1980, making the youngest language 38 years old. At least one of them is largely in a language from 1958, which is 59 years ago.


If you leave then they're no longer paying you, so you owe them nothing, right? :)


Exactly, you owe them your labor while they're still paying you. If they gave you a signing bonus or something under the assumption that you'll stay for a certain amount of time, then they will probably (justifiably) crawl it back.

Like 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.


Life is Extremely Brief.

The time you spend toughing it out in a job you hate is time you could have spent doing a job you enjoy. Look for a new job and do your professional best for the company until you can move on. Absolutely do not tell your employer that you are looking to leave.

As a data point, I've never worked on code older than a year or two and most of the time it was code I wrote. Perhaps I'm some kind of lucky unicorn but I've been doing almost exclusively greenfield projects for 30+ years.


I'll take your job. I actually want the experience to handle legacy code. I'm ok with unsexy stacks because I consider that part of the craft. A true professional won't be able to avoid it, so embrace it.


I think you could interpret the situation as your employer being dishonest (it sounds like it, and that is troubling) or you could say they have will to do things with tech like React or TS, which could be an opportunity for you.

This could be stating the obvious, but legacy code does not necessarily correlate to age. A really bad situation is where your team is actively writing legacy code: written today, needs to be replaced tomorrow.

I have been involved with a greenfield project which replaced a legacy system which was actively being used. My team's decision was to scrap the old and start from scratch. This resulted in a massive delay before we were able to start adding value for our users. While we spent over a year using (learning) newer tech to build a system from scratch, they were stuck using the old system. And of course the new release was buggy.

A much better approach would have been to incrementally introduce the new tech were possible until it replaces the entire system. I think the pattern is called strangler vine.

Working Effectively with Legacy Code by Michael Feathers is a classic. It might be helpful or get you more interested if you are not already familiar.


I think you get a free "this job didn't work out" card every couple of years. If you really hate it, then find a new job. As a hiring manager, I would accept your story as a valid reason for leaving. If your resume has several months-long stints, then I'd start seeing red flags and get concerned. However, if your work history was previously stable and now you make a quick hop, I personally would not pass too much judgment here.

My advice:

1) if you can, do whatever you can to start porting to a new system with React/Typescript ASAP. Do it on the sly or something, maybe, but get it to the point where the higher ups are like "Oh, this isn't as big a deal as we thought it would be". Especially if you can do the transition in a piecemeal fashion. If you can single-handedly demonstrate the benefits of the new system and the ease of transition, then not only will you look good to the rest of the company, but that's a huge win to put on your resume and a great story to tell when you interview at future jobs.

2) Deal with the legacy system. It's also a huge plus to be able to go to an employer and say "I'm a React/Typescript expert, but I've also gone blind into a codebase and mastered it in X amount of time." Use your free time to write React/Typescript projects, especially (again) if you can transform those into new products at the office.

3) If you can't do #1 or #2 and you absolutely can't stand this job anymore, find a new one. Don't worry too much about the "i've only been here for a few months" thing. Sticking it out is almost never the right decision, in my experience.

4) IMO, happiness is paramount. Being miserable at work leads to being miserable when you're not at work, and life's too short to be miserable. Do whatever you can to make yourself happy, whether that means any of the options above or something else I haven't thought of yet.


First, I'm truly sorry. Do you have a goal and is this a stepping stone?

Forget tech for a second. This is about principals, ethics, morals and values. A liar is after your reality. This is about following and seeking mentorship from those whom you respect and those who respect you. This is about having a spine, sticking up for yourself and saying no. I disagree with the comments telling you to stick to the shit you've been served and be complacent. Life is too short and there are thousands out there willing and eager to waste your life if you let them. Your principals are compromised and self-respect is at stake. DO NOT ACCEPT THIS.

Events like this foreshadow and reveal the true nature of the culture at your workplace; a lesson going forward that you should not ignore. I challenge you to challenge them. Professionally and transparently confront them; I was hired for X and am doing Y, when am I going to do X. Do not fear reprisals as they are blessings in disguise. You owe it to yourself. You are passionate and skilled in high-demand front-end skills and they are silently killing your passion, career and earning potential.

1. Know and control your finances 2. Push and demand what you were promised. 3. In parallel, proactively seek a new job/opportunity.

Nothing is wrong with developing legacy applications. It's challenging and can be just as lucrative. However, when I interview a candidate for a new delopment, a history of maintaining legacy apps is a bigger red flag than short time at a precious role(granted not a pattern). Maintaining code vs creating from scratch are two different beasts and mindsets.

Be strong and learn from this experience. Best of luck.


> they're paying me, so I owe them something right?

Lots of quit advice here-- that's the easy path.

Actually improving the place is much, much harder. This could still prove a unique labratory to burnish your tech skills and people management abilities. Can you tough this out for a year? That's a fair cycle to measure results.

Meanwhile, squirrel away your cash and start aggresively building your local professional network. That will ultimately give you options.


This seems like good advice. I think there have to be SOME learnings that will help you grow at this job. I once took a job with one of the largest IT companies in the world, even though the tech and "culture" seemed opposite of what I wanted. But I learned a whole lot, because companies that big are making 1000s of mistakes every month, and you learn from mistakes. You get to see what NOT to do, how NOT to manage people, etc.

There is also a lot of resume building opportunity with a "situation" that isn't ideal, as the previous poster mentioned: can you make some progress on transitioning their stack out of nothing? can you go a bit beyond the job role and have some great things to talk about in your next interview?

I am not saying dedicate your life to a job you hate, but maybe finish out your first year then evaluate your options -- and try to make the most of the rest of the time you are there.


You've got a few problems:

1. You don't like your job that much (because reasons).

2. It's rubbing off on your attitude some, which may make it harder to find a new job you like.

3. You don't have the independence to just do what you like, or to quit and find a job full time.

I wouldn't suggest quitting immediately, because of 2 and 3, but you should probably keep looking locally for something that seems a better fit.

My suggestions would be to study the job market as hard as you do any programming problem. The "plum jobs" are generally specialized to a certain skill set and are hard to find without experience and contacts, so manage your expectations on that front. You aren't going to necessarily find something you like better just because you want to. You have to look at what companies are hiring and try to advertise yourself to meet their needs, especially in a new city.

Leaving in the first 6 months because you aren't a "good fit" isn't a total black mark, as long as you don't make a habit of it, but it always seems like it's easier to find a new job if you've already got one.


Mastering legacy code is a core SW engineering skill. Learn how to do it if only because it makes new code you write less likely to end up in that state.


I'm actually in a somewhat similar situation. In my case, the position is remote, so I haven't moved anywhere, but I was lied to about how agile the company is. They do waterfall, but they call some of the phases of the traditional Software Development Lifecycle "sprints."

We're in the analysis and design phase now, and I've been producing documentation for about a week now. As lead engineer, I'm actually being expected to take wireframes a user experience expert has made, transform them into verbal requirements according to a rigid format in Confluence, and then JIRA tasks are created. I am expected to go into these JIRA tasks and link them to the Confluence document with the requirements.

This is now the second project, and on the first project, I felt I did very little of what traditionally constitutes software engineering and instead a grab-bag of tasks vaguely related to the creation and maintenance of software.

Confirmed that this is simply how they do business, I am on the job market again.


Look for a new job while pulling in your current paycheck. You were lied to from the start and you owe them nothing. Most of the new places will no have a problem with "job hopping" if you are honest and say you aren't working on what you were hired for. Relevant xkcd https://xkcd.com/1768/


Damn that's relevant


You're getting some really angry and personal responses in this thread telling you to suck it up and clean up the code yourself as if thats the path all programmers have to take. Thats not true at all, many companies provide good opportunities for employees to grow within their role in a more positive manner. Cleaning up the codebase would make you a sucker. They lied to you and as you describe it continuing to work there sounds like career suicide. Don't do them a favor by putting in the extra hours and effort into cleaning up their mess (its not YOUR mess). Your time is valuable! By lying to you they are literally wasting your LIFE. Think about it that way and any guilt/obligations you have towards management goes away.

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.


You skill will not rot if the code base is old and bad, your attitude does. It's just not your conform zone, it's ok to avoid it, but you will learn a lot if you don't. Spend some time to understand the business logic of the legacy code by doing code review, debugging...etc. and see if you can improve it by back porting the new technology, there's always room for that.


I was in this situation. Was told they were transitioning to a new stack, but that never happened.

I gave it(wasted) 1 year.

But, in retrospect, I waited too long. If anything, after 3 months, I should have said: "My expertise is X. I want to work on it. I'd be happy to come back when you guys are actually doing X."

I recommend interviewing at other places asap. Life's too short.


When leaving a job that you haven't been at long, "Not a good culture fit" can work in both directions.


What's the legacy codebase, if I may ask (unless it identifies the company too much)?


Some of it is so obsolete and unique it would probably identify the company :) . The rest is slightly less old, MS webforms.

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


Patches all the way down, it seems. I've had to deal with similar codebases. I try to fix what I can, but it always seems to be a neverending process.

Legacy codebases suck, but it doesn't stop newer codebases from sucking just as much. I've learnt that the hard way.


Yes. The codebase is best described as a giant pile of hacks.

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.


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.


Sounds like it's time to get out then. I don't know how hard that would be as you said you moved cross-country, so you could be anywhere (in the US I'm guessing). Remote work is always handy.


"You got duped"

If this is how you feel, that would be a deal breaker for me. But you mentioned in other comments that you can't leave your job right now. So...:

A solution could be: Talk about it to your manager. Tell him/her that this is not what you expected, and how he justifies that. Also tell him/her that you'd like to change project as soon as possible. Try to get the discussion in a written form: email or something...So that you can always quote it later whenever needed :) Basically: be honest, be transparent

Another solution: Look for a new job, while you are working on this project.


I'm in almost the exact same position except possibly worse so as I'm about to be sponsored by the company to stay in Australia on a skilled work visa... So mind numbing and career stifling that I find myself her on HN wayyy more than I probably should be :/ I've mentioned my concerns with the PM and a tech-lead and get told things to the tune of 'well your other colleagues didn't have a problem...' Been here a month now. Currently trying to build up the courage to write something to the boss but I'm not sure if that's a good idea.


Sounds like someone likes 'collecting' programmers from different languages and technologies and giving them jobs =] Learn it love it or leave it, you're still making money right now so....


I have a theory that the company is for sale and the owners don't want their ancient stack to show up on Google search in job descriptions.

If it's not that you guess is as good as mine :)


In my first job after college (circa 2007) I got roped into maintaining a ColdFusion website, enhancing a billing system written in C, and, later, working on a Java 1.4 app (which was starting to feel ancient, even then).

I learned something useful from each of those projects. And it's certainly not the case that this work caused my other skills to rot.

If you really, really don't like the work, then there's no shame in admitting that and moving on. But you have nothing to actually fear.


I've faced this a few times. There were times when I knew that the situation would change and stayed, but I left when I was in your situation and knew that any form of change would be years in the making and my skills would atrophy in the process.

You might do well to learn something while you are there. I was working on a VB6 and mainframe terminal application in the mid 2000's and still managed to extract some value.


"..hope I don't get fired for underperforming?..."

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.


Was with you until you got a little too aggressive. There is a better way to say what you're saying.


Aggressive perhaps. More effective? Maybe


I wasn't hired to work with old junk. if I would have known I never would have taken the job. I also don't have enough money to walk away or risk standing up to management.

The code isn't just old, it's very badly written and has zero documentation.


"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


And I'll add: strive to never create such code yourself. You are 100% correct that everyone says old code is badly written and has zero documentation. So is the code we're writing today. Once you realize that you'll have become enlightened and will be a better programmer for the rest of your years.


If you were lied to, that is reason enough for leaving. If they lie about the role from the start, they will lie about other things.


Have you ever had an employer that didn't lie at least a bit ?


get the things that matter in writing. anything that is not in writing is a bona-fide lie.


yes


They cant be mad if you tell them you are leaving because you were hired to work on xyz and you are actually doing abc. Unless they hired you saying that SOON you will be working on xyz. Then you put yourself in this situation.

Anyways most employers will understand your reason for leaving and it shouldn't be too big of an issue to find a new gig.


Can I ask what the legacy stack was? You can email me if you are afraid to narrow the scope of possible places. Similar thing happened to me once. I ended up toughing it out for a year, spent my evenings learning stuff I wanted to work on so it wasn't a lost year, and then leaving.


Webforms is the newest thing. Most is far older


Find a new job ASAP. If an employer lies to you, then you probably can't trust them. Life and career are too short to continue navel gazing on this one.

In the meantime, go learn the new old stack and be productive. They're paying you, so while they're paying you, you do owe them your time.


The same thing happens to people at my company. If you have options, try an internal transfer. If not, get back on the market. Don't do a job you hate unless you have to.


I remember when I got hired to work on old code for an autoshop program. I actually loved it... great job though it could be tedious, but the worst thing was the boss constantly micromanaging me. I couldn't stand it. We'd have meetings about fixing things and new code to be implemented, than he would have me email him [an outline of] everything said in our meeting.

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.


Stop bitching and move on to write your very own legacy shit code!


Some insight hidden behind poor communication skills here :-)

Not looking forward to clean up all the js frontend code that everyone think is cool these days. :-/


Look upon this as an opportunity to clean up the code and make it beautiful. You might find an opportunity to slip in some new technology.


You were bluntly lied to, you owe them nothing.


well, it's your life. you said it yourself "I'm beginning to think that they mislead new employees because otherwise they would ask for a lot more money or walk away." so ask for a lot more money or walk away.


Have you ever moved from an uncomfortable position and regret it later?


Fool me once, shame on you. Fool me twice, shame on me.


That depends. It sounds like your veterans are burned by the similar lip service to deprecate this codebase.

Are you a bad enough dude to rise up as a leader for these people and help get them out of the rut that you're now experiencing? (And get yourself some leadership bullet points for your résumé?)

Let me toss out a couple of definitions that I subscribe to first before I continue:

Lacking a comprehensive suite of automated unit ("small"), functional ("medium"), and integration ("large") tests is a necessary and sufficient condition for code to be called legacy.

Code is called deprecated if and only if there is an active, expedited push to remove it from production and, if dependencies on it still exist, replace it with something functionally equivalent. (This second part is crucial.)

Frame the conversation in these terms.

With that said, I have a couple of questions:

Do managers make the technology and risk management decisions in your organization? If so, your first priority is to find some way to usurp that from them as an engineer with help from your veteran cohorts.

Do you have any experience writing those three classes of automated tests I rattled off here earlier? If not, this is your perfect chance to develop that skill. It just so happens that this carries over into your area of interest, and it's a very good discipline to get into.

Writing tests like that establishes a certain sort of contract about how the software should function. Integration tests, ideally, exercise its functionality in the context of its inter- and co-dependent systems. Meanwhile, functional tests, with a similar ideal, exercise its functionality in the context of intra-module dependencies within the same system.

With those two things there, you'll be able to make "right around the corner" more of a reality because you'll actually have a metric to use to measure how "done" you are with a drop-in replacement.

(And, along the way, since you're already perceptibly breaking things, you can deliberately break some things but use those failure modes to write integration tests that further boost your confidence that you're getting there! Sneaky!)

Unit tests, in contrast, help you to cross the last mile of maintaining what you currently have as requests to change things come in. To use your language here, it'll help make the process a lot less stochastic, at least in terms of management perception. Your tests will fail before anything happens in production.

If you stay at this organization, your personal goal should be to learn how to write those three classes of tests and to get good test coverage around it all.

Then again, if you can't usurp those things from management, run.


If you were truly lied to, then at the least you should out the company because this is unacceptable - especially given that they had you move across the country for this. If they don't face any consequences for what they did, then they'll continue to exploit others like they did to you.


It's too small a company to maintain my anonymity. Small enough that it's unlikely to burn any fellow HN readers if that makes it any better




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: