One of the reasons senior developers stop growing in their careers is learning new technologies.
Reality
Every day, an unbelievable amount of content about new technologies appears on the web. Examples of how to work with them.
How something has been done wrong until now. Suddenly, there is a new technology and it solves this whole problem.
It is often exactly the problem that is being solved on my project at work.
It would be enough to switch to this new technology and we would have it solved.
So I take a look at this new technology and learn it, so that I can then go to the project manager and tell him how great it is and that we should apply it to our project.
Then I come to the project manager full of excitement… and he tells me that there is no time to rebuild this part of the project.
But maybe, when a new project starts in half a year, there could be space. We’ll see!
Half a year later… there is still no space.
In the meantime, I spent hours exploring this new technology. Learning how to work with it. Slowly becoming a “theoretical expert”.
Well, so I complain about it with my fellow developers. We share other technologies that they have been learning instead.
A few of them catch my attention so much that I add them to my learning backlog and look at them in my free time so I can talk about them with my colleagues a bit more.
Even the project manager seems to like these – he says that maybe on a new project in half a year we would use them…
Reality (from the other side)
I am a project manager. One of my responsibilities is the economics of the project. Less money has to go into it than the company later gets from selling the application.
I know that some decisions in the past were not the best, the team of developers tells me that quite often. In some parts, we struggle with the limitations of the technology we use.
But so far, we have always managed to find some workaround. Clients are, in the end, mostly satisfied with how the application works and they buy it. That is always the main thing.
Did it cost us a few extra hours to come up with and implement a workaround? That is still defendable to company leadership. A small deviation from estimates is expected.
Then one of my most experienced developers comes to me. He says he found some technology that could replace the previous one. That sounds interesting!
We talk about it together. The key information for me is that by changing this technology we could save time that we spend fixing or working around the previous one.
Hmm, but then math and the mentioned economics hit.
We implemented the previous technology in 3 months at the beginning. The dev tells me we would have to replace it completely. So another 3 months of work for the whole team.
The math is quick: 12 weeks, 3 devs = 1440 hours of work (+/- some small differences). The company would have to pay for it.
If we ever work on a workaround again, even if one developer spends 20 hours on it, there would have to be over 70 such workarounds for it to cost us more.
That doesn’t even include the fact that this technology is so new that only this one dev understands it now, the rest of the team would have to learn it.
Nor that during that whole time we would not release any new feature, because we would be digging into technical debt.
Maybe I could push work on technical debt at the start of the next project… Even though I doubt it, I don’t want to disappoint the devs, so I will at least bring it up to the bosses.
Oh, the developers are here with 3 more proposed changes. So there is really no chance that everything would pass… The project has to make money. If it doesn’t, the company will shut it down and we might all lose our jobs.
Reality (objective)
New technologies are nice. Useful. Always better than their predecessors.
But it is not possible to apply them always. On the contrary, they can often be applied only on a completely new project that starts from scratch.
Because every change of technology essentially means a complete implementation from scratch. A lot of capacity has to be invested into that.
Business, in order to have money to pay salaries, has to think about economics. A company exists to be in profit – that is its purpose. If it did not have this purpose, it would stop being a business.
Saving time and money, fixed roadmaps, production… all of these are things that the business has to focus on.
So if something still works, the company has no reason to change it, even if it is 10 years old. Such a change does not make sense – it is simply too expensive.
The project you are paid for uses a specific set of technologies.
You get paid for knowing the ones that are in that set.
Not for another 50 outside this stack.
So when you learn new technologies, the application you work on in your company is not the place where you could apply them.
At most, you might apply them on your own personal project.
This way, you keep learning more and more technologies, but the hours you invest into that learning are not reflected in opportunities where you would use it.
And in the end, not even in your salary.
Learning technologies has always moved you forward
“That’s nonsense. My whole career I’ve been learning new technologies and my salary grows, my position too!”
You are used to learning technologies working great for your career.
In the junior and mid-level phase, that is really the case.
At that time, you are improving exactly in those established technologies,
even though they are new to you.
This way, over the years of programming, you build a false feeling that it will work like this forever. It becomes a fact, empirically verified.
At the moment when those established technologies run out, you automatically slip into “learn more new technologies”. Simply out of habit.
Another false impression is that increasing employability means career growth. It is not growth, it is just movement.
Career growth means increasing your perceived value. With higher perceived value comes a higher salary.
Employability is just quantity. Not quality.
More projects will want you, but they will pay you the same.
Because their tech stack is also limited and they want you to know their few technologies – for others outside their stack, they have no reason to pay you. They don’t need them from you.
What follows from this?
Graph to support what I mentioned above (graph is available only in Czech, sorry!):
At a certain point in your career, learning new technologies becomes a sideways move.
Will it open opportunities in more projects or companies? Yes.
Will it lead to higher perceived value (and therefore salary)? No.
Not because technologies are bad, but because you are optimizing the wrong axis.
If your goal is not to increase your value, or you simply enjoy learning technologies, feel free to continue. That is completely fine.
But don’t expect it to move your career forward the way it used to.
How to increase perceived value?
There are many competencies (= knowledge, abilities and skills) that are overshadowed in our careers by how strong the influence of technology is.
To name a few:
- Effective decision-making
- Communication
- Presentation
- Facilitation
- Leadership
- Delegation
- Strategy
- …
There are quite a lot of them. Feel free to take a look at Step 4 of my mentoring framework, what it roughly includes.
You learn them passively throughout your whole career, some less, some more.
If you start training them actively, you will significantly increase your perceived value.
They are universal – useful for any position or vision of your future and even not only for career growth, but also for personal growth.
Where to start?
Take the first step. Stop asking:
“What other technology should I learn?”
and start asking:
“How does the whole project actually work?”
Because at that moment, your career starts moving forward again.