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