Advices from a Software Engineer with 8 Years of Experience

Table of contents

• My career evolution
• Things I wish I had started doing earlier:
  • Write a work log
  • Leave the comfort zone
  • Be curious about other teams and projects
  • Join the oncall team
  • Change teams
  • Write blog posts
• Things I wish I had done differently:
  • Be careful when introducing new things to the team
  • Do not let your emotions take over in front of the team
  • Dip a foot into the hiring market
• End thoughts

---

Hello and welcome!

My name is Benoit, I have been a Software Engineer for the past 8 years. I stayed at my previous (and first) company for 7.5 years, then I joined a new one early 2022.

This blog post comes from a self-reflection I recently had, on the things I wish I had started doing earlier in my career, and things I wish I had done differently.

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

My career evolution

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

1. I started working as an intern for 3 months at a startup (which quickly became a scale-up) company.
2. After that, I did a full year of work-study where I spent 3 months at school and 9 months at work.
3. Then, I got hired as a full-time Software Engineer, and I kept this title for 3.5 years.
4. Quickly after the introduction of the tech career ladder, I got promoted to Senior Software Engineer. I kept this title for 3 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 (cf. Big Tech Hiring is Conservative - But Why?), I have been trying to keep the same responsibilities as before.

At 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 5 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.

Alright, enough with the context. I hope you'll enjoy reading the rest, and that the following advices will be actionable for your career progression!

Things I wish I had started doing earlier

Write a work log

A work log is a document that contains the list of tasks you accomplished. The granularity and the type of the 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 2 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, to 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 in the waters of the hiring market.

I started writing a work log roughly 2 years before leaving my first company. So, over the past 8.5 years, my work log contains only 3 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 memories to remember what I did during the first 5 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 2 years, then I switched to a Google Docs with bullet points (1 list for each month of the year).

Leave the comfort zone

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 in turn they become comfortable in 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 project of the team or organisation that 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 the 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 the comfort zone.

There may be some subjects that 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!

Be curious about other teams and projects

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 oncall 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 could have a better understanding of what could be the culprit when things went wrong.
• I would know why we needed that particular service, or why we made that choice of data store.
• 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 to their demos, 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.

Join the oncall team

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 oncall environment (cf. Oncall Compensation for Software Engineers).

The oncall 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 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 oncall team, whether it's for the product you work on, or for the whole company (depending on its size), I would suggest doing it.

I see the following 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 oncall environment is required before embracing these responsibilities.

At my first company, I joined the oncall team (who was responsible for all the services) approximately 2 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 oncall team (who is responsible for the services of a single product) 2 to 3 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 the weekends.

Change teams

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

• You are too comfortable at 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 has 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 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, 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, 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 5 years, then switched to the new one for 1 year, and eventually left the company for reasons unrelated to this new team.

If you feel like your situation fits in one of these 3 reasons, I would advise you to consider changing, but only if you stayed at least 1 full year with your current team. I think 1 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.

Write blog posts

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 way of communicating with people. They can read your messages whenever it suits them, 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 communication: video call, in-person meetings, 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 notification, but your goal should not be to increase these numbers. Your goal should always be to improve your writing and share the 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 from time to time. 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.

Things I wish I had done differently

Be careful when introducing new things to the team

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 of 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. I had been learning about the Functional Programming paradigm for a couple of years at that point, and I was convinced of its advantages.

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

I thought these training sessions were sufficient to convince people to adopt this new paradigm. And at that moment, it was true: people were nodding their heads up and down. 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 was going to 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 (a.k.a TS). That old system was initially developed at 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 in charge of 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 am not going to 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 into continuing 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 the span of 2 months, I must have spent around 10 hours a day working on it, including weekends.

Once the work was done, I took 2 weeks of time 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 somewhere inside the new system, which didn't look at all like the rest of the codebase. The team wasn't really familiar with it, as I was pretty much the only one who developed it.

During the presentations I shared, 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 about it. Plus, presenting each concept separately is not the same as using them all together. 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 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 was going to stay in that team for long enough that everyone would eventually be familiar with the new code, 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, in addition to almost burning myself out because of it.

Whether you are an individual contributor (a.k.a 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 won't be around to help them?

Do not let your emotions take over in front of the team

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 that it bothered me, thus starting a "conflict" publicly.

I wanted to show my peers that 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 cleavage 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.
• Or, 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 very far in a company (or in our personal lives).

Dip a foot into the hiring market

When I joined the first company as an intern, I had a 30 minutes 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 a foot on the hiring market for 7.5 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 8 years of experience is definitely not composed of just a "30 minutes behavioural interview".

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

I felt overwhelmed. Dealing with all the job propositions that rain down on me was exhausting. From September 2021 to the end of October 2021, I must have received between 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 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 simply 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 of changing company.

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.

When I finally accepted an offer, I handed my resignation to my manager. If I remember correctly, I got a +25% base salary increase with this new offer, and 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 the time comes to finally join a new company, you will feel less overwhelmed.
• You can check what is 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 even more at getting 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.

Since I was getting 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 what 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.

End thoughts

First of all, thank you for reading so far! I hope this article was useful to you. I think you noticed that all these advices are not really technical. Most of them are about soft skills. Maybe I'll write another article with advices that are 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 the ones that inspired you. They are people you admired, because they did a great job according to your own 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 to do as long as the frequency is reasonable. Everyone should build a network that helps them become a better person.

If you have the occasion to try these advices out, and if it ends up working out for you, please share your experience. I am really curious to get feedback about these advices, and see if they can apply to other situations than my own.

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

---

Photo by Simon English on Unsplash.