Developer expiration date

When will a developer retire? And will they even make it that far while working in this profession? In today’s article, I talk about burnout, crunch culture, and the career paths available once you reach the senior level.

Bad and rotten apple. Ugly trendy bad apple on wooden background⁠ PAGES.POST.COVER_THUMBNAIL.BY_WHOM Qwart

From this article you will learn:

  • How common is burnout in the IT industry?

  • What is the “eating the elephant” technique?

  • What is the impostor syndrome?

  • Who does a developer have to fight against?

  • What career paths are available after reaching the senior level?

  • What does a software architect do?

Starting a career as a developer today is quite a challenge. Sometimes the path is long and difficult. There are many reasons for this - partly due to the current state of the job market and the strong representation of aspiring juniors, and partly due to unrealistic expectations on both sides. The sarcastic memes joking about the relationship between a candidate’s age, expected years of experience, and the actual age of a given technology have become a classic by now. It’s hard to be 20 years old with 10 years of experience in a technology that has existed for only a year.

The topic of today’s article is definitely not "how to get into IT "- that has been covered many times, including by me, and there is no single correct answer to what one should do. Instead, the topic is: how long can I work as a developer, and what comes after?

Early retirement

Retirement? Possibly - but will you make it that far? The profession we’re talking about is one of the more stressful jobs out there. Of course, it’s hard to compare the stress of someone sitting at a desk writing code with the stress faced by doctors or firefighters who fight for people’s lives every day. Still, constant pressure to deliver high-quality products, continuous learning, and rapid problem-solving in a dynamic and error-prone environment has a significant impact on how stressful this work can be.

It’s also true that high salaries, fruit Thursdays and other benefits partially compensate for the bad parts - but is it enough? So the question remains: is escaping a stressful work environment into IT always a good solution?

According to surveys among Polish developers, around 70% have experienced burnout. What does that mean? Burnout is a set of symptoms that appear as a result of physical and emotional overload at work. These include: chronic fatigue, lack of job satisfaction, reluctance to go to work, boredom, pessimism, cynicism, low self-esteem, and lack of interest in professional development. According to various sources, the main culprit is stress, which can lead to conditions such as depression.

Recovering from burnout is difficult. Leaving the industry seems like a natural step, yet many people decide to take a longer break and return — often to a new environment, with new people, and a less stressful project. Why? Probably several reasons: good pay despite everything, passion for the job, and the desire for challenges and personal growth.

So when should a developer retire? The IT industry is still too young, especially in countries like Poland, to meaningfully talk about a typical retirement age for developers. Globally, only 2.72% of developers are over the age of 55. Retirement may happen — but most likely for health reasons. Is it worth it?

How to eat an elephant?

Should a developer know everything? In practice, this is impossible. Learning in technical fields that evolve as fast as programming constantly uncovers new paths and new unexplored areas. The old saying applies perfectly: the deeper you go into the forest, the more trees you see.

It is typical to receive tasks at work that you don’t yet know how to do. Lack of knowledge requires two things: the ability to learn quickly and the willingness to leave your comfort zone. When documentation and examples are available, such work-though difficult and stressful-can still be inspiring. It’s worse when you add tight deadlines and scarce information.

This is where the "eating the elephant" technique becomes useful. Our task is the elephant we must consume. The idea is simple: start by completing the smallest pieces of work, combine them gradually, and eventually you will build the whole-your "elephant."

Impostor syndrome

When discussing difficult tasks and continuous growth, we arrive at a widespread psychological phenomenon: impostor syndrome. It manifests as a lack of belief in one’s abilities, constantly downplaying one’s competence. People affected often feel they don’t deserve their success and that they are deceiving others. Paradoxically, at least 70% of the global population has experienced it at least once.

Impostor syndrome often blocks further development. Many people stop learning because they fear they will be "exposed". But this can be fought. It is important to remember that every success is achieved through small steps. Techniques such as helping colleagues can help rebuild self-confidence.

Unfortunately, impostor syndrome also accelerates burnout. Growth is necessary, but fear of it increases stress.

Right or left?

Being a developer is not just writing code. In many cases, the job requires making important project decisions that will affect the project’s future. No one can foresee the future, which means we often can’t know whether a decision made early in a project was correct. It’s safer to assume it wasn’t - and therefore be prepared to change or even rebuild the project when needed. Poor analysis can sometimes lead to killing the project entirely and starting over.

A humorous and accurate graphic was published years ago on the devstyle.pl fanpage. According to it, coding takes about 10% of a developer’s time; the rest is fighting with machines, fighting with people, and fighting with yourself. Hard to disagree. Fighting with machines means things not working when they should. Fighting with people means gathering requirements and understanding the business domain. Fighting with yourself means ongoing self-development and constant procrastination.

The typical path for developers is mainly a technical path. For the first years, this is most important. The areas we focus on shape us into specialists. Eventually we reach senior or principal level - but even then, the job itself doesn’t change drastically. Juniors and seniors often do similar tasks with similar expectations. So what’s the difference? In my view: non-obvious skills like estimation, risk awareness, more conscious technology decisions (not only based on what you already know), and experience. And not all experience is equal - ten years in a single corporate project is not the same as switching projects five times in a decade.

Above senior level, nothing is predefined. Future growth depends entirely on which direction you choose - technical, managerial, or starting over.

Technical path

This is the most obvious path - as seniors, we have accumulated solid technical experience. We understand multiple technologies, likely have used more than one language, and write code more consciously. The next step is often to become an architect.

A software architect rarely codes. They design entire systems, choosing the most optimal solutions for the business problem. This role emerged alongside the growth of the industry itself. Initially, an architect was simply a more experienced developer - but as systems grew in complexity and scale, the role became more specialized. Today, an architect has a holistic view of the entire system and helps multiple teams build their parts according to the shared design.

An architect must always stay up-to-date, understand new technologies, embrace them, but also evaluate them critically.

Managerial path

There are not many architects on the market, given the requirements and knowledge needed. That’s why many developers choose the management path instead. Here the route is simpler: becoming a Team Leader or Project Manager. Technical knowledge helps communicate with engineering teams and define goals.

Unfortunately, this often means giving up coding in favor of developing soft skills and leadership abilities.

Back to the roots?

Another idea is to step back and become a junior again - in a completely new technology. This brings fresh perspective and new experience but often means a pay cut. I know several people who took this path and do not regret it. Today they understand back-end and front-end more consciously. They walk the same path again - only better prepared.

Crunch

One of the most stressful areas in IT is GameDev. It demands deep knowledge, tight deadlines, heavy workload, and high quality - because the audience is demanding. Add the lowest salaries in the entire IT market and phenomena like crunch, and it’s hard to encourage anyone reasonable to join the industry. Unless it’s a passion...

Crunch is forced overtime during game production. People often work 65–80 hours per week, with no breaks and often no additional pay. The phenomenon is so widespread that organizations like Game Workers Unite fight it formally - but despite efforts, it still exists.

And crunch doesn’t always result in success - look at Cyberpunk 2077. Despite the developers working in crunch mode (fortunately in Poland, meaning they were paid for overtime), we know how the launch looked. Better left uncommented.

Expired?

If we analyze all the above, the developer profession has many advantages. It offers amazing growth opportunities, good salaries, and a chance to see the world from a different angle - the best developers have to understand the domain before writing their first line of code. Okay, maybe that’s an exaggeration, but the point stands.

These advantages reduce stress but don’t eliminate it. That’s why more and more people "escape from paradise." Time pressure, performance expectations, hermetic environments, and corporate pathologies all take a toll.

My goal is not to scare anyone away from IT - but to highlight that this world has its darker sides. For someone outside the industry, even acquiring basic knowledge often means giving up time with friends, hobbies, or family for several months. I’ve seen it many times. I’ve gone through it myself, though I started early, at 22, without family responsibilities.

Summary

So what is the "expiration date" of a developer? In most cases, a few years to a decade. Those who find further career paths or have a high tolerance for stress may last longer. How long? I don’t know - it’s highly individual.

But I do know this: many "stressors" can be reduced or mitigated, and this often depends on companies and the managers working in them.

Share this article:

Comments (0)

    No one has posted anything yet, but that means.... you may be the first.

You may be interested in

If this article interested you, check out other materials related to it thematically. Below you will find articles and podcast episodes authored by me, as well as books I recommend that expand on this topic.

undefined by undefined
Article
18 December 2021

Szalony rok

Moje podsumowanie roku 2021. Był to rok bardzo wymagający, ale jednocześnie utwierdzający mnie w przekonaniu, że to co robię, ma sens. W tym artykule poruszam tematy, które stały się dla mnie ważne i opisuję swoje plany na kolejny rok.

Read more

Zapisz się do newslettera

Bądź na bieżąco z nowymi materiałami, ćwiczeniami i ciekawostkami ze świata IT. Dołącz do mnie.