Learning A New Codebase

A photograph of a hand scribbling out the "not" in "cannot"

A few days ago, my friend Ed Finkler started a new job. Earlier this week, he posted on Twitter:

Having begun a new job myself, I shared Ed’s sentiment. Last weekend, while at the Madison PHP Conference, we were discussing what developers can do during the interview process to get an idea of the kind of codebase a company has. After all, the developer is interviewing potential employers just as much as they are being interviewed as a potential employee. It would suck to be hired only to find the code is in shambles. Short of signing an NDA and asking to see the their code, what can you do?

Here are a few tips I think go a long way in helping determine the state of a company’s codebase. If you have other ideas, feel free to leave them in the comments.

  1. Ask what coding standards the company follows. Can they articulate those standards well? Grill them on specifics. Be sure to ask this of the developers and not the managers. Otherwise, you might not get a good picture of how standards factor into their practices.

    For PHP projects, you should hear something about PSR-2 and PSR-1. If not, then at least the old PEAR coding standards should come up.

  2. Ask whether the company uses a dependency/package management tool. Answers to this question are a good indication of whether the company subscribes to a not invented here (NIH) philosophy. Companies that reuse code from a variety of third-party packages tend to—in my experience—have better structured and cleaner codebases. I’m not sure why this is, but I suspect it’s because the developers have more exposure to how others are doing things and pick up on best practices in this way.

    For PHP projects, you should hear the company talk about their use of Composer. At the very least, they should mention PEAR, but PEAR is waning.

  3. Ask how much of the code is covered by tests. There are unit tests, functional tests, integration tests, and acceptance tests. Maybe there are others that I’m not aware of. Start a conversation about which testing strategies the company uses and how many tests they have.

    For PHP and web projects, there are many different testing tools available. At the least, I would expect to hear a company talk about PHPUnit, but even if they don’t, there are plenty of other unit testing frameworks for PHP, so they may have chosen to use something else. If so, ask why. Questioning a company’s decisions isn’t important, but I think it is enlightening to understand what factors go into their decisions.

  4. Ask to have the company’s deployment process described. As a developer, will you deploy code, or is that handled by different people/teams? Will you be able to push code on your first day or in your first week? The timing isn’t as important as the processes around deploying, though. Try to get a sense for whether it’s a clean and straightforward process versus a haphazard and error-prone catastrophe.

As a follow-up, after you join a company, you are now faced with the daunting task of learning a new codebase. This morning, Ed asked in the #phpmentoring IRC channel on Freenode:

<funkatron> How do you deal with coming in to a huge code base you're not familiar with?

Here are the two tips I offered from my experiences:

  1. Go through existing bug reports, fixing bugs. This helps you learn the code base, while feeling productive.
  2. Write tests. If they don’t have tests, start a test project and start writing them. Aim for some low percentage of code coverage (i.e. 5-10%) at first. It’ll help you learn the code base quickly.

What are your tips for questions to ask potential employers and learning a new codebase once you’ve begun a new job?