#AQChat 2 Q1: I have joined a new team. What can I do to ramp up within 90 days? 🏎️️


#1

#AQChat2 Question 1: I have joined a new team. What can I do to ramp up within 90 days? :racing_car:️️

Why ask this question?

  • You are have joined a new team.
  • You have started a new project.
  • You are learning a new programming language.

Goals:

  • Fill any knowledge gaps that affect day-to-day work productivity.
  • Learn new material to contribute to the team.

Looking for advice on…

  • How to learn a new code base.
  • How to self-study topics related to work and/or new responsibilities.
  • Advice from lead and senior engineers: how do you ramp up newbies?

This question is centered on results. Advice and/or stories that describe what you did and the outcome of it would be appreciated. Please be sure to give 1 or 2 concrete examples. If you are a senior engineer please consider describing your onboarding process. Concrete examples describe things that you have done, not ideas or concepts. We’ll save those for the next question.


#2

With respect to learning a new code base:

I’ve always found that trying to document undocumented functions or types, or otherwise just improving existing docs, is a great way to learn a code base. When writing docs I it feels good to write as simply as possible, yet sufficient description of something. And that constraint kind of guides the way to learning how a thing works.

Now there will still be times when simply trying to read and reason through the code won’t be enough. In those instances, I always like to break things. A debugger is nice, but if you don’t have one then you can always throw a rampant error and then you get a beautiful stack trace leaving you a breadcrumb to go follow. :slight_smile: That, and good ol’ print statements.


#3

When I joined Meta Search, getting onboarded for me involved learning a lot about how the different parts of the system were connected. My first major PR on there was writing Go test coverage for one of our microservices, which had me think about how the service was being used. I find especially that on a team, getting assigned things on places outside “your” area is really effective for seeing how things interact.

For side projects, I’m working on a tab visualization, and at the time I started, I was relearning JavaScript in 2017, so the JS world looked really different from when I was last doing JS in 2014, and a big challenge was that while no single JavaScript tool was hard to wrap my head around, the challenge was figuring out how to compose them into modern JavaScript, and I was trying to learn too many things at once (I think first attempt I was going at React/Flow/Webpack simultaneously). I found that what helped a lot was integrating one tool into my code at a time so, again, I was figuring out how the parts of my system or JS build talk to each other. Good documentation and examples are definitely important to check out (and if you can’t find those, those make great PRs to the tools you use), especially if you’re working with a dynamically typed language like JS.

So in both cases, I was thinking about what each part of my stack does and how that affects other parts, but in opposite ways; on the job by working with existing code, and on my side project by building from the ground up with tools once I get into the “kinda know it” level


#4

Great idea with the docs Henry! I have been reading about different ways of taking notes and one idea I saw in a video was about writing sentence summaries of paragraphs of the textbook, so coming up with the docs would be a code equivalent of that. I think my approach with the tests is similar, especially in Go where tests are used as documentation


#5

Thanks! I think I will try this! Solid advice and is easy to try out. Plus everyone wins!


#6

Personally I work best with a defined goal.

On self-study:

  • Pick a language you’d like to work with.
  • Define a goal (build a crud app, try out a new way to build something at work)
  • Watch or go through an entire udemy course, keep your hands-on keyboard because you will be coding!
  • Complete project
  • Read articles and take notes to digest concepts.

I would do this in quick cycles, about 1-2 weeks. I have learned this from my time at CareerDevs, a community focused on self-learning tech.

It is also important to

  • Set a deadline. 90 days is a good start for a capstone project or 2. Two weeks is good for a class.
  • Set up a battle station. This should be a place where you know you can plop down your thinks, and be assured they will be undisturbed.
  • Set up a do-not-disturb time. This will allow you to focus on what you need to learn. Set aside 2-3 hours of time to focus and work quietly. Take a break, then try again. The idea is to do this consistently so that you are in practice. You will have to say no to distractions.

#8

Yeah, consistency is another must with getting good at a new skill, especially if you’re practicing at the same time each day, and that’s especially important in side projects where you have a lot of time between sessions of work to lose your context. I also find Trello boards really useful for keeping organized so that you can see work that you can break off of the project


#9

Yes to trello! I use kanban flow! It has built-in timers with the cards so that I can track the amount of time I spend on a task.


#10

When I got a job as an SRE at Google, I felt I ramped up the quickest when I took on the task of porting all the team’s tests to the new test infrastructure. I came away with a better understanding of what we were doing and how we related to the teams around us.

What I think was important:

  • each tiny piece of the work was relatively independent, so I had frequent small successes
  • the task touched every thing the team was responsible for, so I gained a big picture of our responsibilities
  • I needed to meet through code review key people important to our team, so I learned our place in the company