Limit the scope
This is my first professional Rails role, and although I was familiar with Rails and have built some small apps using Rails, working with a monolith is a whole different ball-game. I quickly found that I was becoming overwhelmed and struggling to pick up new tickets without falling down rabbit holes trying to work out what the code was doing.
To move past this I agreed with my squad that I would focus on tickets related to the daily insights we send to our users, and start expanding my understanding of the application once I was confident in that one area.
As my confidence grew, I naturally started working on different areas of the codebase. Having some deeper knowledge of that single area helped me to contextualise other sections of code.
Observe or pair on more complex problems
I've been limiting the scope of my work to get an understanding of the codebase, but I've also been spending some time observing my teammates when they are debugging more complex problems.
The engineering team at Cleo has started to open Zoom calls when a complex issue crops up that needs urgent attention, which has two benefits:
1. Engineers who might have the right context or knowledge can join the call, and hopefully speed up the resolution.
2. Engineers who are less knowledgeable in the particular area can log on to observe the work, listen to discussions and ask questions.
Once the issue has been resolved there's also the option to attend a post-mortem to reflect on and learn from the issue.
While I might not understand everything that's happening while I observe, it's helped me to slowly build a picture of the application architecture, and how to investigate and resolve more complex issues.
Ask for help quickly
In an office it's so easy to turn to a colleague and ask a quick question, but the opposite is true when working remotely - it's so easy to just keep on trying to plough through alone and forget to ask for help!
It's especially important to reach out for help or a quick explainer when working in a new codebase. What might take you hours to unpick by reading the code could be explained in minutes by someone familiar with it. Sometimes even just writing down or explaining the problem can unlock a solution, so drop your team a slack message the next time you get stuck for more than 5 minutes.
Keep a learning wish list
When working through tickets it's common for me to notice a gap in my knowledge, but it's not always appropriate to take the time to learn in that moment. Instead, when this happens I add the gap to my learning wish list.
That list is visible to my squad and manager, and I've got a standing 2 hour weekly block in my diary to work through the list filling in the gaps. It also means that when I have sessions with my mentor I have a list of things we could look at and I get the most I can from those sessions.
Conclusion
When joining a new team there's always some pressure to get up to speed and become a contributor quickly. These approaches have helped me to balance this pressure with continual learning, and get the support I need from my new team at Cleo, maybe you’ll find them helpful too.
