Hacking Your Way Through Codebases

You’ve joined a new project, and you’re trying to fix a bug. You try to make sense of the classes, how they interact, what they abstract.. Looking at the design documentation, you realize that they’re older than your son. Previous project members seem to be vacationing in dense jungles in Zanzibar.

It’s a weekend and you’ve nothing to do. So you decide to add that feature you always wanted into your favourite open source library. You check out the SVN trunk and try to figure out where to start hacking away.

Does any of this sound familiar?

That “software development” involves more reading than writing of code, comes as a surprise to many industry newcomers. Books and university courses teach how to design, implement and test software. How to model, simulate and measure systems. How to design, analyze and improve algorithms.

Yeah, well. You don’t start off your career like that, kid. First, you get to make tiny fixes. Which requires you to go through a lot of code, figure out how the entire damn thing works, pinpoint the exact root cause of that sporadic bug; and then use all your education to make the most minimal code change possible to get rid of that bug. Oh, and the bug appears only when there are more than 50,000 people accessing the 4-million-row database table simultaneously, so don’t think about attaching your cute debugger and stepping through the code. Did I say it was sporadic?

If you pass out of the university having read nothing but the example code listings in the text books, then be ready for a rough time when you join the industry. Even if you’ve written your own nice little software. Because reading code is very different than writing it.

You can really judge how good a developer is be seeing how he responds when asked to fix a bug in a codebase which he’s seeing for the first time. The response is either of “what? in that? i didn’t get a knowledge transfer session for that!” or “by when?”.

So how do you do it? It’s many things, but mainly it’s experience and tools. “Ah, so you’ve a box of magical tools!” Well, no. You tend to end up using only what’s generally available, on most platforms and that too by default. Things like ctags, vim, grep and a debugger. That you’ve learned to use really well. But mainly, it’s the experience, and the intution and patience that comes with it.

The best reward of reading code is that you get to learn more from that than from textbooks. Ever seen how a Hindley-Milner system looks like in code?

Go read code. Grow up.