I got my first promotion in 10 months

Sharing what I did and learned along the way

Community announcement

We just launched a brand new community: Little Software Planet.

A place for developers to grow, connect and learn.

Introduction

I went from Junior to Mid-Level Developer at my first company in 10 months. I want to share what I did to grow so fast and drop a couple of things I learned along the way.

Looking back, I think there were 4 main things that made me deserve the promotion.

Made our site more accessible

We needed our site to be accessible. We had older people, such as grandparents, using our site. When I started, the company had a consultant who led the accessibility initiative. I was extremely curious about accessibility because I had never heard about it before. It was a surprise to me.

After learning more about it and talking to my manager, who had prior experience in accessibility, I learned we had a need for it. I learned more about accessibility in my spare time and built side projects where I focused strongly on accessibility, which included testing with a screen reader.

Later, the consultant left. There was room for me to step up and become the accessibility expert of the engineering department. I talked to my manager and proposed testing our site with a screen reader and Axe DevTools to identify issues. I documented all the issues and sorted them by severity level. I followed up and discussed this with my manager. We decided to fix any issues that resulted in a horrible user experience.

Getting good at accessibility also helped me write better tests with Testing Library.

I would consistently share knowledge and make sure the team implemented accessible code.

Introduced practices that helped the team move faster

The practices I introduced were Pair Reviews and Stop and Fix.

Pair Review

Instead of the async flow of reviewing PRs, Pair Review is hopping on a call and reviewing it productively together. This helped us move more efficiently.

Pair Review

We had a problem where whenever build would fail, it could be broken for days. This resulted in the team going into panic mode when we had to ship to customers.

Stop and Fix is a practice from Extreme Programming: Whenever build (main branch) is broken, the entire team stops to fix it. This ensures the codebase is always in a working state.

Documented usage of performance APIs in React

Performance APIs in React were used randomly because people had assumptions about how they worked.

We should always measure to see if there is a need to optimize for performance.

Such APIs don't always come with a benefit, but always come with a cost.

I asked the team about it. There seems to have been a misunderstanding of how the APIs work. After a discussion, I documented the usage of those APIs.

People stopped randomly using the performance APIs. When they did, they would add a comment explaining why they were using it.

Got good at testing

We used the React Testing Library at work, and I got extremely good at it. I also took the TestingJavaScript course from its creator, Kent C. Dodds, and contributed to it (Open Source).

Already in my third month, my manager realized how good I was at testing. We had a meeting that month: my manager, another Lead, and myself. We discussed my rapid growth and how happy the company was to have me. That’s when my manager told me he was shocked to see how good I was at testing when we pair coded.

Lessons to take

What can we learn from my experience?

• Get technically good.

• Be extremely curious.

• Don’t be shy about confronting the team despite your experience.

• If you identify a real problem, step up and propose a solution that involves you having a real impact.