How to become a senior developer in 2021

Pavel Polívka - Mar 18 '21 - - Dev Community

There is a lot of material online on how to become a senior developer, what you should be able to do as a senior, etc... There are these roadmaps that list a huge amount of technologies, languages, frameworks, etc... you need to learn to become a senior developer. Yes, you can probably succeed while following those. But most likely you will burn out while learning all the minuscule details of Nginx setup or learning session stickiness modes of F5 load balancers.

There must be a better way. Let me take you through my journey of becoming a senior developer, including some tips and facts.

I got my first developer job, right after school. I was going for C# interviews as there was my focus during my studies. The problem with C# at the time was that almost everybody in Pragues just wanted to do a desktop app and I was not interested in doing forms all day long. I wanted a backend job. After few unsuccessful interviews, I decided to broaden my search and went for a Java interview. I did know very few things about the Java ecosystem, I could write basic code and that was about it. I was the most junior out there.

I surprisingly got the job. They were looking for junior people. I had no idea what Maven is, I have never heard about the Spring framework, nothing. In the interview, I got asked to do bubble sort on a whiteboard and complete a take-a-home coding challenge, that aimed to test objective orientated programming, polymorphism, and ability to work with java. I was so green at the time, that I had to Google how to log stuff in Java. Sure thing I choose the most convoluted method out there, but hey at least I was logging.

First few weeks on the job I got to familiarize myself with the used stack. At the time it was Spring framework 3/Hibernate/Freemarker/jQuery used in approximately half of the codebase. The second half was spaghetti code inside the JSP files, calling tons of Oracle stored procedures. Standart corporate legacy code. We had few tutorials on the company wiki, but most of it was spent in official Spring/Maven documentation. After few weeks I felt like I understand enough to read most of the codebase (sure I still was not prepared for the most complicated code related to search relevancy, but nobody ever was).

My work process following those few weeks was something like this. I got assigned a new task. That I was trying to find it in the codebase. Usually doing full-text searches based on the error message or some other UI element. Trying to fully understand the issue. Googling. Lots of googling. Fixing the issue. Testing. Fixing again. Committing. The most important part here is googling. Do not be afraid to take on bigger challenges or issues you do not have a full understanding of the issue. You can always google stuff, there are tons of articles online on almost any topic.

When I got stuck on something. And that was happening a lot in the beginning and still is happening from time to time. It's important not to get stuck for days or weeks. You should always have some teammates around you (or you at least around Slack) that you can ask. I guarantee and most of them will be very happy to help you. We developers love to solve puzzles. Do not go to them ask, this does not work, what to do? Describe what you already tried, what is your idea of possible causes, etc... It should help to make this nice experience. The people you ask those questions probably will not know the answer as well. Senior people should not be know-it-alls. They will look at the problem, try few clicks, and then probably Google.

Everybody Googles. Those who claim that not are not doing their work as efficiently as they could.

So if everybody Googles why there is a difference between juniors and seniors? Everybody can Google stuff out.

Sure everybody can. The problem is that juniors usually do not have the knowledge of the stack, application, language, etc to make the search specific enough. They will probable get there with the combination of googling error messages, describing behavior, etc.. it will just take more time.

A nice example here could be design patterns. Junior may have a hint that some design patterns exist, probably did not use most of them and it's hard to detect what pattern use when. And there is no shame in that. You need to learn something. Senior on the other hand will not most of the patterns, if not by name then at least by use case. He should be able to detect when is the right time to use what pattern. There is absolutely no need for him to memorize all the details of the implementation. There is a difference between googling: "What pattern to use when X?" and "Strategy pattern implementation in Python".

Most companies will have a very complicated stack with tons of apps and technologies. You do not need to learn it all at one go. Most seniors have no idea about everything there. They are just good learners/googlers. I always recommend learning as you go. You start somewhere and the bug solving journey will take you somewhere. If you do not understand it, nevermind. Do some googling, reading. Ask somebody. If you do this for enough time you will be able to look at those horrifying technology roadmaps to become a senior developer and check everything. Noby sits down and learns everything from that list at the start of their career.

Senior should still ask questions. There should always be somebody to pair program. More eyes on the hard problem, better. But with seniority, there should be more questions oriented at business. Senior people in the team should have basic knowledge of how business for the given problem works. Senior should be able to foresee some kind of impact of the change, consult that impact before the change to make sure everybody sees it the same way. You will be doing much more communication as a senior developer. Softskills here is very important.

The most important thing as a senior is to remember to give back. Rember your journey and how helpful everybody was. Be that. If somebody asks you a stupid question, answer and explain. Answers without explanation are useless to most people. Do pair programming with junior people, the learning experience for them is very valuable.


Hope this helps. I am always available to everyone so drop hello at my Twitter.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .