How to grow as a Junior Developer

I’ve now been at Wise (formerly TransferWise) for six months. I feel like I’m now fully integrated into my team and have a good understanding of the product. Now that I’m settled and comfortable in my role, it’s given me the breathing room to focus on my growth and development as I head towards my first GrowWise, which is a 360 feedback and development discussion we all have at the one year mark.

Figuring out how to continue learning and finding opportunities to grow took me a little while and a few false starts. I got there eventually, though! Here are some ways that I found to do so as a junior engineer 📈.

Taking on responsibility and putting myself out there 💬

Taking on responsibilities outside the scope of my traditional development role has produced lots of fantastic learning and growth experiences. Here are a few examples of things I’ve done:

Listening to and learning from our customers

The iOS app received several accessibility complaints about support of our VoiceOver from customers, which is something that I’m really passionate about. One of these customers offered to answer our questions and help us improve. I took the initiative to set up an interview with the customer, producing (and presenting) a comprehensive writeup of my findings, which was widely shared out with the company. Although this was a huge amount of work outside my usual role, I learnt tonnes.

I learnt how to plan, execute, analyse and share user research which will be extremely valuable within my team as we continue to build investments 🚀. I also learned how experienced VoiceOver users use the accessibility features in practice, from how to approach navigating an unfamiliar screen, to what accessibility traits and labels are expected. The biggest takeaway was how important the hierarchy of information is and how this differs from visual users. I’ll be able to apply this to each of the screens I build in future and help others do the same.

Going out of my comfort zone with an Instagram takeover

Another example, Wise are currently recruiting graduates and interns. As a current graduate myself, I’ve been asked to get involved in the process, from giving feedback on my hiring process to actively promoting the roles. I was first asked if I’d be interested in doing an Instagram takeover to show what it’s like to be a graduate. This involved recording videos throughout my day, showing what I do and answering questions from prospective graduates and interns. I said yes, even though it’s something that’s really not in my comfort zone.

Although I found it difficult at first, once I got into the flow of it, I ended up quite enjoying the opportunity to share my day and answer questions. I appreciated the trust in me to represent the brand, as I had free reign to post anything I wanted. I learnt how hard it is to produce real and informative content, especially with the constraints of working from home. I also got the opportunity to work with teams I’d not interacted with before, like our social media and early careers teams — whose work resulted in me working there in the first place!

Soon, I’ll also be taking part in a webinar aimed at prospective graduates and interns, which I’m sure I’ll learn a lot from too!

Learning from others — Paired coding 💻

Paired coding is where two developers collaborate in real-time to write code. One ‌”drives”, which means controlling the keyboard and mouse and doing the typing, constantly sharing their thoughts in real-time. The other ‌”navigates”, double-checking the driver’s logic and giving suggestions.

I’ve found that I use pairing as a tool in two cases. The first is when something, like an issue, is raised within the team, and I’m interested in learning how to fix it but don’t yet know how. I’ll ask the team:

”I’d be interested in fixing this, but I am not sure how. Does anyone want to pair with me?”.

Usually, someone with more experience is more than willing to work on it with you. In these cases, I usually assume the ‌”navigator” role; I’ll make notes and comments about the process, suggesting any improvements when I see them. This means that next time I can attempt to solve the issue myself using my notes.

I find this learning method powerful as I’m able to clarify my understanding in real-time by asking the ‌”driver” questions. I can ensure that I don’t just understand what to do, but I understand why I’m doing something.

The second case where I find pairing beneficial is when I’m not confident about solving a coding problem elegantly. In this instance, I’ll take up the role of the ‌”driver”, asking a more experienced engineer to take the role of ‌”navigator”.

I usually use this with my mentor @thchristiedavis, as she’s great at helping me understand the issues with my ideas without explicitly telling me them. As I code, she asks great questions, which make me consider the future implications of the approach I’ve taken. The questions also help me better understand the thinking process of an engineer with more experience, which I can then apply to my other work.

This approach will help me feel a lot more confident about my solution, which is especially great when making higher risk changes to the product. Again, notes can be helpful here for the next time!

Making the most of code reviews 🙌

Code review is now an industry standard. Most companies require at least one approval for another engineer and all the tests passing. Often, as a junior, it’s easy to think of this as a process that you put your code changes through. But, in reality, there’s a lot more potential there.

Code review shouldn’t be senior engineers reviewing the code of the less experienced members of the team. It should flow in all directions, meaning you should be reviewing code too. I’ve found that a sweet spot is doing around 20–40 minutes of code review a day; however, usually, I don’t do this in a single uninterrupted session. I find that code review is a great thing to do when blocked by a question, or when running the test suite etc. It makes the time that would otherwise be wasted useful.

There’s lots of benefits to being both the reviewer and the reviewee. It’s a fantastic knowledge sharing tool, giving you a great overview of the whole codebase. This makes it much easier to make changes outside of your usual domain area. It can also be a great place to discuss and learn things like; new approaches to solving a problem and new language syntax you might not have known about 🙌🏻!

The peer pressure of knowing that your code will be reviewed helps produce better code, as extra efforts put in so the review process will go smoothly. This includes considering the structure and readability of the code and ensuring proper test coverage, which will reduce the amount of technical debt in a product. Doing so means less time refactoring and replacing old code when making changes in the future, speeding up the development cycle and letting us iterate and ship code to our customers faster.

Code reviews are also a great way to catch bugs early. A second set of eyes and a new perspective is a great way to find small (or sometimes large) issues if they’re present. The earlier a bug is caught, the cheaper it is to fix. That’s especially important for us at Wise as we’re working towards “Mission 0”, every cost-saving helps!

Staying curious and asking a lot of questions 👀

This is something that I’ve advocated before, but it doesn’t get any less relevant now I’ve settled into my role. The biggest shift is where my questions are directed. I’ve started asking more about research, product and design as we continue to develop our new and existing products.

Doing so helps me understand the processes we do and how we manage change and growth. Often, the questions also give me better historical context (from before I joined) as to why existing decisions were made, helping inform my suggestions moving forward. Overall, it’s giving me a more well-rounded understanding of our team’s processes, which ultimately makes me a more effective engineer.

Taking advantage of learning resources and budgets 💡

A common benefit of many engineering positions is a learning budget, so check if you have one. You can use them to buy relevant books, online course subscriptions and even attend conferences.

So far, I’ve used mine to access courses like Hacking with Swift Plus and Point Free, which I use to learn about some upcoming technologies we’re planning to adopt. Taking the time to understand them now’s going to put me in a great place to help and teach other team members.

So, if you’ve got one, make sure you’re maximising your use of it!

P.S. Interested to join us? We’re hiring. Check out our open Engineering roles.