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:
- I started working as an intern for 3 months at a startup (which quickly became a scale-up) company.
- After that, I did a full year of work-study where I spent 3 months at school and 9 months at work.
- Then, I got hired as a full-time Software Engineer, and I kept this title for 3.5 years.
- 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.
- I joined as a Software Engineer 2 at a company with thousands of tech employees. Despite the title downgrade at the second company (cf. . 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 ().
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 . It even got a mention in the , and I continue doing so from time to time. I also posted an , 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 , 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 by Gayle Laakmann McDowell.
on Unsplash.↗ Original-Artikel auf dev.to lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
SOCIAL SHARE CARD GENERATOR