Starting work as a programmer today is quite a challenge. Sometimes it is a long and difficult road. There are many reasons for that - some come from the current market situation and the fairly strong representation of juniors aspiring to enter the profession, while others come from unrealistic expectations on every side. Mocking memes about the relationship between a candidate's age, expected years of experience, and how long a given technology has existed have already become iconic. It is hard to be 20 years old and have 10 years of experience in a technology that has existed for only a year.

The topic of today's article will definitely not be how to get into IT. That subject has already been discussed many times, including by me, and there is no single good answer to what should be done. The topic will instead be: how long can I, or will I be able to, work as a programmer, and what waits for me afterwards?

Early Retirement

Retirement? Probably, too. The question is whether you will last in this position that long. The profession we are talking about is one of the more stressful ones. Of course, it is hard to compare the stress of an employee sitting at a desk and writing code with the stress of a doctor or firefighter who fights for other people's lives every day. Still, the constant pressure to deliver products of the highest quality, continuous development, and quick problem solving in an environment that is very dynamic and prone to errors is not irrelevant when we try to define how stressful this work can be. We also have to agree that high salaries, fruit Thursdays, and other benefits partly compensate for those bad sides, but do they compensate enough? So the question is whether escaping from a stressful work environment into IT is always a good solution.

According to research conducted among Polish programmers, around 70% of them have experienced burnout. How should we understand that? Burnout is a set of symptoms that appear as a result of physical and emotional overload connected with the work being performed. These symptoms include constant fatigue, lack of satisfaction from work, reluctance toward the workplace or even going there, boredom, pessimism, cynicism, low self-esteem, or lack of interest in professional development. According to various sources, the main culprit is stress. This leads to illnesses such as depression.

It is difficult to recover from burnout. It may seem that leaving the industry would be something completely natural. Even so, many people decide to take a longer break and return - often to a new environment, with new people, in a less stressful project. There are probably several reasons: despite everything, the earnings are good, the work is often a passion for these people, and the need for challenges and self-development is important to them.

So when should one retire? The IT industry is still too young, especially in countries such as Poland, to talk about people employed in it reaching retirement age. Globally, only 2.72% of developers are over 55 years old. As we can see, retirement may happen, but rather as something forced by health. The question is whether it is worth it.

How to Eat an Elephant?

Should a programmer know everything? In principle, it is practically impossible. The learning curve in technical professions that develop as dynamically as programming does means that discovering new things constantly reveals new paths, and those paths expose new unexplored areas. The Polish saying works perfectly here: the deeper into the forest, the more trees.

A typical situation, then, is receiving tasks at work that we do not know how to complete. Lack of knowledge in a given area requires, first, the ability to learn quickly, and second, the willingness to step outside one's own comfort zone. When sources such as documentation or examples are available, this kind of work, although difficult and stressful, can still be inspiring. It is worse when we add a short deadline and only fragmentary knowledge about the topic.

That is when the right "eating an elephant" technique becomes useful. Our task is exactly such an elephant, and we have to eat it. The technique is based on starting with the simplest things to do and combining them for as long as needed until we get something larger, and eventually - our "elephant".

Impostor Syndrome

By digging further into difficult tasks and continuous development, we arrive at a common psychological phenomenon - impostor syndrome. It consists in stopping believing in our own abilities and clearly downplaying our skills. People affected by impostor syndrome very often live with the conviction that they did not deserve the success they have achieved and that they are deceiving others. The paradox is that it has affected at least 70% of the entire global population at least once in their lives.

Impostor syndrome very often blocks our further development. People affected by it very often stop growing because they are afraid they will be exposed. This problem can be fought. We need to remember that we reach every success in small steps. There are certain techniques that help us increase our self-confidence, such as helping coworkers.

Impostor syndrome is problematic because it accelerates burnout. Development is necessary, but fear of development effectively limits us and deepens stress.

Right or Left?

Working as a programmer is not only about writing code. In many cases, it requires making important project decisions that will stay with us at later stages of the project's life. There are no people who can predict what will happen after some amount of time. This de facto means that we are not able to clearly determine whether a decision made at the beginning was correct - it is easier to assume that it was not. Following that path, we should be prepared to change it and rebuild our project around those changes. Incorrect analyses can, in extreme cases, lead to the need to kill the project and start from scratch.

A few years ago, a funny but very accurate graphic appeared on the devstyle.pl fan page. According to it, programming takes about 10% of working time. The rest is fighting people, fighting machines, and fighting yourself. It is hard to disagree with that. Fighting machines means all situations where something does not work although it should. Fighting people is most often about attempts to gather requirements and understand the business domain in order to create something useful. Fighting yourself means continuous development and omnipresent procrastination.

The path programmers follow is, above all, a technological path. For the first years, it is the most important one. The areas in which we develop allow us to become specialists in a given topic. Eventually we reach the senior or principal level, but even then not much changes when it comes to the profession itself. A junior and a senior have very similar tasks, a similar distribution of activities, and similar results are expected from them. So what distinguishes a junior from a senior? In my opinion, it is a set of non-obvious skills, such as estimating tasks, noticing risks that seem insignificant at first glance, or choosing technologies more consciously for the requirements without focusing only on things one already knows, as well as experience. Experience is not equal to experience - we will evaluate it differently if we spend 10 years in one project in a corporation, and differently if we change projects 5 times over a period of 10 years.

Above senior there is nothing left. Further development depends only on the direction we want to take. We have to choose - the technical path, the management path, or a return to the beginning.

Technical Path

This is probably the most obvious road - as seniors, we have gained a lot of technical experience. We have broad knowledge of different technologies and have probably written in more than one language. We do certain things very consciously, and we see the weak and strong sides of different approaches. The next step would therefore be becoming an architect. Who is an architect?

A software architect usually does not code. This is a person who designs whole systems in order to choose the most optimal solution for the business problem. Interestingly, this profession was born together with the whole industry. At first, an architect was a slightly more experienced programmer - over time, however, systems began to grow to enormous sizes. Today, it is the architect who has a complete picture of the whole project, which allows them to move between different teams and help them develop their parts according to the assumptions that have been made.

What is important - an architect must always stay up to date. They should understand new things, not be afraid of them, but also be able to look at them critically.

Management Path

Contrary to appearances, there are not many architects on the market. Because of the requirements of this position and the enormous knowledge that is needed, many programmers choose the second path - the management path. The matter is much simpler here - we start by becoming a Team Leader or Project Manager. Because of our technical knowledge, it is easier for us to communicate with technical teams and define the goals of the team and the project.

Unfortunately, in many cases this means giving up writing code and focusing instead on developing soft skills and skills related to leading people and projects.

Or Maybe a Return to the Roots?

Another idea may be to step back to a junior position in a completely new technology. This gives a fresh perspective and a chance to gain new experience, but often also means reducing one's previous salary. Personally, I know a few people who made this move and, from today's perspective, do not regret it. Today they understand more and look more consciously at both backend and frontend. They walk the same path again more consciously - only to stand once more at the same kind of choice at the end.

Crunch

One of the most stress-generating areas of IT is GameDev. It usually requires the greatest knowledge, deadlines are very short, there is a mass of work, and the expected quality should be really high - in the end, these products go to a rather demanding group of recipients. If we add to that the lowest salaries in the whole industry and phenomena such as crunch, we will probably discourage every reasonably thinking person from working in game production. Unless it is a passion...

What is crunch? It is a phenomenon involving forced overtime work during game production. More than once it means being at work for 65-80 hours without breaks, often without additional pay for overtime hours. This phenomenon is so common that organizations such as Game Workers Unite fight it officially, but despite attempts to defeat it - it exists and is doing well.

And unfortunately, success does not always stand behind crunch. Let us look at Cyberpunk 2077, whose employees worked in this mode. Fortunately, they were in Poland, so at least they were paid for overtime according to the applicable law. We know what Cyberpunk looked like at launch - perhaps it is better to leave that without comment.

Expired?

If we analyze the above, the profession of programmer has many advantages. Above all, it gives incredible development opportunities, good earnings, and a chance to get to know the world from a slightly different side - a very good programmer has to understand the domain before writing the first line of code. Okay, maybe I exaggerated a little with that last statement, but I hope I managed to convey the point.

The advantages above reduce the stress that comes from work, but they do not eliminate it. That is exactly why more and more people are "escaping paradise". Time and result pressure, a closed-off environment, and pathologies resulting from corporate work all affect people. My goal is not to scare anyone away from working in IT - my goal is to make people aware that this world also has its dark sides. For a person from outside this world, gaining the minimum knowledge usually means giving up time with friends, hobbies, and building relationships with loved ones during the first few months of learning. I have seen this more than once. I experienced it myself too, although in my case I started quite early, as a 22-year-old, without family baggage.

Summary

Answering the question asked at the beginning of this article: what is a programmer's expiration date? In most situations, a few or a dozen years. People who find an extension of their career path, or those with high resistance to stress, will probably last longer. How much longer? I do not know. It is very individual.

I do know one thing, however - certain stressors can be eliminated or at least softened in how they affect people, and that often depends on companies and the managers working in them.