Cold start to joining a new dev team?


#1

I will be joining a new dev team at a small start up in two weeks. Three back end devs, and a few front end devs. I will be a backend dev. What should I be doing in my first week to quickly learn what the team is up to so that I can start contributing?

In practice, what have you done that works? What does NOT work?

Want to make sure I am off to a good start w/o taking up my teammates time.

This article was the inspiration for this topic: http://boz.com/articles/career-cold-start.html


#2

Hi cat-turner!

This is an excellent question. Kudos to you for thinking about this!

Are you joining at a junior level, or more midlevel or senior level? Do you have any sense of the relative levels of the other programmers you are joining?

This info will help me answer your question with techniques that are better for your specific situation.

C


#3

That sounds like your team is a bit bigger than Meta was when I joined them. Here’s some of what I remember

  • My top tip (also was my top tip in my guide to COMP 105 at Tufts) is talk to everyone. It’s challenging picking up a big codebase, so talking with teammates about the code you’re learning will help you figure out what everything is supposed to do (this I also found useful when Meta and Diffeo merged since I had to learn my way around the parts of the Diffeo system)
  • In particular, learn how parts of the system talk to each other. Knowing this means you’d be able to contribute in more areas of the code, and ut will also help you understand how things fit together from the product perspective as well as engineering
  • Take notes on where you get stuck preparing your setup (environment variables, editor, programs installed, etc). Getting these things fixed will help you prevent configuration-related bugs, which are always a pain to track down, and it will also smooth the onboarding process for anyone joining the team after you. And a lot of the manual parts of the onboarding process can be automated, so if you can get that part of the onboarding into a shell script, that’s always a good contribution
  • Learn the deployment/CI process in particular early on, especially in startups that size, where everyone should be able to help land hotfixes and get them deployed if a bug gets shipped

Also, Safia Abdalla has a good blog post on getting started in a new codebase https://blog.safia.rocks/post/170269021619/tips-for-reading-new-codebases


#4

I’d also recommend pairing up with another backend-dev as well as a frontend-dev and working with them for a couple of hours straight. Maybe first observing and making notes, then taking the driver’s seat and letting them guide you through the work.

Ask questions, no question can be wrong, be curious, don’t challenge everything (yet). Get to know the people, the codebase, the reasons for the current state of affairs. It will give you a good start to start sharing your insights, thoughts and ideas without coming over as a totally ignorant critic :wink: .


#5

One point I’ll make is that I think it’s important to try to learn the domain and the product on a conceptual level, not just a technical level. That is, don’t just try to understand what the data contains and how it flows – try to understand what the users are using the product to do and how they think about it. Especially if it’s a domain that you haven’t worked in before. My current position is in a very specific domain (university admissions) and I took longer than I should have to get up to speed because I approached it primarily through the code. I would have done better to ask a lot of questions about the admissions process itself first.

In a similar vein, I like to ask someone to walk me through the “happy path” of a given process first, so I can look at the code that supports that path. It’s important to also, later, understand the code that supports the variations and oddities, but it’s confusing to start by looking at all of the code at an equal priority level.

A question I often find useful is “can you sanity-check me on this?” followed by a summary of how I think a certain part of the system works.

Another key thing to start making notes about very early on is: who is the point person to ask about a given topic? You don’t want to pester anyone, but if you know that financial questions go to Tracy and data integrity questions go to Neena, you can move a lot quicker.

Good luck!


#6

Hello! I’d say I’m mid-level compared to my team. All are senior level engineers. I’m sure I will have lots of learning opportunities, so am ready to enter sponge mode!


#7

Great tips! I have access to design docs so I’ll be sure to check those out!


#8

Solid practical advice. I’d say my biggest concern is getting aquainted with code base but with these tips I now have an idea of how to read the code base. Ty! :sunglasses:


#9

Thank you for asking this question - I’ve just started as a junior and the responses are very useful to me too.


#10

This topic was automatically closed after 3 days. New replies are no longer allowed.