Especially if you are an older developer (I’m 45) and you will just be seen as just another old out of touch developer.
That being said, the further down the stack you go, the more stability there is in technology.
A lot of jobs exist where they just want to know you can code and assume you’ll learn what you need as you go along. Experience in their languages seems most important.
By the time I got back out on the market ten years later, I was already 35 and I was able to talk about projects, architecture, trade offs involved in shipping, etc and I was applying for mid level roles - partially because I had become an expert beginner “engineer” even though I was good “developer” and they were getting me cheaply.
Eight years and three jobs later, my engineering skills had caught up with my age and I was applying for jobs where they needed a “change agent” or “someone who could speak experience into the team”. Now, I rarely get asked any programming questions. It’s mostly architectural and soft skill questions.
But, in the grand scheme of things. There are only two reasons anyone is interviewing for a job. Either they are being forced to find another job because of a layoff or the current environment has become inhospitable or they are choosing to find another job for more money/new challenges.
In the former case, where I need to find a job now, I need my resume to be buzzword compliant so I can find a job/contract fast. I also need to be ready to for more technical interviews especially for contracting.
In the latter case, I can be more picky and find jobs where they are looking for “principal developers”/team lead type of positions and the interviews tend to be more architectural/theoretical.
On a side note, I’m not sure what I want to do next. If I choose the cloud consulting/“digital transformation consultant”/“enterprise solution architect/consultant” route. Knowing a little about everything will come in handy - including something like Graph QL.
I like the insight here about the two types of job and looking back at my jobs I think this is spot on.
There is another reason to change jobs which is for lifestyle reasons. Moving country, changing to a work from home/digital nomad would come under that. In the lifestyle case you are probably trading other factors for the lifestyle factor, so that would also more likely lead to the buzzword compliant route.
a) Focus on technologies that have staying power. I don't think Java EE jobs will really ever disappear
b) instead of flavour of the month, focus on the flavour of the decade? i.e. Go and Kubernetes seems to be the trend :)
c) instead of resume-driven development, focus on having a network. Most of my jobs have merged because a former colleague, classmate or friend realized I knew some programming once, and they might want me to work for them :)
More in depth, I think you can make a trade-off between the tried and tested and the new-fangled thing, by introducing the new in your current job. Technologies that are not cutting edge, but slightly past the first peak on the hype-curve. I.e. if you do backend, you would probably try Go language (instead of Rust/Elixir/...), on frontend you could introduce Type-script (instead of other compile-to-js languages), you might try Kubernetes ... in general technoligies with following that are still new, but with more than five years in production at some places it puts them outside of the 'flavour of the month'
B) There are still a relatively few jobs in Go and they don’t seem to be paying more than your standard enterprise language. I’m not wasting my time learning a language/technology with both a smaller market and no pay premium.
But K8s while I think is overhyped and something being chased because of the ooh shiny effect, it is the type of technology I would jump on, insist on a pay premium and ride the hype curve.
C) you still need to do RDD. Who you know will only get you so far. Who you know gives you the inside scoop on opportunities but you get jobs based on what you know. No one is going to stick their neck out for someone who is objectively unqualified.
I can keep up with that from talking to former managers, former coworkers, my network of local recruiters, recruiters job listings, LinkedIn posts, Indeed job listings, etc.
For example. Let’s say from all over those sources I see the following trends.
Senior consultant positions (in my case AWS). There are relatively few jobs in my local market compared to everything else that pay enough to make me jump ship just for the money. But when they do become open. I’m building my resume and skillset to be qualified for these types of jobs. If I leave my company on my own terms, I can wait until the perfect position opens up. If I need to find a job now I can’t afford to wait and it’s too risky for me to over specialize in an area where local jobs aren’t plentiful.
On that same note, the only reason I am specializing in AWS instead of Azure is because that’s the job I ended up in. Even though the market for AWS is much larger than Azure, the Azure market is more than large enough so it doesn’t matter. GCP on the other hand...
If I take that same mentality to Java, C#, and Go, the same thing applies. Java is more popular in the enterprise, but C# is popular enough that you can quickly find a job, it’s hard to ask for above average compensation just for a developer job since there are plenty of people who can do it “well enough” to develop your bog standard SAAS CRUD app or bespoke internal app. But they pay well enough. The cost of living is relatively low in Atlanta.
On the other hand, I don’t see that many jobs for Go developers locally and when they do appear, the salary is the same as C# and Java. Why specialize in a language where the demand is lower and the compensation is the same - unlike AWS Consulting.
Learning Go would mean I am neither optimizing for salary or for optionality to find a job quickly.
Of course, it’s always good to have Javascript in your back pocket because of the web and it’s used for server side code, desktop apps, and cross platform mobile apps.
As far as my next career move, I am not sure. Extra money would always be nice, but cloud consulting/enterprise consulting doesn’t excite me. I have a decent work life balance and I enjoy my current stability.
On the other hand, I am getting bored with developing, a change of pace would be nice and increasing my savings and investments wouldn’t hurt.
In reality, you probably mix bit-of-collum-a/bit-of-collum-b.
> That being said, the further down the stack you go, the more stability there is in technology.
IME, it's about where you go and not what level of the stack.
Some places are just fine with a basic form-based website with a little JS for convenience that ultimately just talks to an IBM mainframe. Others want full-blown SPA in the latest, greatest Hipster language deployed across a dozen datacenters with Kubernetes and whatever other trimmings.
If the market is paying higher than market salaries for the buzzword compliant “digital transformation consultant”, that’s what I will learn.
As we speak, banks are migrating from systems written in cobol/fortran to systems written in java. I just got quite a few recruiters contacting me for open java jobs. Sure, frontend code was in angular and they offered training for it, but for some even angular might be considered to be "ancient" because they're living in a react bubble (not saying that you are).
When the day comes that I do decide to leave my job and I leave by choice, I’m staying buzzword compliant enough to be an overpriced “cloud consultant”, “digital transportation consultant” or whatever the hype of the day is.
But, I wouldn’t take a job doing Angular knowing that React is more popular and I would rather add React to my resume than Angular.
Don’t get me wrong, those things are problems that need to be addressed, but in my limited experience it doesn’t seem to be as common as it might appear.
Networking like that is how I found my job without a degree in computer science.
I only started really job hopping and taking my career seriously 10 years ago at 35. I’ve always had at least a half a dozen interviews and a minuscule number of rejections. My network got me to the interview without going through an ATS. My Resume Driven Development and knowing the game got me offers.
Ageism outside of the cool hip startup world is exaggerated. Most of the older developers confuse ageism with not keeping their skillset in sync with the market.
Maybe my English is not that good, how do you mean? Asking as a 43yo developer.
As far as staying relevant, I’ve developed a network of trusted local external recruiters and I speak with them to see what companies want.
When I’ve been looking for a job, I’ve found jobs where I have the listed “must have” skills and I want the “nice to have” skills. Rinse and repeat.
I don’t do non work related side projects. I will work extra hours and volunteer for a low risk project using new to me technology just to learn.
I want to say that I would change jobs if I saw the technology that my current company is using is out of sync with the job market all other things being equal. But, every job change I’ve done in the past decade has come with both more pay and more resume building opportunities.
Now after job hopping and following my own advice for a decade, I’ve reached close to the local market (Atlanta) maximum unless I start working for a consulting company (not contracting/staff augmentation).
Whether I am actively looking for a job or not, optionality is important.
I am not advocating not learning things for 20 years. I think it is ok to skip 1-2 years, then you check state and learn framework, relax, learn something fun, relax, learn framework, repeat.always one not all.
Luckily, right now, everything is in the right place for my current job.
- they are paying me above the local median (we are talking Atlanta here not Silicon Valley)
- the technology stack we are using is not bleeding edge but in the right place in the hype cycle.
- I think they will continue to do so for the next two years.
But you’re right. I’m not going to spend my time learning the latest frameworks if I am not going to use it at my current job and I don’t see myself in the market within six months. But if my company ever got too far behind the market, I would have to start preparing.
learn stan (still relevant technology despite being one of the oldest in its domain). learn image processing. learn database administration.
How many companies need someone who specializes in “image processing”? Soon, if it’s not already a commodity library that any company can leverage.
If you want to be a general hire, then you will suffer competing with generalists (this is not a bad thing just a different strategy). You can choose to become an expert on a general skill (or trendy framework). This is useful and highly marketable, but your competition pool is also larger and the technology is still likely to dissolve over time.
Also, for DBA , I think i'm internally thinking Data Engineering instead. I perhaps misspoke by title.
The browser and front end code - just sticking with Microsoft, the popular method has been classic ASP, ASP.Net Web Forms and ASP.Net MVC and ASP.Net Web API and they both have changed significantly after Core. Not to mention that the industry has moved away from server side rendering to client side rendering. The popular client side framework seems to change every year.
The next level down is a server side language, let’s assume that we are doing client side rendering. When I really got serious about my career in 2008, after staying at a job for a decade, job listings were looking for C# and Java. Those are still two of the most popular enterprise languages. While of course both languages have evolved in 10 years, it’s mostly syntactic sugar. If you were in a coma for 10 years, you could wake up and easily understand code in either.
Databases - back in 2001, I was working as a backend developer writing batch jobs to load data into MySQL and Sql server databases and do reports. Now, I’m still working with MySQL doing some ETL as part of my job. What I learned back then is still applicable. The difference between those two databases now and the front end framework of the day is like night and day.
Web servers. I don’t deal with web servers that much anymore (see below), but when I do, it’s still IIS, dealing with IIS hasn’t changed much in 15+ years.
Networking/Infrastructure. I’ve had to deal a little with the networking in the early 2000s, but I didn’t get back into the infrastructure side until two years ago with AWS. Everything made perfect sense. The basics of TCP/IP, servers, load balancers, etc hasn’t changed in decades. While AWS is always adding things, nothing you learn is ever obsolete unlike the framework of the day.