I've been thinking lately about how much I absolutely love to code, like just taking a task and building something cool. And I've also been thinking about my future with development, I'm a Senior Engineer now and I've been coding for 8 years, also taking responsibilities to design, team lead & architect at times. I worry that as I progress the only path is to move more and more into management responsibilities/roles or move into product.
As a web engineer I feel too specialised to move into a full architect role which seems to be the only technical option for career progression. But I also have the worry that I'll get "too old" and not be hireable because all the new kids will know React v239 better than me π
Am I the only who worries about this? Is there career progression where you get to just stay coding/building cool shit most of the time or can you age out of dev?
Top comments (25)
I've been coding for just under 30 years. From that experience, I can say that you can't really "age out", at least not like that.
There will probably be languages you learn that you will mostly forget after about 5 years. I haven't touched a drop of Miva or Coldfusion since early 2000 (and hardly any Perl or VB), but it used to be most of what I wrote in.
There will be some languages that you just enjoy even if they're not the best. You know those guys who get paid big bucks because they're the only ones who know how to write COBOL anymore? Yeah, it's because they've continued to write it because there's still demand from large companies who have old systems. The larger the company, the greater the chance they'll still have some pretty old systems that still need maintenance or a knowledge of how to export data from them.
More than all that, you'll develop a knack for technical UNDERSTANDING as you continue in dev. Anyone can learn and memorize syntax but knowing how something works means you can write BETTER code than some fresh-out-or-college youngster who earns 1/5th of your salary.
These days I typically charge about $150 an hour for consulting work, and I know there are developers out there who charge a fraction of that, but it'll take them 10 days to write what I can do in 1 day and their code will be full of bugs, scalability issues, and security vulnerabilities, whereas I understand all of those areas and so people keep coming back to me because I just do a better job in every way (so I get to build cool new stuff all the time). I know that sounds like personal bragging but it's something most developers acquire over time by learning from their mistakes. It's just natural progression.
If you are feeling nostalgic - I know someone who needs fixing an 20years old system, that has some Perl in it.
I know of a different company using Cold Fusion too. :)
I'd say you're a bit on the cheap side for what you can offer...
Thanks, but I'm sure there's someone out there who still lives and breathes Perl (and ColdFusion) who would be more cost-efficient than I would be now.
I appreciate the note on the rate. It's a sweet spot for me at the moment, though.
I remember what I read around 15 years ago on TheDailyWTF.com by Alex Papadimoulis - a project should be considered successful if the customer is using it 10 years later. It's a failure if it's thrown away and replaced by a new one earlier. So all these "rusty" projects are actually very successful, no matter how crappy the code looks - if it still works it's good for the customer.
That was probably more true 15 years ago. In my humble opinion, industry demands have skyrocketed over the past 2 decades in volume and complexity, and we now have cloud services galore, where integration is the new name of the game. Many clients running older systems are also faced with issues that are hard to resolve without replacing the software (e.g. data warehouses that rely on file-based import/export functionality rather than REST/SOAP web services). These days, I'd qualify anything as successful if it makes it past 3-4 years. Who knows whether that will change in the future or not. Just my opinion.
From the perspective of a software developer - it's successful once you get your paycheck :) It's a problem of your customers if they will keep using it and how long.
Thanks for sharing, it's great to hear from more experienced people and see there is a path out there. And it's not bragging, it's awesome and inspiring πͺ
I have been working since 1980 so more than 40 years. What are you talking about?
I hear sometimes from younger colleagues that it is good to see me still going strong and loving my job. Then they know that there's nothing to worry about.
One lesson in life is go for learning rather than earning. Of course you need money, but many times there are several options and those that offer more learning is to be preferred. When you learn a lot, your earning will increase anyways.
"One lesson in life is go for learning rather than earning." This is great insight π
I'm in a similar position as you as well. I don't have any desire to move into management positions but have moved into tech lead positions. I do want to return to a more 'developer' role in the future however.
I've been doing full stack development and I know the backend architecture fairly well, so I could progress into a architect role if needed, but I'm not sure I would enjoy it (at least not yet).
Unpopular Opinion Ahead:
The developer market (like any market) has changed throughout the years so what we see today won't be the same in 10 years time. While people may want it to say as it is, the market is always adjusting. So a organization may be happy to keep a developer as a developer for 20+ years, if that person were to try and change jobs another developer position, I feel that would be hard (but not impossible)
I think there will still be a market for developers with particular skillsets in large organizations with older systems, but I feel it will be a challenge for a "older" developer to complete in the popular frameworks used by younger developers.
I hope I'm just being overly pessimistic about the future(and would love to hear some counter arguments) and to be honest , some of my negative thoughts are based on the 'current trends' I'm personally seeing...which won't necessary be long term trends.
FWIW, listen to your gut on what you would and wouldn't like. I liked the IDEA of management (having more control) and I moved into a director position with a smaller company. I learned a lot, including that I preferred development, and eventually went back to it (which paid $40k less but I was WAY happier every day). About 10 years later, I'm back up to what I was originally making but this time as an architect so I'm still able to do a pretty decent amount of coding, even if it's interspersed with less-fun activities. However, the architect role allows me the oversight to still make sure rookies don't go off in disastrous directions and projects are all done well, so it's a pretty nice spot to be in.
I like how you emphasis the IDEA of management over the actual execution of the role, I think I feel similarly, I like the idea of it but mostly because of the illusion of freedom that comes with it but I don't think I'd enjoy going to work everyday if I didn't get to build stuff. Or at least that's my thinking at this stage of my career anyway.
thanks for the reply!
You describe a role I hope to be at some point. An architect yet still doing a 'decent' amount of coding.
Same βοΈπ
I think the tough part is that you can never really go into "cruise control", but I think there's always room for someone who understands the principles of the craft and isn't as familiar with the new shiny.
Yes! These folks are everywhere, and they're amazing to have on the team. If you stay as an individual contributor, most orgs have a path for that... But I think it's generally... Slower. Like, getting promoted out of "senior" to what's next is kind of just a long slow haul, and leaping into more clearly leadership roles are often a chance to jump to a next new thing if you fit the criteria.
In our org "principal engineer" is the job above "senior" on the individual contributor track... But it's also okay to become a more and more experienced "senior" if the new criteria for "principle" are not a good alignment.
If any of this is your cup of tea, the opportunity is there.
This is definitely my cup of tea β I don't even mind if the progression is slower as long as I still enjoy what I do and am valued for what I contribute.
This is basically the issue with our industry. Medics are studying specialisation for at least 3 to 8 more years after graduating.
Software developers on the other hand believe they are "senior" after 5 and some even after 2-3 years. I'd say that after you spend over 10 years you will get a good grasp how to write software and at this point you become a senior.
I'd say this is relative, but basically you are a senior when you are no longer able to find the answers to your questions on stackoverflow and even if you ask, nobody is able to answer it in at least a couple of weeks if ever.
Well, after 25 years you begin to experience back and neck pain and that teaches you something else - you need to spend more time thinking than actually coding, so sitting behind the computer and pushing the buttons you start doing after you get a clear idea what you actually have to do, not just stare at the screen.
I'm a full stack self taught developer kind of working on my own with a couple of clients.
I've started at 15 playing with open source web templates. I'm 33 now.
I've only been at one company for about 4 years in the beginning, so never really had an actual career progression inside a company.
Five years ago, after failing at making a profitable profuct, I went from freelancing alone, to setup a company and hire some devs.
I never liked management, I like to get my hands dirty and build stuff.
Now I'm on my own again, freelancing and trying to get back at building a product.
I sometimes feel that I don't have the time to keep up with new tech, but maybe that's because I need to make more space for that, and also because there are many new things to try.
But anyway, I'm very efficient with my current tech stack (LAMP).
And as others said, one thing is the trendy tech, but the knowledge gained from projects cannot lose its value.
And also, I guess career inside standard companies is great, but who knows maybe in the future you feel like doing something else. Join a startup, build your product, quit coding and be an activist. Who knows. Haha.
Thank you and very true, who knows what will happen in the future, for now I'm just going to focus on what I enjoy which is building cool shit :)
I've been in development actively for the last 15 years and I am still "one of the young ones".
I would say that you cannot "age out", you can maybe be a little behind with learning the current buzz-wordy library. Even if one would want to compare themselves with newer/younger developers, they are coming really late to the market place and still have to catch up with all the business rules of the trade (ie, time management, task plannings, testings, working at a pace of the company, aligning themselves with company vision, application of good programming and development practices, architectures, etc).
I've interviewed a lot of people with 2-5 years of experience and the vast majority of them were like "I want to be a {library-framework} developer, it's really cool and it seems like it is definitely the way to go forward". It's a rare occasion to hear an opinion that {library-framework} is ok because it has a good modularity or ability to extend properly, that xyz framework follows proper SOLID principles or that it has a good data modelling layer. Not to mention that almost no one think about the fact that these libraries weren't there 5 or 6 years ago and that no one can predict the state of them in the following 5 years (at one point everyone swore that jQuery is the best thing there is, now everyone is sworn in the same way on React/Angular/Vue.js).
From my experience, "these kids" will drive a faster pace in the team while "older" members (often-most more experienced) will bring up good practices and stability. This combination is a must have for quality software so that both your company and your clients get the best value for cost (so that your team still gets these "fresh" ideas while retaining stability).
If you expect to be of the same value as you were 10 years ago without any education, it is really unrealistic for our trade. It might be realistic for brick layering, plumbing etc., trades where tools don't change at such fast pace. Our "tools" are fast paced when compared to those trades, but still have a slow enough pace when compared to themselves: you have to educate yourself on the new versions of the tools that you use (your programming language, your framework, your dependency manager, third party libraries, etc) and these are updated every couple of months/years and can be adapted to even a couple of months/years after (just look at the adoption of ES6 and how long it took for everybody to actually use it properly). And you are already getting these "educations" with your day to day work, either through process changes, new libraries, security fixes, etc.
In short, my opinion is that you cannot age-out if you are educating yourself in any way. :)
Thank your for this very in depth response, I appreciate the guidance and reassurance :)
I am new to coding as a professional.
I have education in physics, if we relate your situation to science. Current students still have to learn theories, problems which are nearly 400 years old.
Also Newtown's laws are still in use.
I have no conclusion, just want to push this approach to your discussion.
This is something I am starting to worry about. Whilst I don't believe the "PHP is dead" hype, it's pretty much all I have worked with (and basic front-end stuff) for the last 12 years. I'm trying to get into Vue, but I just don't do enough of it for the way of working to stick.
I think part of my problem is that I've naturally moved to a role where I am doing more planning than coding, and therefore don't get the time to practice as much as I would like. I'm then spending my free time (actually free time, not family time) creating content for my blog, or to help others.
There's just not enough hours in the day, it seems.
"one line of my code worth 10 of new kids" - I like your attitude πͺ
"There ain't no career progression but happiness in what you do everyday." and this π