Learning A New Codebase
Theme 1: Change, by Jerry Wong / CC BY-NC-ND
A few days ago, my friend Ed Finkler started a new job. Earlier this week, he posted on Twitter:
First days humble us all.
— Ed Finkler (@funkatron), September 16, 2014, 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.
-
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.
-
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.
-
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.
-
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:
- Go through existing bug reports, fixing bugs. This helps you learn the code base, while feeling productive.
- 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?
7 Comments
The best question I find is "What steps are involved for me to ship code from day 1". If the interviewer is technical enough they'll be able to walk you through more detailed steps about what their CI/CD solution is (or release process if not CD) If they're too far removed from tech it shows quite rapidly without having to ask too many further probing questions. It's also a good test to see whether or not they think you'll be able to ship code quickly or not.
I have recently joined a new company and have faced this exact task. There was (still is) a big project ongoing and I was supposed to help out pretty much starting day 2. I've gotten some explanation on parts on the project though in all honestly they didn't really help at all. I was overwhelmed.
So what I did was debugging. I literally just went through a couple of requests of the application (endpoint taking in a soap request, being handled later by a couple of pre-defined tasks of the main application) and checked how the code is being processed. Doing this for many requests I learned the pattern of what happened and managed to understand the current code-base fairly well.
I'm three months in now, still don't understand it all 100% but with every bug report I pretty much always know exactly where to look for.
So TL/DR: debug the code!
I didn't survive working for a startup because I got overwhelmed by the very messy codebase. Was not having fun at all. Daily headaches. Would not choose to do that again. But this article does give me some insight into what I could've done differently to keep myself in a positive light with management.
I actually really enjoy being able to clean up awkward code. I don't interview much but whenI do I always look for roles where if I am working on legacy code I will have the opportunity to fix as I go.
To get familiar with the code base I am similar to Manuakasam. First thing I set up is the debugger. Second thing is getting an idea of the data model. Third is taking a lower priority ticket that I can spend a couple of days on if necessary and use that as a spring board for debugging. Your team will gain confidence in you quickly if you are able to quickly become a productive teammate. Their confidence will then boost yours.
The last recommendation I would make is to not wait until you have a new job to learn new code bases. Reading new code is a lot like reading music. You can take it in more quickly if you do it on a consistent basis.
Seeing as I'll be interviewing at place in the morning, the timing of this piece couldn't have more perfect. Thanks Ben!
The piggy back on what @manuakasam:disqus said, I find one of the best and fastest ways to acclimate yourself to a new code base is to debug the code. When I started with the company I am currently at, that was the first step to onboarding. Every engineer was placed on the bug fixing team until their efficiency and comfort with the code was at a point where they could quickly ramp up to a very specific portion of the application and own it. I can honestly say that fixing bugs makes for a very fast learning process AND keeps one productive without having to know everything about the code or the way it is all tied together.
As far as questions to ask of your interviewers... one thing I think that is important is to ask the engineers themselves - NOT THE MANAGERS - what the dynamic is between the producers of the code and the directors of that code. Find out what makes an engineer happy to work there, or in lieu of that, find out why they might not be happy to work there. After all, you will be "one of them" if all goes well, right? It would make sense to get a vibe from your future team BEFORE signing the offer letter. It's also a good idea to ask as many of the engineers as possible what the last cool, innovative thing they worked on AT THAT COMPANY is. Have them describe it, have them tell you what management did to facilitate their ability to get it done. Find out their time commitment for that project and how they feel about the overall product of their work. I think a lot can be said for that.
My questions to employer are:
5. "What if product deployment will cause a critical fails? How long does it take to rollback changes on production?" It is an addition to questioning about Continuous Delivery that will get you to be sure whether you will sleep well at night.
6. "Is your codebase well documented? Is documentation relevant? Are there any tutorials?"
7. "Is there any aboriginal code developer who is familiar with codebase and can teach me?"
8. "May I have a personal test environment where I can torture the codebase without affect to other?"
My tips about leaning the codebase:
3. Read the documentation if it exists. Check documentation is relevant. Create new or correct if not.
4. Do not try to learn everything on your own. Talk, talk and talk to other developers about codebase.
Maybe those questions and tips will help you to find the perfect job of your dream. But sometimes you will have more interesting job if employer has no answers yet but want to have them.