Not learning working at a legacy codebase, should I move to greenfield dev?

I have this problem sometimes with my software developers. I think because they read too much hacker news and "trendy" news sites they believe the moment they aren't working in a cutting edge code base they are not evolving as developers.

That couldn't be further from the truth. You learn much more navigating a very complex code base, having to introduce changes without breaking the APIs, making decisions about scope and communicating with stakeholders who rely on that API. Evolving a big legacy code base that is generating revenue to the business and supporting the core users is a very hard software problem

Greenfield development is easy, anyone out of a bootcamp knows how to put A+B together from internet articles.. I honestly am not amused when I see CVs of people who keep just playing with cool toys and never maintaining their code, people who never worked in code bases that are 5+ years or stayed a long time in a company.. IMO as a rule, and every rule has an exception, they aren't valuable software engineers. They haven't had to support their own systems until they become legacy... they're fad driven developers.

The best thing you can do is read this book: https://www.amazon.ca/Pragmatic-Programmer-journey-mastery-A... and apply its lessons in your company, in a code base for years.

Whatever framework or technology you're chasing honestly doesn't matter. It's bound to be considered legacy at some point anyways.

My career is 10 years old at this point. In the first 5 years of my career I spent half my time working on green field projects and half on legacy projects. Today I leverage far more of what I learned on those legacy projects than on the greenfield ones.

A lot of software engineers talk about and appeal to maintainability for why software should be written a certain way. But if you haven't spent years on a million line code base that's 10-20 yrs old you honestly have no idea what maintainability means. I learned a lot tracking down bugs and understanding why those happened.

The other half of the five years I learned Silverlight a new shiny technology on a greenfield project.

Now to answer your more direct questions.

> If my resume is only working on the greatest and latest, is that a bad thing

No, but if you apply to a job that involves maintaining large legacy software(this group includes pretty much every software group that is making tons of money) they might ask you questions to see if it's a good fit.

> Does anyone else have a hard time trying to convince themselves the value of maintaining old codebases

I don't, I like old code bases. You have a large impact on a lot of users. I find it hard to be motivated to rewrite working code in a new sparkly technology if it doesn't add significant value to the end users.

> How did you do it knowing when you apply at the next job interview, they will be asking up to date technical interview questions

Usually if I'm ready to switch jobs and I want to apply to jobs with some new technology I'll spend a month going through the basics. Honestly even if I'm familiar with it I will. Most interviews will ask questions that you won't know even if you work with a technology for a year. But will know from watching a video for an hour.

> I felt really dissapointed at myself at my inability to adapt...

Don't worry about it, I know plenty of devs who love new technology and are constantly switching to whatever the new fad of the year is. They had great careers, seemed like pretty happy people, and we're really valuable sources of knowledge on which new technology's were worth integrating into the project.

If you like new tech don't worry about it, just get a job working on new tech and switch every couple of years to a new job. This is a very viable career path.

I'll tag on to this line of thinking.

It is interesting how legacy code can influence what you do in new code.

I still consider myself a bit of a n00b and landed a job where there is this monster of legacy code. I hate working in it with a passion.

Then I got the chance to build something new while working with the old code.

Very quickly I realized how much that legacy code taught me about maintainability, extensibility, and dealing with the business logic(s) that are likely to show up.

My new project was / is hardly perfect, but I made sure those things that seemed inevitable / the old code taught me "Oh I see something changed and this is a shim of sorts to do X, Y, Z when it only did A, B, C." showed up in my new code too, but were easily changed / customized and etc.

Things that are / were a big lift in the old code ... in my project is now just about 5 minutes of work and so forth.

Still hate that old code... but it taught me a lot that just writing straight new code would never have shown me.

It's super hard for me to not respond too strongly to this, as I'm currently having trouble with a particularly junior dev who just cannot wrap his mind around maintainability issues...

But really, I feel if "you" are spending the majority of time setting up new projects and familiarizing yourself with new technologies, that doesn't leave much time to get really GOOD at anything. Sure, we live in an amazing time where the simple act of adding a new technology to a problem can grant huge business benefits in a lot of places. But that's almost never the end-all, be-all of it. You don't just get to hook up GraphQL and ring your hands of it; as the company grows and begins to rely more and more on the new technology you set up, issues like whether or not you're getting source data efficiently start to really matter. How you set it up, and the design patterns you instituted for that technology, could very well make for the success or failure of a company. And it'll definitely effect the mental well-being of the the devs you leave behind.

I disagree with most of the things in other comments. Working in legacy makes it harder to land a job that isn't related to legacy code. No one cares that you spent x years of your life maintaining some old crap written in a language that went out of fashion. Staying in such a job equals putting yourself at a disadvantage in the future and is not worth it at all unless the job pays exceptionally well... and my experience is that such places actually pay worse.

When I look for a job the number one question I ask is "how old is the project" and number two is "what kind of technologies are primarily used". If it's something that's older than 5 years I don't pursue the offer any further.

I agree here. React is not a fad. Its matured and has essentially become the industry standard. My company gets lots of young engineers who don't really know React that well, and it can be a problem. It can be issue even for those with lots of front end experience since they've built up habits and patterns and mental models that don't really make sense any more. On the other hand, I'm thought of as an expert in modern JS and React, so I get all the hard/interesting problems and everyone comes to me whenever they have a question. That's generally a good position to be in career wise.

But, really, the benefit of using modern tech is that it's going to make you much more productive especially when we're talking about the front end. A more productive dev is a higher paid dev.

There might not be a lot of market value in doing greenfield JSP development, but being able to navigate legacy codebases and maintain them without breaking critical user flows is a crucial skill. If you only ever use the latest and greatest then definitionally you won't have direct experience working on legacy systems.

If you want to stay up-to-date with new technologies, try to identify places where you can rewrite core subsystems in a safe way. When you pitch this, make sure to explain why it would be useful to the company.If that goes well, you'll have more credibility as you suggest rewriting more of the codebase.

Depends on how you value your own experience and skills. I can assure that if you can market yourself as someone who can add tremendous value working wth legacy codebases, you could be very valuable to a company. However, if that doesn't excite you and you only care about tech stack, then yes you should find something else. However, my personal opinion is NOT to focus on tech stack but find a company/business that you really like working for not because of the code but because of the product/market and other interesting challenges it brings.

So ask yourself: are you not motivated because the codebase is legacy or is it because the team/environment is not giving you challenges that you enjoy ?

There are plenty of shit startups with shiny tech that have terrible environments, not much market fit/business and hardly any security/stability. Do you want to work in such environments ?

I've been in this space long enough to give you one very important piece of advice:

- language and frameworks get you interviews, accomplishments get you jobs

Note: that advice isn't relevant to FAANG style companies that do algorithm interviews. They usually don't give two sh*ts about your accomplishments and will put you through the same algorithms non-sense they put a fresh grad.

It's much more important to be accomplishing something. The problem with chasing frameworks is that you aren't actually focused on what engineers and developers do; solve problems with technology. So yes, you likely aren't growing maintaining an old code base, but it's not because you aren't practicing React. It's likely because you are spending most of your time tackling technical debt. This is a valuable skill in and of it self, but I would say if you are rather junior, aim for a good balance of greenfield and maintenance. It's important to fully grasp every part of the SDLC. Yes that maybe less relevant in today's "agile" non-sense, but it's pretty valuable for you as a professional to understand what the full cycle is. What does it take to get a project off the ground? What does it take to setup a CI/CD pipeline (and btw, these have existed in some form for YEARS)? What does it take to deliver? Why did you choose language/framework A over B? And so on...

Really there are some rules of thumbs we've developed as a profession around this: - If you aren't doing something different in ~2 years, you probably want to ask for a new opportunity internally or move - Always be ready to interview, you're likely to get at least a 20% salary increase by doing this - Longevity in a position is only valuable if you like the organization and intend on moving to management or principal engineer type roles

Don't focus so much on frameworks and languages unless you want to be a consultant/contractor in that space.

And above all else: NETWORK! Build a real organic network of friends and colleagues. This is more valuable than anything else. These are the people who think of you when a job comes along. These are the people who you join or bring to a new organization to do something trans-formative for that place. This needs to be both organic and deliberate. Keep up with old friends, classmates and colleagues. Make new ones at hackathons, industry events, meetups etc. (this is harder, but possible). And above all else have a life. Participate in non-technology things so you don't burn out. Try learning a new non-technical skill potentially in an industry that you might want to work in.

Good luck!

Do what you enjoy.

It's a lot like music or dating. You have your own style. Stick to it, experiment with it. Yours might be working on the greatest and latest. Mine is fast iterations. Someone else might love clean code. Someone might love having completely bug-free code.

Don't convince others, just find the right 'band' for your style.

You didn't mention your co-workers. In a professional setting, we should mutually learn and teach software engineering wisdom from peers, not just from deep-diving shiny stuff with headphones on.

If there are no peers there who're interested in teaching you or learning from you, then yeah it's probably a dead end.

If you're looking to be valuable in the job market then my advice would be to focus on fundamentals and soft skills. If you're more interested in changing what you work on day to day then I think you need to apply elsewhere. It's really hard to change the stack of legacy software and often doesn't make business sense. Even when there is a lot of value in upgrading, you will need to convince people that may not necessarily agree.

What has worked for me is to move to what has made me MOSTLY happy. It's rare that you will find a perfect situation.

>Despite the fact that I tried to lie to myself by saying as a software engineer, I should be able to adapt to anything and place customer first.

This is not a lie as I understand it.

I was | am in the same boat. Decided to quit my job. & potentially not work as a Software Engineer again. But will work on engineering jobs that will require me to create 'new' code. Yeah legacy codebases e.g AngularJs | GWT are depressing & will never wish that on anyone. Unless they enjoy it.

Ask for more money to account for lack of career growth or ask to be moved to a different team. You are losing a TON of money by working with legacy technology, don't get duped. Imagine taking a job writing knockoutjs in 2020 for normal salary wow.

Not necessarily. If you're a real nerd, you'll be running side projects and making up problems to solve with the tech you're interested in. But if life is too busy and you're not happy doing the old codebase thing, then.. yeah. Get a job that engages you. But don't dismiss the value of having a good work environment/team/company.