Daniel Irvine on building software
Working with a new codebase
9 May 2013
I started a new job recently and so far it’s been a nerve-racking experience. The big challenge has been switching codebase: moving from a comfortable, in-depth understanding of the world to knowing absolutely ziltch. This is a typical experience for programmers and feeling lost is to be expected, although of course we’d all prefer if the feeling was only momentary.
Working with an unexplored codebase is like traversing an uncharted jungle. It’s 99.999% likely that you’ll end up going the wrong way. In a jungle, you’re going to hit the uncrossable river, the steep cliff, the lion’s den. In a codebase, you’re going to make poor design decisions and you’ll introduce bugs and make schoolboy errors. Until you plot the mental map in your mind, you will get lost and that’s going to show in any code you write.
Here’s my advice for any programmer that’s changing job:
- Acknowledge that you’ll likely be producing poor-quality code--or at least, poorer-quality code than what you were writing at your previous job. Not just acknowledge it, but forgive yourself for it and don’t let it get you down. You will get better.
- Not all codebases are created equal. Some will be easier to navigate than others, and the tools you used before may not be useful to you. Some codebases may even have pre-written maps in the form of BDD-style tests. Whatever you’re faced with, just keep reading and writing that code--remember that practice makes perfect.