The Junior Dev Approach

Company: Klaviyo

Foreword

I have past and incoming future experience as a part of teams with room to fail, grow, and learn. Ownership was a key portion of my previous internship, and so too came everything with it: less handholding and the pretense of a project pushed to production. The following blog post will be derived from what I learned.

My approach to performing well as a junior developer in a corporate workspace consists of three living principles:

1. Prioritize Curiosity

Directing a significant portion of my time towards learning about the stack, team workflows, internal tools, and of course fellow team members is beneficial to all involved parties. This includes not being afraid to fail, asking for help, and being involved in all processes until I can function autonomously i.e. code reviews, retros, sprint plannings. The faster I can integrate into a new workflow/team, the more I will be able to contribute sooner. It goes without saying how the drive and enthusiasm to learn as much as I can benefits myself.

A really helpful practice that jumpstarted my understanding is pair programming: you have the opportunity to bounce ideas off of a peer who is likely more experienced and knowledgeable than you, and in turn absorb their wisdom and incorporate it in real time!

A cautionary tale: while the fear of failing shouldn’t get in the way of learning and progress, a fear of lacking sufficient knowledge to take on a workflow should. Understand when to backpedal and reassess if more needs to be done in the knowledge department.

2. Manage Time and Priorities

When confronting a set of tickets, I give each one an estimate of the time it will take and its priority to the overall project. There are other factors too; some block others, some are blocked by others, and some need information I don’t have yet. It is up to me to set up a working DAG of tickets, as well as meetings with domain experts, and ultimately piece together a working schedule for the sprint to come.

A key lesson I learned is to not get sidetracked and focus on priorities. A feature vital to a project assigned to you will always be more important than a high impact overhaul to an already working system.

3. Balance Impact and Value

All work creates different amounts of value, which adds progress towards the team and company’s goals. Impact is a byproduct of visibility, which leads to better reviews and progress towards promotions.

Valuable work doesn’t necessarily accrue the impact it deserves, while less time consuming work may be more impactful. On the other hand, if we only took on impactful work, we’d generate a lot less value. Take the following scenarios for consideration:

  1. Dev A refactors a large portion of the codebase to be more modular, easier to manage, and more welcoming to new hires. This is highly valuable work - a new hire may be onboarded significantly faster, and this scales to however many new hires utilize this portion of the codebase. However, the impact is not felt immediately, as it requires new hires to join AND comment on how easy it was to onboard to bring attention to Dev A’s work.

  2. Dev B modifies an internal tool to allow for a new sorting method in development datasets. This feature was a big complaint of a corresponding team that works closely with Dev B’s team. Adding a singular sorting method does not generate as much value as Dev A’s refactor, but it is higher impact solely because of the visibility of the issue resolved.

It is inevitable that I will end up choosing between being either Dev A and B, as well as encountering both Dev A and B in other coworkers. Thus, it is my responsibility to ensure value like A receives the visibility it deserves in order to incentivize valuable work within the company culture. Following this, it is my responsibility to bring as much visibility as I can to my own work to produce more impact.

As a junior, doing high visibility impactful work is a priority when it comes to early career building, while delivering value is essential to learning and truly growing as a programmer. These may not go hand in hand, so balance is important.