Exhaustion at every corner, this year. Like many, my family and I were facing the direct consequences of two world crises: climate change with visible effects on daily life, and Covid quarantines/tests/sickness, etc. And then, the nearby war. We are only three, with a small kid who started kindergarten just this year. And I already had a stable job so that makes my experience way easier than a big bunch of other people. But anyway, let's talk development and leave the difficult part to the end.

Navigating the path from Junior to Senior

I professionally work in development for 2 years and a half now. That means that at the end of 2021 I had just 1 year and a half of experience. This made me a junior developer, and I felt like I was one.

I feel, instead, that 2022 made me make the jump to an intermediate developer in the real sense, meaning both on the technical side and the "soft skills" side. And even better, I felt like starting the jump into a senior role, step by step.

Mostly, I worked in React for the past year or so. Almost no backend development, although I started my career on that and I got more proficient than frontend. That allowed me to specialize a little.

I finished the full version of Epic React by Kent Dodds. I read lots of good practice articles and put all of the knowledge into my work projects. Luckily for me, I had lots of time in the Sprints at work to solve tech debt and do some nice refactoring. Although it was sometimes frustrating to update dependencies and resolve internal conflicts, the experience gave me a deep understanding of how React works and helped me to become proficient in it.

But overall it gave me a wide perspective of how, internally, React works. I felt I became quite good at it. So, I started to leave it for a moment and focus a little more on other skills that senior developers have. But I had no idea which was it.

How do I remember what I did 10 months ago?

I read about the "soft skills" that are often developed by senior developers and realized that while I had some of these skills already, there were others, like mentoring, that I couldn't develop in my current small company - it's between 20 and 30 people and managing the work as an agency. However, I did discover the concept of "building in public" through the work of Shawn (swyx) and following podcasts or other sources, for example by Randall Kanna. I'll be coming back to this.

My half-year performance review was a turning point for me. While I had given a few tech talks within my company that were well-received, they were mostly assigned to me by higher-ups and covered more general subjects

During my half-year performance review, I was asked if I expected a salary increase and why. I was caught off guard by the question and was not prepared to answer. As a result, I struggled to recall specific examples of my work from the past months and could only provide a general overview of my contributions to the company.

As a result of my half-year performance review, I received a small bonus but no salary increase. This motivated me to find a way to better track and document my accomplishments. I discovered the concept of a "brag document", which is a simple document (in my case, a Google doc or a paper sheet with dates, like a journal) where I can record my big achievements as well as daily or weekly tasks, the reasons why I am happy or satisfied with my work, and any compliments or feedback from colleagues or managers. I used the brag document to document my successes and highlight specific examples of my good work

Moreover, I put in it the extra work not related to my job: course progress or completion; blog posts; bigger articles.

I still have to show its sum up for the next performance review, so I don't know about the effects of it. But I can certainly say that I will remember what I did, why, and how to present it to my company.

Escape from side projects

We all know that among developers there's a hustle/side project culture. The normal way of thinking is that to stay updated with the tech advancement one has to build stuff outside of work, because normally work is based on only one tech, and it's not possible to experiment with it.

Well, here I go in another direction. As for many, many other developers with families with kids, side projects are a very time-consuming/expensive type of activity. Normally, there is simply no time for it. I did start one, but it went over my forgettable things very quickly.

But this was not enough for me. Going back to the "build in public" topic, and not being able to do it with a project, I thought that could be done with blog posts.

However, I had the same time issue. So, I thought of one thing. What if I can translate my code issues, bugs, or feature of work, from the PRs to blog posts?

In that case, half of the work is done because I already found a solution, and I have the problem. So that was it. I started writing about issues I found at work and how I solved them. It reduced my writing time by half.

In the meantime, I proposed by myself and have given two much more technical talks to my company, wrote one blog post for them and another one is on the way. You can check them on my Polywork profile.

And in November I started my newsletter. I think all of this will contribute, eventually, to compensate for the lack of mentorship and formal career advancement. Most of all, I'm happy I can write and talk about topics I'm interested in.

The bad parts

As I mentioned in the beginning, exhaustion was at the corner every part of the year. I work from home, but I worked remotely almost my whole development career, starting even before Covid hit. I love it, but sometimes it strains when there are troubles inside the family.

Developers have a lot of peer/society pressure to get always better, improve all their skills, or be left behind. Feeling the need to pass from junior to intermediate to senior, be it for the salary or what else, adds a lot to the mix.

Then the war in Ukraine started. We even hosted, for a month or so, a family of friends who ran away from Kyiv. Living in the Czech Republic, almost at the border, and remembering the Soviet repression of the Prague spring in 1968... it wasn't pleasant.

Luckily for me, support from family and even from my company was never missed, and I'm grateful for that. Meditating (or at least trying, given the kid) every day also helps a lot in stabilizing my emotions and actions throughout the day.

And even so, I had periods when I was most productive, and others when I was completely out of focus. One thing I learned was that it's ok. I know now when I push too much, and just let it pass. And I never steal a minute from my kid. All of this happens when either I got some break from work, or when he sleeps. There are fractions of time that can be managed to be productive, but that's a topic for another article.

Conclusion

I learned so much on my path this year. I experienced so much that I can't write here, because it would be a small book. I learned how to participate more actively in meetings and take business/code decisions; navigate the team's internal issues and help them solve with everyone. I'm making better PRs and improving my technical skills.

Maybe the most important lesson I've taken is: don't stop but don't exaggerate. Take your time, but don't stop. You love that, so find slices here and there. And if you don't love that, don't do it.

And try to write down as much as possible, whatever you have learned, been complimented about, or screwed up. It all becomes part of you, and it's better to remember it.

Let me know if you would like to go deeper into some aspects of the various Intermediate to Senior skills!