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?
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.
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.
I was thinking I could just apply to other places and be honest with them... But some may also frown upon me saying bad things about my current employer
I'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.
Chalk it all up to career learning... Try not to get too personally invested or discouraged.
I'm amazed the code works at all. The stack traces are more than twenty deep sometimes. I can't stand to look at it for more than 20 minutes without a break.
I need to be more careful next time I'm looking for a job
Also consider that "the fastest way which is usually a bad hack" is sometime the correct pragmatic approach for a legacy codebase that's in the process of being replaced. Giving them the benefit of the doubt, think about whether the elegant design is really necessary if there's a ground-up rewrite about to happen.
Even if it's demonstrably true that they've been "claiming" a rewrite is "just about to start" for a _long_ time, sometime's that's just as frustrating a thing for management as it os for the coders - management may well honestly have always believed this rewrite was supposed to have started 12-18 months ago, and that it genuinely is only weeks away from starting... Just like they believed last month and six months ago... I've _been_ "that manager" before (and I'm sure I will be again).
And why do you agree?
One of the differences between professionals and other workers is that professionals are experts in how to do their work. If I tell my doctor to just write me a prescription because I said so, she'll just scoff. I can make requests, but she decides what will happen and how.
Especially if you're already likely to quit this job, then you don't have much to lose by insisting on using best practices. Sure, you have to honor their desire to do things reasonably quickly. But you don't have to keep digging the hole deeper if you feel it is professionally negligent to do so.
Haven't counted but I think this is totally not unusual when I work on Java which I consider a modern stack.
What kind of passive language and thinking is that?
Everything is legacy once it is written.
Imagine you, the trailblazer, only having to write new code and not having to maintain the crap you wrote.
The actual problem here is your attitude and way of seeing things. Legacy? Sucks?
Fucking write a better version and show some initiative instead of just hoping of being granted the opportunity to work on "new shit".
Millenials these days.
The code isn't just old, it's very badly written and has zero documentation.
- Says everyone
Now you learned 2 valuable lessons:
- There's a lot of shitty code that you sometimes have to deal with
- Never put yourself into a state of dependency on a single income source, unless you wish to have the emotions you are feeling now
Start documenting those requirements and create a plan to map those to technologies that you prefer. Understanding how to successfully migrate platforms is a learned skill, and it's going to become useful again when React is no longer en vogue.
Also, OP's story is currently colored by how upset he is so I'm sure the interviewers made the job sound more appealing than necessary but I'm sure there is also some revisionist history happening.
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.
According to OP this company has been around for 10+ years. It'd be a miracle if they didn't have legacy code.
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. :)
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.
The webforms stuff isn't much better because the code quality is the worst I've ever seen. Adding features and fixing bugs is a stochastic process because you never know what will break.
Usually fixing a bug will expose an old fix that was done improperly for the original even older bug, forcing you to undo multiple levels of hacks to implement your own. It's nightmarish
Legacy codebases suck, but it doesn't stop newer codebases from sucking just as much. I've learnt that the hard way.
Yes, you can step away, in the figurative and literal sense. In many possible worlds this may even be the best plan, if you have no real agency over the code. And you got lied to. It'd hardly be the first time someone has been convinced that the work would be cooler than it is.
But -- you also have to decide if this is an opportunity in disguise. Stories of folks who gradually build ownership over the creaky "legacy" codebase and polish it up with Sisyphean refactoring, until it shames the "rewrite", are out there, and they're real.
On the other hand, fixing the legacy code may be one of the hardest things you can do in software architecture. There's no sense of joyous freedom to it, just correcting of old mistakes. But if you did that, and published documentation to evidence what you did and how, lots of folks would want you - and not necessarily for the task of fixing their own crusty code.
So there is an opportunity here, if you can find a way to sneak it through the management, which has surely decided on the balance sheet that the code is a "deprecated asset" and will not want to hear about new ideas. In fact, to maintain it you don't want to present anything as a "new" - you have the much harder task of justifying every small change as an opportunity to improve the debuggability - to get the callstack down from 20 deep to 19 deep, to remove a superfluous parameter, to improve turnaround times, to reduce the code size by a few lines, or something similarly miniscule, but which might add up over time into real understanding.
Never seen it in practice. Is this a real thing?
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.
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.
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.
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.
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.
If it's not that you guess is as good as mine :)
Not looking forward to clean up all the js frontend code that everyone think is cool these days. :-/
[0] https://www.snellman.net/blog/archive/2015-09-01-the-most-ob...
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Anyways most employers will understand your reason for leaving and it shouldn't be too big of an issue to find a new gig.
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.
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.
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.
