Table of contents
- My career evolution
- Things I wish I had started doing earlier:
- Things I wish I had done differently:
- 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. 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.
Top comments (18)
I have 20 years of experience as a software developer / architect and I pretty much agree what you wrote here. There are a couple of points I would like to make:
I guess writing a blog about your accomplishments is a pretty good proxy if you cannot publish any source code. However, if at all possible, publish software projects – hobby or work related. You create software for living so you should demonstrate your skills by publishing source code, not blog entries.
Sometimes big changes require big rewrites and the most important thing about those is having the main developer of those changes available whenever those changes are merged to the work other people are doing. In case of Git this would be merging your changes to master branch. We have a rule for our team that if you're going for a leave or holiday, you don't merge your branch into master, even if it has code reviews done and it passes automated tests. You want to have the documentation as you described but you also want the developer to be available to answer the small details which are always missing from the documentation. The only thing that can describe all the details is the source code, everything else can give you more or less overall picture only.
Other developers can replace you if they have the documentation and source code but that replacement will be less effective than having the original author available. I'd say reserve at least 2-4% of the total work used for the big rewrite for the time reserved to support the newly introduced code after the merge. For example, if the branch took a year to write, you reserve the next week after the merge for supporting the other developers. You can do some best effort work during that time but your primary task is to support other developers with the new code. You definitely don't take a leave there.
We use Git and rebase workflow for everything, so keeping the "ready" branch off the master until you return from the leave is no problem. If you don't know how it works, learn to use Git effectively.
And about the meetings and disagreeing on things. I think it's fine to express this during the meeting if you can keep the discussion to matters and facts. Expressing something like "I'm against this action because it causes side-effect X which would lead to Y" is not only okay, it's the recommended way to proceed. However if once you start to speak about persons and opinions (or even beliefs), it's time for 1:1-discussions instead.
And I would like to add one point not in the article: keep learning new stuff all the time. I'm always balancing how much new stuff I learn vs how much I use the methods that I already know. It's hard thing to balance but I think it's absolutely required if you want to stay relevant and effective when better techniques become available. And if your employer cannot agree that you can use some of your paid working hours for this, your salary should be good enough for the working hours that you can do the same thing on your own time without feeling ripped off.
Other than that, great work!
Hello! Thank you for sharing this valuable message, I completely agree with all of it!
For the big rewrite part, here is some additional context that was not mentioned in the article. I was overconfident. All the use cases were covered with automated tests (not saying 100% code coverage, but 100% use case coverage). I was confident it wouldn't break during my absence, and it felt like a pretty good accomplishment to fully release that rewrite right before leaving. The problem I didn't anticipate is that one of the most critical use cases was wrongly tested: I assumed the system would behave like A, so I tested all the possible cases for A, but in the end it behaved like B.
This is problably something I should have written in the article:
Don't make assumptions, always ask questions.
This may involve some delay where we are waiting for the answers, but it's better than implementing some solution based on the incorrect assumptions.
As you said, a better way to handle this situation would have been to release the last parts of the project after my vacations. At least I learned a good lesson from that unpleasant moment of my career. We can't rewrite the past, but we can use it to write a better present.
For the meetings part, you are absolutely right! It's completely fine to disagree with things, as long as the disagreement is backed by arguments based on facts and "cold" statements, and where it is used to move toward a better solution overall. Though it's easy to let emotions take over in some cases, so it's very important to be self-aware of that, and to avoid these situations (1:1s are there to release the pressure and talk about these issues).
The last part is one of the most important things to do as a developer: learning! I am lucky that I was always able to take time to learn while working. Since it's something I've always done, I felt like it didn't fit the "wish I had done earlier" or "I had done differently" parts. It's definitely something that fits a "I have always done, and will continue doing" article/section though!
Another way to put it: "Always question your own assumptions."
Thank you for sharing your experience. It was very interesting and practical.
For weeklywork logs, do you also take daily work logs to help refer back to and organize them at the end of the week? What about daily work logs over weekly?
Hello! I only maintain a weekly log that I fill every Friday afternoon. I believe writing weekly instead of daily helps me avoid keeping track of trivial/small tasks. For the record, in 2022 and 2023, I have on average 10-12 bullet points for each month. I'm not saying it's a recommendation, but it is what works for me.
That said, if you feel like a daily log can help you write the weekly log, then go ahead! I can only encourage you to do what works best for you :) just be mindful of the amount of details/small things that you write in the daily log. In my experience, not everything is worth keeping in the long run ;)
thank you for sharing extremely useful experiences, i learn so much from your article
So much great advice here! I can definitely recommend being on call if you want to get good at problem solving. Wish I'd started a work log 10 years ago though!
Thanks for the advice sir. I'm a newbie developer currently learning JavaScript.
Thank you so much for the wonderful case study and experience!
I can use it as a learn and reflect on myself and plan to become a more senior role.
Thank you for reading, I'm glad it can help you! :)
1 sentence in and this is absolutely golden
One thing I learned during my over 20 year career in the field is to not rely on the test to evaluate the correctness of the code. As counter intuitive as it seems they are only a tool as many to improve the quality of your code and in no case is a certification of correctness.
The test themselves are "atomic" logic problem that are developed by someone and could vary in their quality. I think everybody had experienced soon or later to have found that unit test that actually did not fail when instead it should, or when someone commited a unit test that actually covered 100% of the code but omitted the result verification of all the involved data (that actually returned the wrong result, or persisted the data wrongly or not at all).
Unfortunately is not easy to catch everything during a code review, and as is not easy on the feature code, it's not easier in the relative tests that can be order of magnitude more complex of the code they are going to test.
So when I've read you left for holiday after realising this big chunk of refactoring because you were confident thanks to the test, I thought "oh boy, this guy will learn an hard lesson". In you case the test where technically all correct, the issue was the most common one pitfall, the interpretation of the requirements or the assumptions related to it. Not well written code and tests can cover you from that.
So yeah no merge before holidays, and hands on deck the first days to iron out the issues that will arise when the code run for real.
Your Haskell engineer should have insight with the utilization of Haskell and ideally other useful programming dialects. Having experience across different dialects, for example, Scala will assist them with guaranteeing that they will actually want to convey what you really want.
They ought to likewise have the option to show insight with conveying projects like your own utilizing Haskell. The more tasks associated with the better as they will actually want to carry that figuring out how to assist with your undertakings>> Mobilunity
The best cheap assignment writing services strike a balance between affordability and quality. Look for providers that offer reasonable rates while maintaining high standards of work, check geekandnerd.org/. By reading reviews, comparing prices, and assessing the expertise of their writers, you can find reliable services that offer exceptional assignments at a price that suits your budget.