Detecting your growth as a junior developer can be difficult if you’re not observing the right parameters. In this article, I will give you three signs that indicate you’re growing as a junior developer.
You’ll spend more time thinking through problems
It can be tempting to believe that producing more code more often is a sign you’re growing as a junior developer. However, I would argue the opposite to be true. When I first started my career as a Software Engineer, my instincts and zeal would lead my attempts in solving problems rather than thoughtfulness. And If I’m being honest, I still struggle with this. As time went on, I learned from my Senior Engineers that getting a “working solution” wasn’t the goal but rather creating a “complete solution”. So how do you do this? By thinking!
Here’s a list of three things to think about when solving problems as a Software Engineer:
Think about potential problems and edge cases that need to be accounted for.
Example: A React component that receives the title (string) of a book
Potential problems/edge cases:
The title is extremely long
A title is never given
A title has a bunch of spaces and tabs in the string
A title is given in all caps
Think about how your code works to see if there’s any room for refactoring.
Example: A React component calls a function that filters through an array to display data.
Potential refactor:
Use the useMemo hook to make sure that function only gets called when it needs to and not on every render.
Think about all the necessary steps required to achieve a proper solution.
This step really comes in handy when solving a complex problem you’re unfamiliar with. Once you know “what” you need to do, you can goggle “how” to do it.
Your average review cycles will decrease
If you’re not familiar, your average review cycles or a.r.c. for short, represents the number of times you have to address pr comments. For example, let say you send a pr and your senior dev reviews it and sends it back to you with minor comments. You address those comments with perfection and he merges your pull request. This represents an a.r.c. of 1 and is the ideal situation. This number will increase if you don’t address the pr comments thoroughly and your senior dev has to right more comments on your pr. My a.r.c was pretty high early in my career.
How did I get it to decrease? First, I double checked my work to make sure I addressed all the comments in my pr. Then I started asking the three questions I mentioned earlier to create “complete solutions”.
You’ll take more initiative
In the beginning of my Software career (and still today), my senior devs would “lead me to the well” concerning the infrastructure I needed to solve a problem. This included, suggesting packages I should use for complex features and handling backend issues I wasn’t familiar with. As time went on, I noticed this pattern and I started to handle some of these task myself.
If you’re just starting out as a junior, you may want to connect with your senior dev on how much leeway you have in making decisions that effect the companies code base. If you have the freedom to make decisions like implementing new packages, leverage it so you can grow into a more autonomous engineer.