Effective ways to contribute in a new codebase as an onboarding iOS Engineer
For most engineers, joining a new organization means having to onboard to some existing codebase. The larger a codebase, the more complicated it can be to navigate for new engineers, which can be overwhelming to start contributing code. As an iOS Engineer at Meetup, I experienced this firsthand when onboarding. This blog post focuses on some tips I’ve learned from my experiences contributing to Meetup’s iOS codebase when I first onboarded. To illustrate these practices, let’s look at an example of a task I worked on.
The task
My task was to re-platform our Experiment feature in the iOS app, which allows us to conduct A/B testing on new features. At the time, this feature was located in Meetup’s legacy codebase and part of the task was to move this code into its own module. The acceptance criteria for this task was to make it so any engineer can import the standalone feature and use it without having to reference legacy code.
When I began this task, I had some knowledge of where I can start working, so like any eager engineer, I dove right in! On the surface, re-platforming is essentially moving over files and implementation to a modularized framework. I thought, “how hard can this be, right?” I started ⌘+ C’ing like never before! Files were being copied at the speed of light. We were taking flight! I couldn’t wait for the reaction of my peers: “Damn, Hakeem, you did this that quickly?” However, not too far into the work, I was hit with about 100+ Xcode errors when trying to compile. I could faintly hear Xcode laughing at me.
This leads me to tip number one…
Reading Documentation
This underestimation was a sign for me that I had to go back to square one and read up on how this feature is architected. Indeed, reading the documentation unveiled nuggets of information on how to re-platform that I didn’t realize. More importantly, reading documentation gave a high level picture of how individual components work together. So, I tried again, and just like the first attempt, I… still faced many Xcode problems.
When you do things the right way and you still fail, it’s not fun. This brings up another point about documentation: Sometimes you might read and follow something to a T and it still doesn’t always work out.
In this case, there were many coupled dependencies that were not highlighted in the documentation. Knowing this, I proceeded to resolve the issues by replacing or removing the unnecessary dependencies. The takeaway here is that while contributing changes to a new codebase can be overwhelming for new engineers, reading documentation can make things easier to grasp to get you going on your way. If you find things that can be added to the documentation, make sure you add it so the next engineer can get the “Damn, [new Engineer], you did that this fast?” moment that you hoped for when they onboard.
Navigating Codebase
One of the biggest challenges as a new engineer when starting on a task is figuring out where do you start? What you may find in a new codebases is that the components representing a feature can be scattered throughout the project based on the team that architected it so sometimes what you see is not what you get.
For example, for the task we are working through, all the code that relates to the experiment feature was not entirely in ExperimentFeature.Swift file. So how would you go about finding the place where you need to make the changes?
Two methods I love using are top-down and bottom-up approaches to project navigation. Both of these go hand in hand with some Xcode searching tools that come in handy.
For a top-down approach, if you know the class, module or filename where you suspect changes need to happen, you can navigate directly there and drive down the call stack until you find what you are looking for.
Tapping ⇧⌘O (Shift + Command + O) will open quick access where you can keyword search.
Alternatively, you can take the bottom-approach where if you have any hint on what a variable name or function is, you can search it and go up the call stack until you reach what you are looking for.
Keyword searching in the file navigator shows every instance of where the keyword is used. You can go directly there and drive up the call stack to find classes that manage it.
Either approach will quickly lead you to the location where your code commits can be made.
For top-down and bottom-up, you can imagine a tree-like structure , in which when you are following top-down approach you move from root node to leaf node and when you follow bottom-up approach you follow leaf node to root node.
Pairing with another engineer
When I started at Meetup, I learned that the team used pair programming as a way to help get code delivered. I was skeptical at first, but it turned out to be an amazing experience to pair with another engineer when working on tasks.
After completing this modularization task, one of the CI scripts that handles our string localization started to fail. You can imagine: I just fought my way through 100+ issues and just when I see the light at the end of the tunnel, Xcode becomes a vibe kill again. What was more alarming about this issue was that it was not even related to my changes and it affected our app deployment process. This specific error is a runtime error that occurs when our CI attempts to export localized strings: without localized strings, we can’t deploy the app to the App Store.
Luckily, I was the person on-call so I was able to take an initial pass at it. I tried my best to solve it but got nowhere. After a few hours of trying and failing, it was time to call in the big dawgs! I hopped on a call with a senior engineer and we looked at the issue together. At first, he too was puzzled but after an hour of looking deeper, we found out that the issue is related to a recent Xcode localization change that affects new modules. Basically, I could have worked on this issue by myself for another 10+ hours and I wouldn’t have figured it out, but with another pair of eyes we got to the bottom of it.
Suffice to say, it’s easy to assume when things break, it’s due directly to the changes you made. However, that’s not entirely true as sometimes there are side effects that occur due to environmental changes. Having someone else take a look at an issue with you will save you tons of time and headaches.
Follow existing patterns
Now to the fun part. I have cleared all of the issues, found the right place in the codebase and am ready to write that killer code that will skyrocket Meetup in the App Store rankings because we have the best A/B testing feature ever! At least that’s the hope right? But how do we even write the most effective code for this task? I started looking around and I see all of these fancy classes, methods, and protocols written by others and am tempted to write a cute class for this myself. I mean I have to show I can roll with the cool code right? However, don’t get ahead of yourself. Some things are meant to be kept simple. If there is no need for a complex class that does something simple, don’t introduce it.
Oftentimes, the best way to ship code is to copy a pattern that already exists. Yup! I said it, it’s okay to reference existing code patterns written by your fellow engineers as long as you give credit where the idea came from or link to it. Matter of fact, it’s actually encouraged to have the team aligned on shared architecture as it keeps things consistent and easy to follow. (That in itself could be a topic for a whole other blog post)
Conclusion
The main takeaway from this post: it’s completely normal to feel lost or overwhelmed when navigating a new codebase. However, given some of these tips, it will make it easier for you to find what you are looking for and where to commit your changes. The more you poke around, the more familiar you’ll get with the codebase therefore making things easier down the road.
Happy coding!
