When you join a new development team or company, where do you start?

Here are a few things I usually do, to give me a quick at-a-glance sense of where I am. These things don’t require any special onboarding or knowledge-sharing session. You can do these things as soon as you have access to their systems, to begin learning.

• I run a static analysis/linter tool against the codebase.

  My goal isn’t to fix any problems at this stage, just to get a sense for whether the broken window effect is strong here.

• Execute the test suite.

  Is there a test suite? How complete is it? Does it work?

• Navigate the code manually.

  Start in a random spot. Or start at the top of the application and work your way down. Doesn’t really matter. Spend half an hour doing this, and take (mental) notes. Is the code easy to follow? Can you tell what it’s doing? Do you know why it’s doing it?

• Look at git history.

  Are the commit messages clear and well-written? Are the commits appropriately sized? Does each commit do one thing and one thing only (i.e. not mixing a bug fix with a new feature)?

  If the team is using GitHub or similar, also look at their pull request history. How long does a pull request tend to live? How large are the pull requests? What does the approval process look like?

• Take notes.

  Finally, through all of this, I encourage you to take private notes about your observations, and anything you think should change. I say private, because it’s too early to start complaining about these things. Just because your new team does something that seems odd to you doesn’t mean they don’t have a good reason. So keep notes of any complaints, then see if you can learn the reasons for these complaints naturally. After a couple weeks, if the reason for something is still unclear, feel free to ask. But of course, do it in a non-judgemental way.