Hello, and welcome!

My name is Benoit. I have been a software engineer for the past eight and a half years. I stayed at my previous (and first) company for seven and a half years, then I joined a new one in early 2022.

This article comes from a recent self-reflection on the things I wish I had started doing earlier in my career and the things I wish I had done differently.

What I am sharing here may be useful to any junior to mid-level developer who wishes to improve and progress toward the title of senior and beyond.

Before diving into the main subject, here is my career evolution:

1. I interned for three months at a startup (which quickly became a scale-up) company.

2. After that, I did a full year of work-study, spending three months at school and nine months at work.

3. Then, I got hired as a full-time software engineer and kept this title for three and a half years.

4. Quickly after the introduction of the tech career ladder, I got promoted to senior software engineer. I kept this title for three years until I left the company, at which point the tech teams accounted for approximately 200 people.

5. I joined as a software engineer 2 at a company with thousands of tech employees. Despite the title downgrade at the second company (see Big Tech Hiring is Conservative — But Why?), I have been trying to keep the same responsibilities (and more) as before.

n the beginning, I was part of the frontend team. The tech organisation was split between backend and frontend developers. At that time, we were no more than 30 engineers. When our new CTO arrived a year later, he introduced an organisation based on feature teams: the Spotify Model. Although there was some friction at the start (people don’t like change), this reorganisation definitely turned out to be for the better.

I stayed for more than five years in the same feature team. I was there at its inception, so throughout the years, I became the tech referent of the project. Eventually, I joined another team, where I worked until I left for a whole new adventure a year later.

All right, enough with the context. I hope you’ll enjoy reading the rest, and that the following advice will be actionable for your career progression!

A work log is a document that contains the list of tasks you accomplished. The granularity and the type of tasks don’t matter, as long as you keep track of what you did.

You can fill in this document at the frequency you want. I would advise doing that on a weekly basis. Tasks done during the week are still fresh on Friday, so you won’t struggle writing them down.

Why is this work log important? For the following two reasons:

• To remind yourself of all the things you have done over the past 6 to 12 months. This is very valuable during performance reviews, so you can show your manager what you have accomplished and why you deserve that raise or promotion.

• To keep track of projects, notable responsibilities, and critical numbers (e.g., decreased latency by X% for a critical service) that you had over your career. This is great for completing your resume, whenever you want to venture into the waters of the hiring market.

I started writing a work log roughly two years before leaving my first company. So, over the past eight and a half years, my work log contains only three years of data (with some gaps here and there). When I had to write my resume in late 2021, I had to rely on my memory to remember what I did during the first five years of my career. To say the least, it took me some time to remember everything valuable, and I’m sure I forgot some of them.

You can use a work log template if you want to (here is an example). Personally, I have been using Microsoft Notes for the first two years, then I switched to a Google Doc with bullet points (one list for each month of the year).

This is the best way to learn and become a better developer. The comfort zone is the scope, environment in which you feel comfortable doing your job. It is the teammates you already know and work with daily, the projects you have been working on for years, the responsibilities you have been carrying, and so on.

But why would someone advise you to leave this wonderful situation? Because this environment is not suitable for evolution.

Sure, if you stay in this bubble, you are an efficient person. You already know who to talk to about a specific subject, and what file in the codebase has to be changed. But what is better than one efficient person? Several efficient people!

Once you have reached the comfort zone on a particular topic, you should look for:

• Mentoring people, so they become comfortable with this topic.

• Look for something new to do outside of your comfort zone.

Mentoring is one of the responsibilities that is expected from a senior position. It is a great way of helping our coworkers to be more efficient quickly. You become a force multiplier.

As for the new things to do, it could be anything. Here is a non-exhaustive list for inspiration:

• Contribute to a team/organisation project you never had the chance to touch before, e.g., because it was always assigned to the same person (who was in their comfort zone).

• Write documentation about a topic you are comfortable with. The objective is to share your knowledge and indirectly mentor people so they can get this knowledge faster than you did. Also, writing is a great skill to learn and improve, be it for documentation, emails, instant messages, RFCs (Requests For Comments), blog posts, etc.

• Volunteer to participate in cross-team projects. You can even take a leadership position during these projects to feed two birds with one hand.

• Take care of improving tooling, monitoring, or team/organisation processes.

• Participate in meetups organised by the company.

• Join a community/guild at the company to work on org-level, cross-teams projects.

• Help the hiring team by conducting technical interviews, and/or checking take-home exercises from candidates.

The goal is to learn something new. Performance reviews can help you define what to do, and how to do it when stepping outside your comfort zone. But you don’t have to wait for this moment to make the move. You can do that at any time, as long as your manager is aware of it. For instance, you can talk about it during a 1–1 meeting. One of the core objectives of your manager is to help you progress in your career, so I highly recommend talking with them before leaving your comfort zone.

There may be some subjects you don’t really care about. In my case, for a long time, I didn’t want to learn anything related to machine learning and data analytics. But, my curiosity and thirst for knowledge eventually led me on the path of these topics. Even though I didn’t get the chance to work on company projects based on these fields, I am glad I learned about them. It is great to have meaningful conversations with my peers, and it can even help me find ideas I couldn’t get without this knowledge.

If you want to progress in your career, I strongly encourage you to leave your comfort zone and learn new things every time you get the chance. And I’m pretty sure this advice also applies to one’s personal life too!

This one is close to the previous one, though you don’t have to endorse additional responsibility.

For a long time, I did not care about teams and projects outside my team’s scope. Our product had some dependencies with services owned by other teams, but as long as the API between them and us was clearly defined, we didn’t have 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. As we were organised in feature teams, if we needed some changes in one of the other projects of the company, we had to make these changes ourselves. Each feature team had its own roadmap, so we couldn’t ask another team to do the work for us. Although we were slow at first, with the help of the other team, we progressively became more efficient when contributing to their projects.

But, for the other services that we didn’t directly interact with, I had no idea how they worked, and what was their precise role in the system. It was when I joined the on-call team, years later, that I really started having a look at all the services of the company. When I finally got the full picture, it felt great.

• I had a better understanding of what the culprit could be when things went wrong.

• I knew why we needed that particular service or why we made that data store choice.

• Finally, piecing everything together, after years of bringing value to the company, provided an awesome feeling of “Ohhh, now I get it.”

If you can, take a look at the other projects and teams at your company. Read their internal wiki pages, attend their demos, and read their public documentation. This is something you can do from time to time; it doesn’t have to be a sustained effort. Bonus: if you can draw a diagram and write some documentation about the “full picture,” do it. Chances are a lot of people in the organisation will thank you for that!

Notice that you do not have to produce anything here, compared to the previous advice regarding the comfort zone. All you need is to be curious, read documentation from the other teams, and ask questions. You might meet people from other teams along the way, and you may discover projects that you really want to work on.

This one may feel controversial, and it may not even be possible at your company. Of course, you should consider this advice only if your company has a healthy on-call environment (see On-call Compensation for Software Engineers).

The on-call team is composed of people who are willing to intervene if something goes wrong during and outside business hours, i.e., at night, during weekends, and on bank holidays. Your company may have a dedicated team of SREs (Site Reliability Engineers) for it, and/or your team may not be responsible for DevOps work.

But, if you have the possibility to join the on-call team, whether it’s for the product you work on, or for the whole company (depending on its size), I would suggest doing it.

Here’s some advantages of joining this team:

• You learn a lot about the “behind the scenes” of the products and services that make the company thrive.

• You feel more empathetic to your coworkers, as you experience the weight of responsibility whenever something bad occurs, especially at night.

• You feel more engaged with the company, as you invest more of your time into making sure the products and services work as expected for the customers.

Again, a healthy on-call environment is required before embracing these responsibilities.

At my first company, I joined the on-call team (who was responsible for all the services) approximately two months before leaving. I wish I had joined earlier, as I learned a lot during these few months, and this additional responsibility was well compensated.

At my second and current company, I joined the on-call team (who is responsible for the services of a single product) two to three months after my first day. For now, I am only intervening during business hours, but eventually, I will be able to respond to pages during the night and on the weekends.

I can see three reasons why you would move to another team:

• You are too comfortable in your current position, and you would like to go out of your comfort zone.

• You don’t really like the projects/scope of the team, and you wish to work on projects that you enjoy more.

• The relations with your coworkers and/or manager have deteriorated, and you want some fresh air while still being part of the company.

If you see yourself in one of these situations, then I encourage you to consider a new team instead of resigning and looking for a new company.

Changing to a new company is exhausting, and you may lose things that you really appreciated, such as coworkers, the engineering culture, or employee benefits.

I think team hopping is great for the following reasons:

• The organisation of the new team may be different (rituals, ways of working together), so you get more experience in this field.

• You can bring positive changes that you learned from the previous team (improve the code review process, tools, libraries, and rituals), thus becoming a good practices advocate at your company.

• You can help your new teammates when they have to work on the projects owned by your previous team (i.e., knowledge spreading efficiently from one team to the other).

• You can learn new tools, languages, libraries, architectures, and ways of solving problems. In other words, become a better developer.

• Possibly, you get to work in better conditions if your change is due to reasons 2 or 3 mentioned earlier.

One year before leaving my first company, I decided to move to another team. Several teams asked me to join them, and if I could have split myself into multiple parts, I would have gladly joined them all.

When I joined the new team, I felt like my senior title was not legitimate anymore. I had to learn new codebases, tools, and practices. Sure, I kept my soft skills and my knowledge about the business/products, but my technical skills took a hit. Learning something new was great, of course, but I wasn’t the technical referent of the team anymore. Though, whenever the team had to contribute to the projects of my previous team, I could help them in a more efficient way. Through time, the feeling of “not deserving my title” faded away, and I became even better as I gathered more skills.

That being said, I think changing teams should not happen too frequently. I stayed at my first team for more than five years, then switched to the new one for one year, and eventually left the company for reasons unrelated to this new team.

If you feel like your situation fits in one of these three reasons, I would advise you to consider changing, but only if you stayed at least one full year with your current team. I think one year is a reasonable amount of time to feel if you belong with your current team or not. If you cannot wait for a whole year, then it means the situation is quite critical, and I would suggest involving your manager, and/or their manager to address the urgency.

This one should just be “Write,” but it felt too short. Writing is one of the most important skills a developer should have. A lot of our daily work involves writing: code, messages, emails, documentation, RFCs, meeting notes, incident post-mortems, etc.

Writing is one of the best asynchronous ways of communicating with people. They can read your messages whenever it suits them, and they are not interrupted in the middle of their task and can focus on it. Of course, in some situations, synchronous communication is a better way of communicating, i.e., video calls, in-person meetings, etc., to address some urgency or remove ambiguity and misinterpretations. But in my experience, developers are more exposed to writing than talking on a daily basis.

Writing blog posts is interesting for the following reasons:

• Practice makes perfect. The only way to improve a skill is by practising it. If you are not sure you are doing it right, you may ask for help from someone who does it well in your opinion, so they can mentor you on this topic. You can also read documentation and blog posts about it. That being said, the most important thing is to start practicing, even if your first articles have some flaws.

• It forces you to know the subject you are talking about. This is a great way of actually learning things — by diving deeper than usual into a specific subject.

• It develops your personal brand. The more people are interested in your blog posts, the more followers you get and the more influential you become.

You can write articles on your personal blog, and/or on your company’s blog. Writing for your company is great at the beginning because it already has a base of readers and followers. However, you have less freedom on the subject you want to talk about, as it’s the company’s choice.

Do not expect to become popular after the first blog post. It takes a long time to become influential. You might even never reach that moment, and that’s fine. You should write for YOU, to improve your writing skills, and share your discoveries with the community. You should not care about how many likes or followers you get. Yes, it is a great moral boost to get that type of recognition, but your goal should not be to increase these numbers. Your goal should always be to improve your writing and share knowledge.

I started this journey by publishing on my first company’s engineering blog: The most accurate way to schedule a function in a web browser. It even got a mention in the JavaScript Weekly newsletter, which felt awesome.

Then, in March 2021, I started writing blog posts on Dev.to, and I continue doing so occasionally. I also posted an article on HackerNoon, but I didn’t really like their editing on the title, and I felt like Dev.to would be my main blog medium, at least for now.

This is especially true the more senior you become, though even juniors should feel capable of introducing new things to the team, be it libraries, languages, paradigms, ways of working together, and so on. As a junior, you will be more easily challenged by the senior folks on your team. However, the more senior you become, the easier it gets to convince people, especially juniors, to be onboard.

Back at my first company, a few months before moving to another team, I was in a position where I could propose… ambitious changes to the codebase. At that point, I had been learning about the Functional Programming paradigm for a couple of years, and I was convinced of its advantages.

Over a few months, I introduced functional concepts to two teams, including mine. For the record, these presentations occurred before I introduced the heavy changes to the codebase.

I thought these training sessions sufficiently convinced people to adopt this new paradigm. And at that moment, it was true: people were nodding their heads. They understood the new concepts, the pros and cons, and what we could use to improve our projects.

At one point, after these presentations, we saw an opportunity:

• It was at the beginning of the summer, so business activity would be quite slow for a couple of months.

• Over the first half of the year, we encountered a few bugs and had to use dirty workarounds in one of our oldest systems.

• We could drastically improve the testability and developer experience of that system, using functional concepts and the types of TypeScript (aka, TS). That old system was initially developed as an early version of TS that did not provide great type features.

In other words, it was the perfect time to do some refactoring! I showed a proof of concept to the team, using functional and type-level programming with TS, to greatly improve that system. We were all convinced of its benefits and decided to go further with a production-ready implementation. I was responsible for creating the tasks, planning what could be done in parallel, etc. I posted regular updates to a Slack channel where stakeholders could follow the progress.

I developed the v2 of the system as a library within our own codebase, making it an independent module where it was possible to test every possible edge case we could think of, with unit tests since side effects were finally under control. Despite introducing a lot of new concepts, functions, and code changes, everyone was fine with it. I got approvals during code reviews.

I was heavily inspired by the fp-ts library, which has a way of coding that differs from “regular JavaScript,” some could say. We couldn’t simply import the library in our codebase due to constraints I will not mention here, so I had to reintroduce some of its functions and data types myself, with minor adaptations. I shared more presentations about these changes and got positive feedback.

The lack of opposition led me to continue deeper into the rabbit hole.

Once the new system was finished and tested, we had to replace the old system that was scattered everywhere in the codebase. It was used in a lot of places, so making the migration from the old system to the new proved to be very tedious.

I had never overworked so much in my life. I loved refactoring the old code to what I thought was a better version, so I didn’t count the hours. Over two months, I must have spent around ten hours a day working on it, including weekends.

Once the work was done, I took two weeks off (they were already planned for a long time). While I was gone, the team was unfortunate to get a quite important incident. They struggled to identify the root cause and to find a fix for it. The issue was located inside the new system, which didn’t look like the rest of the codebase. The team wasn’t familiar with it, as I was pretty much the only one who developed it.

During my presentations, people understood these new tools and practices and agreed with the changes. But, once they were alone in the middle of all this novelty, they rightfully felt lost.

Presentations are a thing, but if you don’t practice what you just learned, you will eventually forget it. Plus, presenting each concept separately is not the same as using them altogether. It adds complexity to an already-difficult subject to learn.

Long story short, I introduced a lot of new concepts to my team, and while they were on board during my presentations, the changes I brought to the project greatly damaged their ability to fix a critical issue while I was gone.

When I got back and learned about this incident, I offered to share more presentations with them so that they could get more familiar with the new code.

In reality, I should have never gone down the rabbit hole in the first place. It was not a pragmatic solution. The type improvements were great, but the whole new functional system was a mistake.

You should not bring important changes to the team just because you are comfortable with these changes. You have to keep the bus factor in mind. I thought I would stay in that team for long enough that everyone would eventually be familiar with the new code, and that I could teach them little by little.

But, a few months after these events, I joined another team. Looking back, I feel bad for dropping this hard-to-maintain module a few months before leaving them and almost burning myself out because of it.

Whether you are an individual contributor (aka IC) or a manager, if a senior teammate introduces important changes like these ones, I strongly advise you to really challenge their proposition. I am sure a better tradeoff could have been found in my case.

If you are in the same position as I was, I encourage you to think twice before committing. Is this really a pragmatic solution? Are you sure the scope is well defined and rabbit holes well identified? Are you doing this for the good of the team or because you like it? Will the team be comfortable with it when you aren’t around to help them?

I’ve had moments where I strongly disagreed with whatever a manager or coworker was sharing with the team during a meeting. I let everyone in the room know it bothered me, thus starting a “conflict” publicly.

I wanted to show my peers it was fine to disagree with someone else’s decision. However, this type of behaviour is not healthy:

• People may feel uncomfortable when a conflict becomes visible/obvious, like in these situations. It’s not fair to put them into these situations.

• This may create division within the team, where some agree with person A, and others agree with person B. A team must remain united to be efficient.

• Generally speaking, it shows some lack of self-control and discipline, and some inability to take a step back and think about the situation.

I am not saying that it’s easy to contain our emotions. After all, we are human beings, not machines. But, it is also important to show respect to our peers and avoid disturbing the course of the meeting.

In my opinion, the right thing to do is to wait for the end of the meeting, then immediately:

• Go talk to the other person in a 1–1 meeting.

• Talk to your manager about the situation, and find a way to fix it.

It is important to trigger this 1–1 immediately after the meeting that made you feel this rush of emotions. The more time passes, the worse the situation gets.

In my experience, talking with the other person always helped in improving the situation. Communication is the key here. Without social interactions, we cannot go far in a company (or our personal lives).

When I joined the first company as an intern, I had a 30-minute interview with my future manager. And that’s it. I did a quick “culture-fit” interview, and I was accepted.

After that, I didn’t set foot on the hiring market for seven and a half years. Once I decided to leave, my single and brief hiring market experience was clearly not representative of what I was about to deal with. The hiring process when you apply for senior positions with approximately eight years of experience is definitely not composed of just a “30-minute behavioural interview.”

After reading The Most Heated Tech Job Market in History, I felt I was ready to try it. I updated my LinkedIn profile, then set myself as “open to work.”

I felt overwhelmed. Dealing with all the job propositions that rained down on me was exhausting. From September 2021 to the end of October 2021, I must have received 5 to 10 propositions per business day. I had to take PTOs (Personal Time Off) to address the situation, and I spent a significant amount of my weekends dealing with it.

Initially, I was able to answer every recruiter's message. But, when I was in a situation where:

• I had to work all day, as I was still employed at my current company at that time.

• I was in the middle of moving to another city, which was quite stressful for me.

• I was engaged in the hiring process of several companies.

• I kept receiving new job propositions.

It became increasingly hard to answer all of the new messages from recruiters.

I ended up writing my own message template containing my wishes for the next job. I shared as many details as I could: size of the company, engineering culture, remote work, compensation, technical challenges, and so on. But despite this, I couldn’t keep up with all the messages.

To all the recruiters that contacted me at that time, and to whom I never got the chance to answer, I am sorry. I was overwhelmed by the situation.

But dealing with LinkedIn messages was not the most difficult part of it. The most exhausting part was actually doing the interviews. I never got the chance to train DSA (Data Structures and Algorithms) before, as I never felt the need to change companies.

I trained mainly on leetcode, and I also bought a few books to help me:

• Cracking the Coding Interview by Gayle Laakmann McDowell.

• System Design Interview Volume 1 by Alex Xu.

In addition, I had to remember and present some of the most impactful projects I worked on in detail. This is where the work log we mentioned previously could be a very interesting asset.

Once I finally accepted an offer, I handed the resignation to my manager. If I remember correctly, I got a +25% base salary increase with this new offer. There was some additional compensation included and overall better employee benefits for my situation (working remotely).

The reason why I encourage you to try interviewing from time to time is for this:

• You will get some experience along the way, so when you finally join a new company, you will feel less overwhelmed.

• You can check your worth on the market and potentially ask for some compensation adjustments at your current company. If you can get a job offer, chances are it will help you get what you think you deserve at your current position.

At my first company, I got good salary raises (between 7% and 10% year-on-year), except for the last year. Despite not being satisfied with the one I got in the last year, I thought I would have gotten an even better raise the next year anyway. That moment never came as I quit before it happened.

Since I got good raises for most of my career at that company, I never felt like checking what I was worth in the hiring market. I wish I had done that earlier. That doesn’t necessarily mean I would have left the company earlier, but at least I would have gotten some experience, and I could have possibly asked for a salary adjustment instead of a raise.

Don’t get me wrong: getting a 10% raise is great. But if your salary is 15% to 20% below what the market tells you you are worth, in the end, that 10% raise isn’t good enough. And how can you know if you have the compensation you deserve? By experiencing that market yourself. Also, by staying in touch with former coworkers that experienced the market themselves.

Doing interviews doesn’t force you to leave the company. You can do tens of interviews while staying at your current company, as long as you don’t sacrifice your work for doing interviews. This is why I had to take PTOs, and I had to do interviews early in the morning and during lunch breaks.

First of all, thank you for reading so far! I hope this article was useful to you. I think you noticed all this advice is not really technical. Most of them are about soft skills. Maybe I’ll write another article with advice that is more about technical skills or hard skills. Let me know if you would be interested in such content.

One last thing I wanted to share with you: stay in touch with some of your former coworkers, especially those who inspired you. They are people you admired because they did a great job according to your standards. They may have been excellent managers or influential technical leaders that you really appreciated. This is important because they will help you improve and become a better developer. They may even convince you to join their company/team, which is healthy as long as the frequency is reasonable. Everyone should build a network that helps them become better people.

If you have the occasion to try this advice out, and if it works out for you, please share your experience. I am really curious to get feedback about this advice and see if it can apply to other situations than my own.

As always, feel free to share your opinion in the comments! See you next time :).