
Not learning working at a legacy codebase, should I move to greenfield dev? - bluetofu
I&#x27;m currently working as a front end engineer (70% front end, 30% back end).<p>When I used to briefly worked at greenfield projects where I get to play around with React, Redux, starting a component library etc, I was very excited and learned a&#x27;lot.<p>I was then moved to a team working on maintaining a legacy but critical codebase. 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. I was not happy and motivated.<p>For some reason, one year in, I&#x27;m not growing. To be honest, I am not interested in the old ways of doing things (e.g. Knockout, JSP) as I see no market value in them. I tried to reason with my manager the value of upgrading the tech, but the progress is very slow.<p>If my resume is only working on the greatest and latest, is that a bad thing? Does anyone else have a hard time trying to convince themselves the value of maintaining old codebases? How did you do it knowing when you apply at the next job interview, they will be asking up to date technical interview questions? I felt really dissapointed at myself at my inability to adapt...
======
aprdm
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...](https://www.amazon.ca/Pragmatic-Programmer-
journey-mastery-Anniversary/dp/0135957052/) 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.

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

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

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

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

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

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

------
rafiki6
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!

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

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

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

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

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

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

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

