Contents
Hello!
My name is Benoit and I have been working as a software developer for the last 8 years. I worked at my previous (and first) company for 7.5 years, and at the beginning of 2022 I moved to a new one.
This article is the result of a recent introspection about what I should have started doing in my career earlier and what I would have done differently if I had the opportunity to go back in time.
What I’m sharing here can be useful to any Junior or Middle developer who wants to improve and advance to the Senior level and beyond. The tips in this article are mostly about so-called soft skills, I will go through technical skills separately in the second part.
My Career Path
Before moving on to the main topic, I will briefly tell you about the evolution of my career:
-
In the beginning, I interned for three months at a fast-growing startup.
-
After that, I worked for a whole year under the program Work&Study, in which I studied for 3 months and worked for 9 months.
-
Then I got a full-time job as a Software Engineer and worked in this position for 3.5 years.
-
Shortly after the introduction of the grading system, I was promoted to Senior Software Engineer. I kept that grade for three years until I left the company, at which time I had about 200 technicians.
-
Finally, I started working as a Software Engineer in a company with thousands of technicians. In spite of the downgrade (see Big Tech Hiring is Conservative — But Why?), I tried to keep the same functional responsibilities as before.
In the beginning, I was part of the front-end team. Development was divided into backend and front-end developers. At that time, there were about 30 of us engineers. When a new CTO came in a year later, he introduced an organization based on feature-teams: Spotify Model. And while there was some friction in the beginning (people don’t like change), this reorganization was definitely for the better.
I’ve worked in the same feature team for more than five years. I’ve been in it since the beginning, so I’ve become the technical leader of the project over the years. Eventually, I moved to another team, where I worked for a year, and then I got a job at another company.
What I Should Have Started Doing Earlier
Keep a Work Log
A work log is a document with a list of tasks you have completed. The level of detail and the type of tasks don’t matter, as long as you keep track of what you’ve done.
The document can be filled out at a convenient frequency, I would advise you to do it weekly. The memory of tasks completed during the week is still fresh on Friday, so you won’t have a hard time writing them down.
Why is a workbook important? For two reasons:
-
To remind yourself of everything you’ve done in the last six months to a year. This is very important during performance reviews to show your boss what you have achieved and why you deserve a raise or a higher grade.
-
Track projects, visible responsibilities, and critical metrics (e.g., X % latency reduction for a mission-critical service). This will help a lot when writing a resume when you want to enter the job market.
I started keeping a work journal about two years before I left my first company. So for the last 8.5 years, my workbook only contains three years of data (with some gaps). When I was writing my resume at the end of 2021, I had to rely on my memory to remember what I did in the first five years of my career. It took me a long time to remember all the valuables, and I’m sure I forgot something.
If you wish, you can use the Work Templateof his journal (here is the example). Personally, I used Microsoft Notes for the first two years and then switched to Google Docs.
Stepping out of your comfort zone
This is the best way to learn something new and become a better developer. A comfort zone is an area where you feel comfortable doing your job. It’s the team you already know and work with on a daily basis, projects you’ve been working on for years, responsibilities you’ve been carrying for a long time, and so on.
But why do I advise you to leave this beautiful place? Because this environment is not suitable for significant development.
Of course, being in this bubble is still efficient. You already know who to talk to about a particular topic and which file in the codebase you need to change. But what’s better than one efficient person? A few efficient people!
Once you’ve reached your comfort zone on a particular topic, you should:
-
Become a mentor for other people so that they, in turn, also feel comfortable in this topic.
-
Looking for something new outside of your comfort zone.
Mentoring is one of the responsibilities that is expected from a Senior-level position. It’s a great way to help colleagues become more efficient quickly. By teaching others, you become a multiplier of power.
As for new cases, it can be anything. Here’s a list for inspiration:
-
Take part in a project that you didn’t have the opportunity to touch before, for example, because it was always assigned to the same person (who was in their comfort zone).
-
Write documentation on a topic that is close to your heart. The goal is to share your knowledge and indirectly mentor people so that they can gain that knowledge faster than you. In addition, writing is a useful skill that is worth learning, whether it’s documentation, letters, messages, RFCs (Requests For Comments), blog articles, etc.
-
Voluntarily participate in cross-team projects. You can even take a leadership position in them, which will kill two birds with one stone.
-
Improve tools, monitoring, or processes in your team or organization.
-
Participate in meetings organized by the company.
-
Join company communities to work on projects at a higher and cross-team level.
-
Assist the team in recruiting by conducting technical interviews and/or checking candidates’ test tasks.
The goal is to learn something new. Performance reviews help you determine what to do and how to do it, stepping outside of your comfort zone. But you don’t have to wait until that moment to make a move. You can start doing this at any time if your manager knows about it. For example, you can talk about it during a 1-1 meeting. One of your boss’s main jobs is to help you advance your career, so I highly recommend talking to them before you leave your comfort zone.
Perhaps there are topics that you don’t really care about. In my case, I didn’t want to learn anything related to machine learning and data analytics for a long time. But my natural curiosity and thirst for knowledge eventually led me to study these topics. And while I didn’t have the chance to work on the company’s projects related to these areas, I’m glad I learned about them. It’s great to have meaningful conversations with my colleagues, and it also helps me come up with ideas that I wouldn’t have been able to come to without this knowledge.
If you want to advance your career, I highly recommend that you leave your comfort zone and learn new things at every opportunity. And I’m sure this advice applies to your personal life as well!
Be interested in other teams and projects
This point is close to the previous one, although you don’t have to take on additional responsibility.
For a long time, I wasn’t interested in teams and projects that weren’t within my team’s scope. Our product had dependencies on services owned by other teams, but as long as the API between them and us was clearly defined, we didn’t need to know anything about their services.
The only time we had to open the box and see how things worked was when we had to contribute to these projects. Since we were organized into feature teams, if we needed some changes in one of the company’s other projects, we had to make them ourselves. Each feature team had its own roadmap, so we couldn’t ask another team to do the work for us. Although we worked slowly at first, with the help of another team, we gradually became more efficient at contributing to their projects.
But as for the other teams/units that we didn’t interact with directly, I had no idea how they worked and what their role was in the system. It wasn’t until I joined the oncall team, years later, that I started to really learn all of the company’s services. When I finally got the full picture, then:
-
I’ve become more aware of what can be the reason when something goes wrong.
-
I began to understand why we needed this particular service or why we chose this particular data warehouse.
-
Finally putting it all together, after years of working for the company, I had an amazing feeling: “Oh, now I get it.”
If you have the opportunity, look at other projects and teams within the company. Read their internal wiki pages, visit their demos, check out their public documentation. This can be done from time to time, it doesn’t have to be a full-time activity. Bonus: If you can draw a diagram and write documentation about the “big picture,” do it. There’s a chance that many people in the organization will thank you for this!
Note that you don’t need to produce anything here, unlike the previous advice about the comfort zone. All you need is to be curious, read other teams’ documentation, and ask questions. Along the way, you may meet people from other teams and discover projects that you’ll really want to work on.
Join the on-call team
This advice may seem controversial, or it may not be possible at all in your company. Of course, you should heed this advice only if your company has a healthy on-call atmosphere (see On-call Compensation for Developers).
An on-call team consists of people who are ready to intervene if something goes wrong during and outside of working hours, i.e. at night, on weekends and holidays. Perhaps your company has SRE Teamand/or your team may not be responsible for DevOps work.
But if you have the opportunity to join an on-call team, whether it’s for the product you’re working on or for the entire company (depending on its size), I’d suggest doing so.
I see the following benefits here:
-
You’ll learn a lot about the behind-the-scenes products and services that make the company thrive.
-
You’ll begin to understand your co-workers better as you’ll feel the weight of responsibility when something bad happens, especially at night.
-
You’ll feel more involved in the company’s operations as you invest more of your time in making sure that products and services work as customers expect.
But before taking on this responsibility, it is necessary to create favorable conditions for on-call work.
At my first company, I joined the on-call team (which was in charge of all services) about two months before leaving. I wish I had done this sooner, as I learned a lot in those couple of months and that extra responsibility paid well.
In my second and current company, I joined the on-call team (which is responsible for maintaining one product) two to three months after the first day of work. For now, I only work during working hours, but over time I will be able to respond at night and on weekends.
Change team
In which cases it makes sense to try to move to another team:
-
You’re too comfortable in your current position and would like to step out of your comfort zone.
-
You don’t really like the team’s projects/tasks and would like to work on projects that you like better.
-
Relationships with colleagues and/or your boss have deteriorated, and you want a better work environment while staying with the company.
If you find yourself in one of these situations, then I advise you to think about a new team rather than immediately quitting and looking for a new company.
Changing companies can be exhausting, and you can also lose what you really value in your current company, such as colleagues, engineering culture, comfortable environments, or employee benefits.
I believe that switching teams can be great for the following reasons:
-
The organization of a new team may be different (rituals, ways of working together), so you get more experience in this area.
-
You can bring positive changes that you learned in the previous team — improve the code review process, tools, libraries, rituals. And as a result, become a conduit of excellence in your company.
-
You can help new colleagues when they have to work on projects that belonged to the previous ones.her team. In this way, knowledge will be effectively disseminated from one team to another.
-
You can learn new tools, languages, libraries, architectures, ways to solve problems. In other words, to become a better developer.
-
You may have the opportunity to work in better conditions if your transition is due to the 2 or 3 reasons mentioned earlier.
A year before leaving my first company, I decided to move to another team. Several teams have invited me to join them, and if I could split into several parts, I would happily join them all.
When I joined the new team, I felt that my title of Senior Programmer was no longer legitimate. I had to learn new codebases, tools, and practices. Of course, I kept my soft skills and business/product knowledge, but my technical skills suffered. Learning new things is great, of course, but I was no longer a technical leader on the team. Although, when the new team had to participate in my previous team’s projects, I was able to help them more effectively. Over time, the imposter feeling faded and I grew as I gained more skills.
However, I don’t think it’s a good idea to change teams too often. I worked for my first team for over five years, then moved to a new team for a year and ended up leaving the company for reasons unrelated to this new team.
If you feel that your situation is similar to one of the above, I would advise you to consider switching teams, but only if you have been in the current one for at least one full year. I believe that one year is a reasonable amount of time to understand whether you belong to your current team or not. If you can’t wait a whole year, then the situation is quite critical, and I would advise bringing in a manager to solve an urgent problem.
Write Blog Posts
This point should have been just “Write”, but it seemed too short to me. Writing skills are one of the most important skills a developer should have. Most of our day-to-day work involves writing text: code, messages, letters, documentation, RFCs, meeting notes, postmortems, etc.
Writing is one of the best asynchronous ways to communicate with people. Messages can be read at any convenient time without interruption in the middle of a task. Of course, in some situations, synchronous communication is the best way to communicate: video call, face-to-face meetings to solve some urgent problem or to clear up ambiguity and misinterpretation. But in my experience, developers write more than they talk on a daily basis.
Writing articles is useful for the following reasons:
-
Practice is the way to perfection. If you’re not sure you’re doing it right, you can ask for help from someone who you think is doing it well so they can mentor you in the matter. The most important thing is to start practicing, even if your first articles are flawed.
-
The goal of writing an article will make you understand the chosen topic. It’s a great way to learn something new, consolidate knowledge, or understand something at a higher level.
-
It develops your personal brand. The more people are interested in your articles, the more followers you get and the more visible you become.
You can write articles for your personal blog and/or your company’s blog. Writing for your company is a great option at the initial stage since it already has a subscriber base. However, you will have less freedom in choosing the topic you want to talk about since it is the choice of the company.
Don’t expect to become popular after the first publication – it takes a lot of time. You may never even reach that point, and that’s okay. You have to write for yourself, improve your writing skills, and share your discoveries with the community. You shouldn’t care how many likes or followers you get. Yes, recognition and positive evaluation are nice, but the goal should not be to increase these numbers, but to improve your articles and share knowledge.
I started this journey by posting on the engineering blog of my first company: The most accurate way to schedule a function in a web browser. She even got a mention in the newsletter JavaScript Weekly, which was very nice.
Then, in March 2021, I started writing blog articles on Dev.to And I continue to do it from time to time. I’ve also posted Article on HackerNoon but I didn’t like the way they edited title and I decided that my main place to blog would be Dev.to, at least not yet.
What I wish I could do differently if I went back in time
Be More Careful When Making Global Changes
This is especially true the older you get, although even juniors should feel able to implement new things into the team, whether it’s libraries, languages, paradigms, ways of collaborating, and so on. As a junior, it’s easier for you to take on challenges from senior team members. However, the older you get, the easier it becomes to convince people, especially the less experienced ones, to follow the innovations.
Back at my first company, a few months before I moved to another team, I found myself in a position where I could propose ambitious changes to the codebase. By that time, I had been studying the functional programming paradigm for several years and was confident in its benefits.
Over the course of several months, I introduced functional concepts to two teams, including my own. For your information, these presentations took place before I made major changes to the codebase.
I believed that these trainings were enough to convince colleagues to accept the new paradigm. And at that moment, it really was. They understood new concepts, the pros and cons, and what we could use to improve our designs.
At some point after these presentations, we saw an opportunity to:
-
It was at the beginning of summer, so business activity will be lower than usual for several months.
-
In the first half of the year, we ran into a few bugs and had to use crutches in one of our old systems.
-
We could radically improve the testability and developer usability of this system by using functional concepts and types of TypeScript (aka TS). This old system was originally developed on an early version of TS, which didn’t provide a lot of type capabilities.
In other words, it was the perfect time to refactor! I showed the team a proof of concept using functional programming and type programming with TS to greatly improve this system. We were all convinced of its advantages and decided to go further by creating a production-ready version. I was responsible for creating tasks, planning what could be done in parallel, etc. I was regularly posting updates in a Slack channel where stakeholders could follow the progress.
I developed the second version of the system as a library in our own codebase, making it an independent module where we could test all the possible edge cases we could think of with unit tests, so the side effects were finally under control. Despite the introduction of many new concepts, features, and code changes, everyone didn’t mind. I received support during the code review.
I was very inspired by the library fp-ts, the way of coding can be said to be different from “regular JavaScript”. We couldn’t just import the library into our codebase due to limitations I won’t mention here, so I had to re-implement some of its features and data types myself, with a few adaptations. I made several presentations about these changes and received positive feedback.
The lack of objections motivated me to continue to delve deeper into this topic.
Once the new system was finished and tested, we had to replace the old system that was scattered all over the codebase. It was used in many places, so the transition from the old system to the new was Very much Tedious.
I’ve never worked so hard in my life. I liked to refactor old code to what I thought was a better version, so I didn’t count working hours. For 2 months, I must have spent about 10 hours a day working, including weekends.
When the work was finished, I took 2 weeks off (they had been planned for a long time). While I was gone, the team unfortunately ran into a rather important incident. They struggled to identify the root cause and find a way to fix it. The problem was somewhere within the new system, which was nothing like the rest of the codebase. The team wasn’t familiar with it, as I was developing it almost single-handedly.
During the presentations I gave, people understood these new tools and practices and accepted the changes. But when they found themselves alone with the innovations, they rightly felt lost.
Presentations are a good thing, of course.Oh, if you don’t put into practice what you’ve just learned, you’ll eventually forget about it. Also, presenting each concept separately is not the same as using them all together. This complicates an already difficult subject to study.
To make a long story short, I introduced a lot of new concepts to my team, and while they were on top of all my presentations, the changes I made to the project prevented them from solving a critical problem while I was away.
When I came back and found out about this incident, I suggested that they give more presentations so they could become more familiar with the new code.
In fact, I shouldn’t have gone down that rabbit hole in the first place. It was not a pragmatic decision. Improving the types was a good idea, but the whole new functional system was a mistake.
Don’t make important changes to your team just because you’re happy with them. You have to keep in mind Bus Factor. I thought I’d stay on that team long enough for everyone to eventually get familiar with the new code, and I could teach them a little bit.
But a few months after these events, I moved to another team. Looking back, I feel guilty for abandoning this hard-to-maintain module months before leaving the team, and for nearly burning out because of it.
Whether you’re an individual developer (aka IC, individual contributor) or a manager, if a senior team member makes important changes like these, I strongly advise you to challenge their suggestion. I’m sure a better solution could have been found in my case.
If you are in the same position as me, I encourage you to think twice before making a decision. Is this really a pragmatic solution? Are you sure that the scope has been identified and the risks have been identified? Are you doing it for the good of the team or because you enjoy it? Will the team be ok with this solution when you’re not around to help?
Don’t let emotions get the best of your team
There were times when I strongly disagreed with what a manager or colleague told the team during a rally. I would let everyone in the room know that I was concerned about this, and in this way I would start a “conflict” in public.
I wanted to show my colleagues that it’s okay to disagree with someone else’s decision. However, this behavior is not healthy:
-
People may feel uncomfortable when conflict becomes visible/obvious, as in these situations. It is unfair to put them in such situations.
-
This can lead to a split in the team, with some agreeing with Person A and others agreeing with Person B. The team must remain united to be effective.
-
Generally speaking, losing control of one’s emotions is indicative of a lack of self-control and discipline, as well as an inability to take a step back and think through the situation.
I’m not saying it’s easy to keep your emotions in check. After all, we are human beings, not machines. But it’s also important to show respect for your colleagues and not disrupt the flow of the meeting.
In my opinion, in such a situation, it would be best to wait until the end of the meeting, and then immediately:
-
Talk to this person in a 1-1 meeting.
-
Or talk about the situation with your boss and find a way to fix it.
It is important to have this 1-1 meeting right after the situation that caused you to have a rush of emotions. The more time passes, the worse the situation becomes.
In my experience, talking to another person has always helped to improve the situation. Communication is key. Without social interactions, we won’t be able to get very far in the company (or in our personal lives).
Monitor the labor market from time to time
When I joined my first company as an intern, I had a 30-minute interview with my future manager. And that’s it. I went through a quick “cultural fit” interview and was accepted.
After that, I didn’t enter the job market for seven and a half years. When I finally decided to change jobs, my one and only experience of employment was clearly not in line with what I was about to face. The hiring process when you apply for a Senior position with about 8 years of experience definitely doesn’t consist of just a “30-minute behavioral interview.”
After reading the book The Most Heated Tech Job Market in History I felt ready to give it a try. I’ve updated my LinkedIn profile to “searching.”
I felt depressed. It was exhausting to deal with all the suggestions that poured at me on a daily basisIn 2014, the Netherlands announced that it From September 2021 to the end of October 2021, I received probably 5 to 10 offers per working day. I had to take time off to cope, and I spent a significant portion of my weekends doing so.
At first, I was able to respond to every message from a recruiter. But at some point, I found myself in a situation where:
-
I had to work all day, as I was still working at my current company at the time.
-
I was in the process of moving to another city, which was quite stressful for me.
-
I was constantly getting new job offers.
It became increasingly difficult to respond to messages from recruiters.
As a result, I wrote a message template with wishes for the next work. I provided as many details as possible: the size of the company, the engineering culture, the remote format, compensation, technical tasks, and so on. But despite this, I still didn’t have time to respond to all the messages.
I want to say to all the recruiters who contacted me at the time and to whom I never responded: I’m so sorry. I was just stunned by the situation.
But replying to messages on LinkedIn wasn’t the hardest part. The most exhausting were the interviews. I never had the opportunity to do DSA (Data Structures and Algorithms) training as I didn’t feel the need to change the company.
I trained mostly on leetcode, and also bought a few books that helped me:
-
Cracking the Coding Interview, Gayle Laakmann McDowell.
-
System Design Interview Volume 1, by Alex Xu.
In addition, I needed to recall and present in detail some of the most significant projects I had worked on. This is where the work log we’ve already talked about can be a useful tool.
When I finally accepted the offer, I wrote a letter of resignation. If I remember correctly, I received a 25% salary increase back then, as well as additional compensation and generally better conditions for employees in my situation (remote work).
The reason why I recommend that you have interviews from time to time is as follows:
-
You’ll gain experience, and when it’s time to move to a new company, you’ll feel less overwhelmed.
-
You’ll be able to find out how much you’re worth in the market and possibly ask for a salary adjustment at your current company. If you get an offer, then it’s likely to help you get what you think you deserve in your current place even more.
At my first company, I received good salary increases (7 to 10% per year), except for the last year. Even though I wasn’t happy with the salary I was getting last year, I thought I would still get an even higher raise next year.
Since I have been paid a good salary for most of my career at this company, I have never had a desire to know what I am worth in the job market. I wish I had done it sooner. That doesn’t necessarily mean I would have left the company sooner, but at least I would have gained some experience and maybe asked for a raise instead of a raise.
Don’t get me wrong: getting a 10% raise is a good thing. But if your salary is 15-20% lower than what the market is telling you about your value, then in the end, even a 10% raise won’t be enough. And how do you know if you have the compensation you deserve? Having experienced this market for myself. As well as keeping in touch with former colleagues who have experienced this market themselves.
Passing interviews doesn’t force you to leave the company. You can go through dozens of interviews while staying at your current company, as long as your work tasks don’t suffer. That’s why I had to take time off, conduct interviews early in the morning and during my lunch break.
Conclusion
First of all, thanks for reading this far! I hope this article was at least helpful to you in some way.
One last thing I wanted to share with you: keep in touch with former colleagues, especially those who inspired you. These are people you admired because they did a great job by your own standards. Perhaps they were great managers or influential tech executives that you valued very much. They may even invite you to join their company or even team on occasion. Each person can create a network of contacts that will help them become a better person.
And you can take a step towards professional development and career growth by visiting the openOTUS lessons, where IT experts share up-to-date knowledge and experience. See the schedule of events in the calendar.
———-
Acknowledgement and Usage Notice
The editorial team at TechBurst Magazine acknowledges the invaluable contribution of the author of the original article that forms the foundation of our publication. We sincerely appreciate the author’s work. All images in this publication are sourced directly from the original article, where a reference to the author’s profile is provided as well. This publication respects the author’s rights and enhances the visibility of their original work. If there are any concerns or the author wishes to discuss this matter further, we welcome an open dialogue to address potential issues and find an amicable resolution. Feel free to contact us through the ‘Contact Us’ section; the link is available in the website footer.