With this new series, I want to give you a glimpse of what a career as a web developer (well at least that’s what I am today) can look like by sharing a yearly summary of what each new year has taught me from a technical perpective, of course, but also in terms of personal development.

As I am writing this post I’ve already in this industry for three years, so I am writing based on how I remember this first year.

First things first: I’m loving it!

If you’ve read the post explaining why I chose to become a web developer, you probably already know that I had a specific dream job in mind before choosing to switch careers. The pursuit of this dream job fueled me with enough resolve and energy to go through months of training, part of which I did while also keeping my old job, and through months of job hunting.

The very first and most crucial thing that I can say when I look back at the year I’ve now spent as a web developer is: it really was worth the effort!

I’ll dive into all that in much more detail in the following sections, but the overall aftermath of this first year is clearly positive:

• I now work in a small team with colleagues who have been nothing but kind to me since my arrival, have helped me learn a lot, and really make the workplace feel like a second home.

• I now feel free (and even encouraged) to learn, explore new technologies, and share what I’ve learned with my colleagues thanks to a range of formats: Notion pages, live presentations, even git repositories. My past experience as a bored and invisible engineer in a lonely room now seems so far away…

• There’s been so much to learn, first technically of course, but also regarding aspects I didn’t really consider as paramount before, but whose importance I am now starting to realize: communication, documentation, software architecture, and much more.

• Last but surely not least, I still feel the same fire and the same curiosity inside me towards web development!

Climbing the technical ladder

As anyone can expect, my first year was full of technical challenges and lessons. Even if you go through all the training in the world, you are bound to have a few last things that will need to be learned on the job. In my case, there were plenty of things that my previous training had not allowed me to learn to the level expected in the professional world, which I therefore had to become better at:

• Git: Although I had been involved in a one-month group project at the end of my bootcamp, I hadn’t had the opportunity to use git that much, and I only knew basic commands that simply weren’t enough. So it didn’t take long before I had to learn how to interactively rebase a branch onto another or to backport commits (typically fixes). With that also came quite a bit of advice on how to use git in a smarter and cleaner way by splitting merge requests into several precise commits and naming them in a standard manner, or by learning to postpone changes that should be made in a distinct merge request.

• TypeScript: Ever since I knew I had been offered a position in my current company, I knew I would need to use TypeScript every single day. I followed a few tutorials and tried to learn it on my own, but it really took me a full year to master the fundamentals. I was actually lucky enough to spend this first year working on a project that wasn’t actually using that many generic types, which definitely is one of TypeScript’s most tricky parts. I was therefore able to learn about advanced TypeScript features at my own pace during this year, without being actually expected to use them all the time.

• Code review: Even now I happen to think that code review is just one of those things you can’t actually learn by yourself. You need actual colleagues, the more experienced the better. When I joined the team, this part of the job felt quite unnatural to me at first. I used to consider that my job mostly consisted in writing code (spoilers: nope, it does not), and I was completely underestimating the importance of code review. It took me months to develop the habit of reading open merge requests in the morning, to learn how to make constructive comments to my colleagues, and to gain enough confidence to question (or suggest alternatives to) how they chose to tackle a given task instead of assuming they knew better than me.

• Docker: I’d used Docker before, mostly when following fullstack tutorials on YouTube, but I quickly realised that the project I was involved in at work was significantly more complex than any of the latter. It massively relied on Docker (and Docker Compose) to be able to locally start our APIs and run integration tests. So as months went by, I gradually became more and more familiar with Docker commands as well as with debugging using container logs, which also led me to understand how powerful and useful Docker is!

• Node.js / Fastify: I was obviously able to learn quite a lot while using Node.js to build APIs, all of which I had only scratched the surface of during my months of training. During this first year, I gained a much finer understanding of all the things frequently handled on the backend side, for instance:

  • Generating documentation for one’s API using Swagger and OpenAPI, converting it to a format that can be handled by AWS when deploying it, and making sure this documentation is coherent with our API’s actual behavior.

  • Validating HTTP calls to third-party services (SOAP, REST, etc.) using libraries such as zod.

  • Versioning our API to correctly indicate to its users when it introduces breaking changes.

  • Handling errors in a standard and readable format across our APIs so that users can interpret them, while hiding technical errors they should not know about.

  • Using monitoring logs for various purposes, mostly for debugging and anomaly investigation.

• Amazon web services (AWS): It surely won’t come as a surprise to you if I tell you that the first project I worked on relied heavily on AWS. Until then, I was pretty much unaware of the diversity of components available in AWS, and more generally of the whole serverless and cloud trends. In just a few months, I started using quite a lot of AWS acronyms in my everyday life, things such as Lambda functions, Kinesis data streams (KDS), Elastic Container Services (ECS), Simple Systems Manager (SSM), Identity and Access Management (IAM), just to name a few… And even if I was not a big fan of those, I actually started to understand why AWS was so dominantly used in our field.

What about the work environment?

When I decided to change jobs, I was also looking forward to working in a small team, being respected and allowed to give my opinion and make contributions. In that regard, I feel incredibly fortunate considering the following:

• For the past year I have been working in a team of roughly ten developers who all seem to share common values about the importance of communication skills in addition to technical excellence in our line of work, balance between personal and professional life, or even on climate change and our own responsibility and accountability as developers.

• I appreciate that we are not just working together, but also talking, eating and even playing together during breaks. This, to me, is incredibly valuable and makes the office feel like a second home even after just a year.

• Most of my current colleagues are senior developers with years of experience. Many of them have allowed me to improve and learn a lot by answering many of my questions and concerns, by giving me valuable advice, or constructive feedback regarding my work.

• My manager is also a senior developer. As such, he understands my job and is able to give relevant advice when I tell him about the occasional issues I face at work. We try to tell each other when things go well and when they don’t, and it’s actually a relief that we are able to communicate efficiently.

I really believe that being able to find such a cool working environment makes all the difference in the world between any work opportunity and a great one. By great, I mean one that will allow you to learn quicker and let your career soar while also keeping your passion and curiosity intact and nourishing you with rich human interactions.

The imposter syndrome: good or bad?

TheThere is only one downside I can see to this first year. Being a perfectionist who pays a lot of attention to detail, it shouldn’t really come as a surprise if I tell you that I was lacking confidence in my skills when I started working as a web developer.

Don’t get me wrong, I knew I could be proud of what I had achieved since my first YouTube tutorials. I simply did not see myself as a great developer yet. Every now and then on the job, I’d be reminded of how much I still did not understand about the web (or TypeScript, or PostgreSQL, you name it), and of how much I was still relying on others. I often felt like I had to keep trying hard, that my current learning pace was not high enough, and that I still had pretty much everything to learn from others.

The imposter syndrome will obviously affect your self-confidence, but I think it was also partly beneficial to me because it led me to ask all sorts of questions, to make efforts to become better and more knowledgeable in my work, and more generally to always doubt and question the things I hadn’t actually thoroughly looked into. Those are really habits that will allow you to improve a lot! But is it possible to keep the benefits while also protecting your self-esteem?

I like to think so now, and here’s my modest piece of advice for all the junior developers that may be reading this post:

• Your worth is not defined by what you know or don’t know right now, but by your ability to learn and make progress. As long as you arer learning and evolving, you are doing just fine!

• Try not to compare yourself to others, but rather to who you used to be one or two years ago. Believe me, it’s surprising how much one can improve in this job in just a few years.

• Don’t focus too much on goals and results because you might end up not appreciating the present. Every now and then, take some time to appreciate where you are right now, what you have already accomplished, and how the things that once seemed impossible to you now seem within your reach, providing that you just stay on your current track. Appreciate the trip, not just the destination, my friend!

What’s next?

That’s it for this first yearly summary! I sincerely hope you enjoyed it. I’ll return soon with a similar article about my second year, in which there’s also going to be lot to say! Until then, cheers!