This article will be mostly about personal advice on how to stay in the industry and keep your sanity while being happy. I want to summarize my ideas about this topics as the “Growing Developer Mindset”. So what makes a growing developer?

We, as developers, often hear these horror stories about old developers just disappearing or younger ones replacing them. This is a like night to day difference in comparison to other industries. In other industries, the more senior people are supposed to show the younger ones the ropes.

Why is this happening in IT? How can we avoid to be part of this process?

The reasons

Reasons for this are manifold. Let’s collect the most common ones:

  • As a technical person, you sooner or later might hit a brick wall in terms of compensation. Often the only way of surpassing this wall is to move into a management role. Bye bye, IDE/Editor/all the things you love.
  • You end up with a job which is about maintaining a solution you build in a technology which is not fresh anymore. By “fresh” I mean that greenfield projects are created with it. This is per se nothing too bad, it just means that you could end up being part of a team with other people in the same position. Often this can lead to even really nice paid jobs when the technology is still used to earn money.
  • You worked on some technologies for more than one or two decades, sadly your skills don’t translate too well to other programming paradigms. You get laid off and it is hard to find a job fighting with all the young and hungry developers which probably work for half your salary.

As you can see, there are mostly two groups of reasons. One is that in some companies it is hard to get a better salary when you don’t take responsibility for other people (becoming a manager) and the other that people make themselves hard to hire. How can we overcome all of this?

Staying relevant

After a while, you really feel comfortable using your tech stack at work. You know how to do things the way they are supposed to do. Despite this feeling really nice – you probably shouldn’t get too comfortable.

This feeling is making you slack. Every once in a while you should feel uncomfortable. Uncomfortable because you try things which you don’t know to do at the beginning. These are the things which shape your future.

Learn new technologies

If you do the same thing over 5 years, your CV will look really boring. Probably you did not learn as much in the last 3 years in comparison to your first year.

Which developer would you hire?

The one Java Developer who was working now 10 years on a Spring 2 project or the one having started with two years in Spring 2, migrating to Spring 4 and afterward getting his feet wet in NodeJS and finally adding some experience in Go?

For me, the answer is pretty clear, as long as both of them are not interviewing for a Spring 2 position, the second developer should come out ahead. He just has seen more. The only difficulty the second developer might face, is to convince his future employer that he stays for more than a year – since his past experience might be coming from different employers. In case he made all this experience at one company, this shouldn’t be an issue.

My advice in this area is to just stay “curious”, look for opportunities to learn new things and don’t be afraid. You will learn everything on the way. For me, learning is half the fun while being on the job.

Boy being curious.
Boy being curious

Take responsibility

First things first: I think you don’t need to manage people.

What if I told you that you can take responsibility without managing people? It is sufficient to lead them in some or the other way. You can take a lot of project responsibility or responsibilities for your development process without being the person in charge of hiring and managing other people. As a technical lead, you could define and work on the way projects get implemented.

It pays off (literally) when you are more than a mindless sheep following the herd.

Become a Team Player

Programmers working as a team.
Programmers working as a team

I often read articles about becoming a “10x developer” or a “rockstar developer”. Still I am pretty sure I not yet encountered a 10x developer (if they even exist).

Software is normally written in a team. A team consists of individuals with different skill sets and levels. Hypothetically adding a 10x developer to a 6 person team with average joes would more than double the team performance. On paper this sounds really awesome, doubling the team performance by a single hire.


Coming back to reality: Even if you would find such a high performance person and convince him/her to join your team of average developers, there still would be a lot of issues.

After a while, this developer will solely own a lot of things. When you now think about replacing this single person – it will be really hard. Since by whom is the person going to get replaced? By another team?

I also could see a lot of conflict between our new developer and the existing team, due to him/her trying to introduce concepts the other people don’t understand and are not willing to accept.

The following paragraph is about what I personally think will be a person closest to a 10x developer: You find an experienced great team player who is willing to mentor, lead and teach the other developers. He is also contributing to increasing the overall requirement and development process. When you put the person in front of an editor or an IDE he generates better output than your average developer.

Due to all the efforts of this developer the productivity across the team rises. Even though he is not delivering ten times the results as his teammates. I really believe that the addition of this individual helped the overall team performance a lot.

Other factors are that in this team, it is still possible to shift workload between co-workers and to motivate the remaining developers. The success is not only tied to a single person. Also, I think the person in the second example will be really respected and acknowledge between his fellow developers.

Learn to solve problems instead of focusing on the code

From a business perspective, I tend to say that you won’t get paid for coding. You are getting paid for solving problems. The more experienced you get the more time you will spend with gathering requirements and thinking about whether the things you are supposed to do are even making sense.

Person solving a rubiks cube representing problem solving
Person solving a rubiks cube representing problem solving

This is not only because you might be got promoted to such a position, but also because the past might have taught you that it is worth to spent more time getting the requirements straight. Having the wrong requirements can force you to throw weeks of your implementation away or having to change it to “what your customer really meant” two weeks down the road.


The most important things for becoming and staying a developer are keeping up-to-date, not being afraid to learn new things and pushing your boundaries while also brushing up on your non-coding skills.

By working on these factors, I guarantee you will have a really happy life as a programmer and everybody in your circle will respect you for whom you are. Also in case you eventually want to get away from the code – you will also be well prepared.

Having any comment or feeling about the post? Feel free to reach out via twitter.

About the Author:

Marcus "Mo" Eisele

Marcus is fascinated by technology. He loves learning new things.
He is a Software Engineer at Daimler TSS and has a personal blog at