How to ramp up on a new team and stack quickly

I joined the Messenger Privacy Experiences team as an iOS engineer about two months ago. New team, completely new stack. I’d never written any apps before, iOS or Android, nor had I written any Objective C.

Here’s some of the strategies I’ve used to build up context quickly.

Consolidate Wikis and Internal Posts

The first component of learning is getting a sense of the big picture - where each of the individual pieces fit in.

Inspired by my digital garden here on my website: I did this by just writing what I learn! I created a document where I’d pretty much jot the key takeaways as I read the wikis and posts, and linked to the full posts where needs be. The idea is that this knowledge base doesn’t have to copy across perfectly fine wiki pages or posts, it just needs to be a central hub.

When doing this, you have to have your end goal in mind. If you’re only working on a specific part of the stack, then only read up on that much. As my manager advised, it’s way too easy to over-index on this and just spend too long reading and not enough time doing.

Since I’ve ramped up, this doc has gradually expanded as the framework for a high-level overview of the connected areas, e.g. as iOS engineer, this includes some understanding of what the Android team, designers, product managers and infra teams are working on.

Ask Team Members for Braindumps

Having got a high-level overview through wikis and docs, the next step is to deepen this knowledge by gaining specific context from each member of the team. I organised 1:1 meetings with everyone on my team, in which I spent:

• 5 mins on introductions and getting to know how they work
• 20 mins asking them to braindump everything about this area, and what they’re working on
• 3 mins on what the current/upcoming problems are
• 2 mins on who you should speak to next

Doing this breaks the ice with everyone, gets you up to speed on the current context, and the problems the team are trying to solve. I then spent time going through my notes and consolidating them into my knowledge base doc.

Now I think you can probably skip the first step of going through wikis and just talk to team members, but I personally feel like having a little context and preparation beforehand helps me ask better questions, and is more respectful of the other person’s time.

Write and Review Code

There’s no getting around it. My manager put it this way, learning is:

• 10% reading
• 20% coaching (from other team members)
• 70% doing

Up until now, the tips build up a conceptual understanding of the codebase, but as a software engineer, you have to write code to understand the nitty-gritty.

Write code, fail fast and learn from code review. Much as I discussed in my internship advice post, it’s a case of leveraging the fact that no one expects you to know anything because you’re new to the team. To overcome the impostor syndrome, you can even tag your Pull requests / commits with WIP (work-in-progress) or Feedback requested.

I would also recommend reviewing other team members’ code as soon as possible. To start with you can just observe, trying to put yourself in their shoes and ask how you would approach that. As you become more confident, perform the first review of the code, and then watch how the more established team members review the code after you. Like with feedback on your own code, note down the things they spot that you missed. It’s perfectly fine to say “I’ve left some comments, but I’ll defer to Person X to accept/reject this”.

During code review, both when I am writing and reviewing code, I proactively ask questions about parts of the code I am unsure about. Something like, “Just for my own understanding, why did you do X this way?” or “I’ve implemented it this way because of X. Are there better ways of doing this?“.

Pair Program to Unblock Yourself

Now this is not a strategy I’ve used myself, but rather one I actually learnt when onboarding another engineer onto the team. Barely a month into the team, I was onboarding someone who is way more senior than I am, but I just happened to have more context about this particular project.

Pair programming helps you onboard in two ways. First, the obvious, pair programming lets you ask questions about the nitty-gritty of the codebase. The second, pair programming is an opportunity to observe the workflow the other person uses, whether it’s IDE shortcuts or how they debug.

Accept that ramping up takes time

If you’re anything like me, it’s easy to be impatient or anxious about not feeling like you’re able to contribute to the team.

The impact you have when you’re fully ramped up will far outweigh the time you spent ramping up.

It’s not just about getting through the tasks you’ve been assigned as quickly as possible, but rather a case of taking a bit longer to really understand the fundamentals of the stack you’re working with. E.g. understanding the difference between strong and weak references in Objective C.

It’s all about celebrating the small wins along the way. And then before you know it, suddenly you’re the person who’s onboarding other people!

Bonus: debugging - the baptism of fire

I ended up picking up some API knowledge by accident really - there was a critical bug that needed to be resolved for an internal deadline. Turns out it was a chain of interlinked bugs, and investigating the root cause meant I ended up learning the hard way how the APIs we used in the iOS layer worked on the infra side.

Bonus: Your tips about ramping up

This post is just my experience of ramping up, but as I’m looking to set up processes to help new team members ramp up, I’d love to hear how you’ve gone about ramping up.

What worked for you? What did you find hard when joining a new team? What do you wish the other team members helped you with?

Send me a tweet or DM on Twitter!