When I started in my first dev job I hit on the idea of being a Junior++ developer. It was clear that the expectations on a junior developer were incredibly low and that there was plenty of time and room to explore and develop. I made sure to finish my tickets and get the work I needed to done, but I also did three things to set myself apart as more than a typical junior that I think anyone can do.
1. I made time to work with other juniors.
Working with senior developers is not uncommon, it's the best way to learn about the code base. But taking time to work with other juniors is a great way to mutually learn on something that you are likely equally lost on.
Working with a senior can become a very passive experience as they are so far ahead of you that you just sit and learn and absorb. Juniors tend to be ahead in some areas and behind in others, so we would unblock each others thinking at different points but the gap in knowledge was small and so no one felt like they were left out.
It was a very rewarding and engaging process.
2. Fix user pains that are too small to make it on to the backlog
Making time to speak to users directly let me fix a few tiny bug bears for people in the wider business. Things like a list being ordered the wrong way or a form clearing on error are minor enough to never make it to the top of the backlog but can be fixed by pretty much anyone with a spare 15 minutes.
Fixing these little annoyances shows initiative and also gains you fans in the wider business as you fixed their specific problem. It also gives you great experience working with users and owning a feature (no matter how small) from start to finish.
3. Do something to save your team or department time
We had an API that caused a number of support tickets per week. This was about 30 minutes of time for devs to fix. Not massive but annoying. The issue lay in the way the API fetched data from the database and an assumption made about the data in the request URL query params.
I spent five days across two sprints rewriting the logic in that API to fix that assumption and remove those support tickets.
Fixing this made me realise that the production logging wasn't good enough. So I proposed to my manager that I have a go at making a logging module that could be added to all out APIs and persist logs in one place. She gave me the ok and over 4 weeks, in between main ticket work, I created a Node logger that we could inject into all our APIs.
I worked with a senior developer on the logger and got it into production within a few days of it being completed.
Find a small pain point for you team and fix it, they will love you for it.
These three things combined are a great way to build a good reputation in you team and the business. They also help break up your day a little a give some variety of work that can sometimes be lacking in development roles.
Top comments (0)