
Ask HN: I got duped into working on legacy code, should I leave? - throwawaysbdi
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.<p>Its legacy code dating back more than 20 years. I&#x27;m afraid that my skills will rot if I stay too long. The code quality is also horrible and its making me hate coding.<p>The company talks about how we&#x27;re just around the corner  transitioning to newer stuff.  After talking to some veterans, apparently it&#x27;s been &quot;right around the corner&quot; for years.<p>I was hired for my React and Typescript skills&#x2F;interest and it&#x27;s been months with no signs of being able to use them. I&#x27;m not good with their current stack but I have no interest in learning it because its so obsolete. I&#x27;m beginning to think that they mislead new employees because otherwise they would ask for a lot more money or walk away.<p>I&#x27;m torn about my best course of action. I&#x27;m not good at my job because I don&#x27;t know their tech. I&#x27;m not good with their tech because I hate it and I&#x27;m bitter that I was lied to. I can&#x27;t mentally force myself to learn this ancient shit. On the other hand, they&#x27;re paying me, so I owe them something right?<p>The best solution for me is definitely to just get a job somewhere else, but I&#x27;ve only been at my current job for a few months. Should I just stick it out and hope I don&#x27;t get fired for underperforming?
======
sterex
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. :)

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

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

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

~~~
throwawaysbdi
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

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

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

~~~
throwawaysbdi
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

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

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

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

~~~
draw_down
No, no.

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

~~~
mod
Agency work, for one.

~~~
dkarapetyan
Really? Which agency is that?

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

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

------
jsnell
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...](https://www.snellman.net/blog/archive/2015-09-01-the-most-obsolete-
infrastructure-money-could-buy/)

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

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

~~~
p0nce
> 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?

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

~~~
throwawaysbdi
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

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

~~~
bigiain
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](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...

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

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

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

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

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

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

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

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

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

------
Animats
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?

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

~~~
macca321
Must be Wasabi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
gherig4
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/](https://xkcd.com/1768/)

~~~
throwawaysbdi
Damn that's relevant

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

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

~~~
throwawaysbdi
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

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

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

~~~
reitanqild
_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.

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

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

~~~
throwawaysbdi
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 :)

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

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

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

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

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

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

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

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

~~~
throwawaysbdi
Webforms is the newest thing. Most is far older

------
mattbgates
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/](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.

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

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

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

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

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

------
dtzur
You were bluntly lied to, you owe them nothing.

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

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

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

~~~
sauronlord
Aggressive perhaps. More effective? Maybe

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

~~~
reitanqild
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. :-/

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

~~~
throwawaysbdi
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

