Tips on what I should do to move up?

Question

So I work for a company doing maintenance for a web application. The web app is so old, has an insane amount of legacy code and has hundreds of thousands of lines of not so great code if I'm being honest. It's sort of like being given the Titanic that's already been sitting at the bottom of the ocean for 100 years and being told to fix it and make sure everyone is riding on it safely.

I would love to make the application better but I feel like I'm in a tough situation. I'm mainly always given tasks to "fix this weird bug" or "tell me why the application does this? How do we work around it?".

I talked to one of my higher up coworkers who told me to learn React and continue understanding how our system needs to work and maybe I could be a part of building out a new application in the future.

I'm currently working on building a website using React and FastAPI on my own just for fun and experience.

I think my dream scenario would be to:

• Build out a new application for a big company
• Be on the team that supports that application

Since I built it, I would know how it works and I would understand how to support it.

I've thought about maybe talking to that coworker a bit more about what he would want and what I could do to get to that situation since I only talked to him once for a short 2-3 minute conversation.

I've also thought that maybe even if the company doesn't decide to start building out a new application, or I can't be a part of building out the new application, I could find a job elsewhere in a few years doing something like that.

Do you guys have any tips for me? Anyone ever had experience being in this kind of situation? What can I do to level up and reach my dream scenario?

Answer 1

As I'm reading it, my understanding is that your primary goal is to move up in your career as opposed to simply move up in your company. I think your approach isn't bad in general in that it will help your career regardless of the company. However, I think you need a reality check about your company. You're saddled with a crap website that has no prospect of even repair, only rewrite. Your colleague's suggestion to learn React is a good one, though I disagree with the rationale. I don't see the benefit of staying in the company once you've got the skills to go elsewhere.

Personally, when I look at a company I'm considering working with I try to look at the technology stack they use and then how stable or unstable it is. I've walked away from several companies based on their web presence or other evidence of questionable competence. I remember a recruiter from a very old established company trying to get me to submit to them. I was more than willing to do until they gave me a URL to submit a formal application to get me into the system for tracking. I had no problem there either. Until I saw the application. This was in 2015 and the application was written in ASP. Not asp.net, but asp. Another company I cut ties with (again an older company that was usually very desirable to work for. At that place, they were using VB 6 applications to run their financials. A public company. Relying on VB 6 with no immediate plans to replace it.

A company that is content with crap is not a company you want to work for. But right now, they pay the rent. Don't rely on some vague hope given by a colleague. But I think it's still a good idea to build an application using your desired technology. That may or may not be React, depending on your job market. But building a prototype application will give you something tangible to show future employers. Microsoft has done that for years to demonstrate technology, with dummy companies like Contoso or Fabrikam.

The unfortunate reality is that the easiest and most common way to advance your career is to change jobs. It can be scary but you may be surprised at your own worth to other companies once you acquire more skills. Your current company? It's a coin-flip as to whether you could advance there or not. But for some reason, companies have more often been willing to hire new talent than promote. And when they do promote, the increase in pay is still usually less than if they'd brought someone in.

In summary, here's what I would do. Go ahead and learn whatever technology and make your prototype app. I wouldn't worry about doing an app with the hopes your company will use it. In fact, I would strongly recommend that you do not. Depending on location, employment agreement, etc. they could try to claim that it belongs to them anyway.But if you have a working application that demonstrates good functionality and has code you can show a different employer. I just can't get past the fact that it's a largely broken app they already have. That is the legacy their software is demonstrating. Additionally, you don't want to be maintaining the old while trying to write a replacement. That's not very productive (I've been there) and will just add a lot of stress. Come up with some sample projects on your own and treat that like an artist would treat a portfolio.

Answer 2

Since I built it, I would know how it works and I would understand how to support it.

That won't work: Writing an application takes quite some time, so by the time you write the last line of code, you'll have forgotten about the first part.

The only way to effectively maintain (or extend) software is to be able to figure out existing code, which is a skill that you can train in your current role. Also, it is important to write code in a way that can be figured out. That, too, is something best learned by seeing how others have failed or succeeded at it.

So when you assume that you need to write code in order to maintain it, I think you've got it backwards: You need to maintain code in order to write good code.

That's not to say that maintaining legacy code is necessarily what you should want out of your career. It's your career, so you get to choose what you want to do. If you prefer working in newer technologies, or prefer building something from scratch rather than spending all your time maintaining things, another job (or another role at your current employer) might suit you better. But in pretty much every developer role, you will, on occasion, have to figure out existing code. And it won't necessarily be well written and documented, either. The only difference is how often that happens.

Therefore, if you seek a change because you can't figure out existing code, you would be better served to learn that skill - but if you seek a change because you enjoy writing new code more than fixing existing code, other jobs might be indeed be better. In that case, learning a technology used for building new stuff is a very good first step. You might also want to ask your current employer whether such a switch would be possible, and what would be required to make it happen. Or look for opportunities elsewhere. Or you could stay a while in in your current role, learning from the successes and mistakes of your predecessors so can repeat the successes, and avoid the mistakes when you get the chance to write new code.

Answer 3

Adding to meriton's answer: if you feel like you can honestly propose a "better" code - here "better" may be maintainability, scalability, performance, user experience, whatever you identify as an issue that needs to be fixed as long as the issue is affecting the business somehow - and you can prove it - and/or the fix/improvement has an "obvious" reason to be implemented - and here you might want to take a step back and reflect on why the code is the way it is and why nobody in the team has ever brought up this issue. The answer may be - as predicted by meriton - that the code just works well the way it is. Perhaps they have already studied that option and came to the conclusion that it's not worth it - I believe it's commonplace among big corporations to maintain their allegedly outdated software following a research showing that the benefits of an "upgrade" don't justify the cost.

At a more personal level, I recommend you to document all the issues, improvements, feats, bugs, whatever you observe and feel like you can make it better: document it, plan the solution, prototype it and when the time comes to present it to your immediate superior or the team, you'll know.

In case the time never comes, you'll have more than just a reason to quit: the time and work you have put into your research and plan will definitely teach you a lot and perhaps be a nice addition to your portfolio.