3 affirmations for the next 365 days: on improving myself as a developer
Tags: productivity, career, beginners
Published: 2021-01-16 14:16:19

---
title: 3 affirmations for the next 365 days: on improving myself as a developer
published: true
description: New year, new opportunities for self-improvement: talking about what matters to me, my future self, and what I will be focusing on for the next 12 months to become a different developer than I am today.
tags: productivity, career, beginners
//cover_image: https://direct_url_to_image.jpg
---

On this day exactly one year ago, I published a piece in which I talked about 6 habits that I wanted to create in order to level up as a developer (you can read it [here](https://dev.to/httpspauline/6-new-habits-i-m-building-to-level-up-as-a-junior-developer-1n24)). 

I re-visited it a few days ago and found this little retrospective very valuable and enjoyable, which gives me more than enough reason to write an updated piece for the coming year. This time I am changing it up a little bit by turning it into a shorter list of ✨_**affirmations**_✨ that I hope to manifest (because truthfully, calling it "2021 goals" makes it sound like a checklist and gives me too much pressure).

I'm again sharing this publicly mostly for accountability reasons, but hopefully this will also inspire you to think about some things you want to work on during the next few months!

### 1. I am getting better at creative problem-solving

Whenever I build features, I have the tendency to solely focus on making things work and getting features shipped at a steady pace. While this is not necessarily a bad thing in itself, I often find myself criticising my own code for not being "elegant" or "sophisticated" enough—the implementations I come up with are oftentimes rather basic and in my opinion are nowhere as clever as some of the implementations built by my peers. Although my code also gets the job done, moving forward, I'd like to pay more attention to how others structure their logic and to the feedback I get in PRs in order to improve my problem-solving skills. 

On top of this, I would also like to improve the quality of the code reviews I conduct. While I tend to test and review PRs of others quite thoroughly, the feedback I give has often been limited to nitpicks. I believe that deepening the understanding of the stack I use daily will also play a valuable role in levelling up my creative problem-solving skills (which I hope to achieve by doing more of the next item on this list)!

### 2. I build side projects to boost my learning and development

You don't need to code 14 hours a day and have 50 side projects that are all hosted on dedicated domains to call yourself a developer. I do think, however, that working on small projects every once in a while is a great way to learn new skills. Last year, my side project completion rate was a whopping **66.7%**! My secret to success, you ask? Well... _(whispers)_ I only finished 2 out of 3 tiny projects I started. Yes, you read that right. I can count the number of projects I started on one hand. I also started 2 different courses and out of those, finished a grand total of 0.

Because of these not-so-impressive key results, I will be recycling this item from [last year's list](https://dev.to/httpspauline/6-new-habits-i-m-building-to-level-up-as-a-junior-developer-1n24) and hopefully start more projects (and finish those courses 😅) while still saving time for other hobbies, too.  

### 3. I am an active voice of new/junior developers

Even though my employer dropped the `junior` term from my job title (hooray!) at the beginning of the year, I still find it extremely important that every single engineering culture is one that's comfortable for all engineers regardless of their experience level, and one in which everyone gets heard (especially in spaces where senior engineers vastly outnumber junior engineers). 

This requires (but is not limited to) documenting clearly where needed, communicating with each other in an inclusive way, leading by example, and creating a psychologically safe space for everyone. Having this type of environment will not only empower junior engineers, but can also be very helpful for engineers who are new to your codebase. 

This means we're going to have to fight a few misconceptions here. I want to continue spreading the message that accommodating to new developers does **not** mean you are going to slow down the pace at which you ship, or that you're going to lower your code quality standards. It means being empathetic, inclusive, and contributing to the growth of others (because every senior engineer was once a junior engineer, too). 

---

If you have made it this far, thank you for reading. 💚 I'd love to hear from you: **what are some affirmations you're setting for yourself?**