The Obsessive Programmer’s Guide to Surviving A Huge Codebase

Programmers who want to do it for a living are always in for a shock when they get their first programming job. There are the added pressures of deadlines, office communication, customer demands, and the like. These are well understood. However, there is a pain point that is rarely addressed, and can remain painful for a programmer late into his or her career. It’s difficult to make the transition between coding by yourself and coding as part of a team. In school or on independent projects, you knew the whole codebase because you wrote it – or co-wrote it with one or two other people. You knew where every module was and what every function did, and in case you forgot, all the coding standards were your own, so you found it all easy to read. And, since the whole project was written by one person, it was comparatively small. It was easy to make sweeping, system-wide changes. When you first move into a larger team, suddenly the codebase is an enormous thing, written by others and not understood. And it’s your job to improve it. It takes some getting used to.

This should go without saying, but learn to love source control, and become an expert at using it. A large but hopefully shrinking percent of schools do not teach you about source control at all. It’s indispensable. In particular, get used to a tight integration cycle, and become very good at reverting and un-reverting your changes.

Don’t panic! Learn to accept the fact that you won’t understand everything. Trite, right? You might be surprised how hard it is to pull off, though. In a sufficiently large codebase, every bad practice will be represented somewhere. Programmers are perfectionists, so this makes us want to tear our hair out. You just have to come to terms with the fact that you can’t fix everything at once. If you want, keep a to-do list. Wiping one thing off of it may not be a tremendous win for the company, but it’s great for your sanity!

This is not to say that improving the code isn’t important. It just means that you may have to accept that parts of the code aren’t pretty and instead focus on more important things, like global performance improvements. Learn to see the big picture, and focus on doing things that can help the whole codebase at once rather than one module at a time.

You won’t understand the whole codebase. Neither will anybody else. However, every piece of the code was written by someone, so for any area of the code, there will be someone who knows it. You’ll often need their help, so you’ll need to know who they are. Learn who the domain experts are in each area of your codebase. Apprentice yourself to them. Spreading knowledge through the company makes everyone stronger.

Apprenticing yourself might not sound very attractive to the Obsessive Programmer. Fortunately there’s something you can do that lets you be the guru. Become the domain expert on some area of your codebase. Your obsessive nature will make this come easily to you. Find a poorly understood section of the code, or a module written by someone no longer employed at the company. Or, find some body of knowledge so in-demand that the current domain expert has become a bottleneck – making it useful to become a second expert in that area. Being a domain expert has the side benefit of making you hard to lay off.

Once you have become a domain expert, share your knowledge, ideally through paired programming. You’re a stakeholder in the company, and you want everyone to learn. Spread your expertise around until it’s commonplace, then find a new area of expertise.

Last, I can’t overstate the importance of learning to write good tests. People are going to use your code. People are going to change your code. People are going to break your code. Tests are your last, best line of defense. How to write good tests is a big topic, so I won’t go into it here. You can get some very good information over at the google testing blog.

Working a real job may be more stressful than coding on your own, but you should see that as an opportunity to get better. Shut up and man up. It’s worth it.


4 Responses to The Obsessive Programmer’s Guide to Surviving A Huge Codebase

  1. Chad says:

    Good post; I liked it.

  2. Ben McGraw says:

    Your best so far.

  3. Mike Rooney says:

    Nice indeed! But what kind of lame school doesn’t teach VCS or working with existing code? At RIT version control was a requirement in multiple courses and at least one project in a higher level class was taking a project written by freshman for their first SE class, learning it, and refactoring aspects of it. I enjoyed this experience and it was added recently in direct response to students complaining they didn’t get any experience in that sort of thing.

    • joblivious says:

      The closest I ever got to learning “working with existing code” was once when a professor simulated it by doing the first half of your assignments for you. I never got taught source control, ever, and other people who went to school for CS tell me I’m not the exception – although this is insufficient data, and based on hearsay, it’s the only data I have.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: