Not learning working at a legacy codebase, should I move to greenfield dev?
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'lot.
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.
For some reason, one year in, I'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.
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...
17 comments
[ 2.8 ms ] story [ 42.3 ms ] threadThis is not a lie as I understand it.
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.
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 ?
If there are no peers there who're interested in teaching you or learning from you, then yeah it's probably a dead end.
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.
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.
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.
- 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!
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.
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.
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.
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.
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.