I make part of my living these days as an IT management consultant, and in this capacity, I’ve developed an interesting niche: evaluation of codebases.

Specifically, an organization’s management will bring me in to spend a week or two looking through a codebase, sizing it up, and making recommendations for what to do with it going forward (e.g. stay the course, rework the architecture, targeted training, scrap it, etc.)

As you might imagine, this part of my practice has me looking at and quickly grokking a lot of unfamiliar code. Every few weeks, I’m squinting at strange classes, running static analysis tools, and making lists of assumptions and questions to ask the development team. I’ve found that this practice has benefits to me beyond helping me earn my living; I’d argue that it makes me a better programmer.

Consider the opposite situation — one that describes an enormous cross-section of industry developers.  They come into work each day and deal with the same codebase. This continues day in and day out for weeks, months, or even years.

This year, my wife and I are hoping to make a visit to the Galapagos Islands, which are noteworthy for the uniqueness of the wildlife there.  The animals living there have been isolated from the wider world of fauna for millions of years, and the result is that they’ve developed unique and unusual characteristics that cannot be found anywhere else. This is what tends to happen to codebases in shops where the majority of developers work in relative isolation. A bubble forms and practices drift toward the unusual.

For an individual, this isolation tends to put a damper on skill acquisition and can even be career limiting. It’s the polar opposite of the situation in which I find myself — constantly immersed in unfamiliar code. So how can you remedy the isolation (without drastic career moves, that is) if your professional life shows you the same code day in and day out? Well, the dead simplest thing I can think of is to seek out and review other people’s code. And to do that, there’s no better place to go than Github.

Here’s what you can do. Every few weeks or so, poke around idly on Github, searching for random codebases in your language of choice. Big or small, popular or niche, active or forgotten — it really doesn’t matter much.  They just need to be different and new.

Once you’ve found one (and just about any one will do), clone it and get the code locally on your machine. Open it up in your IDE/editor/environment of choice, and start looking around. If you start to perform this exercise with some regularity, here are some benefits that you can expect, in my experience.

Practice Getting up to Speed Quickly

Getting your bearings in a new codebase can be daunting, particularly if you’ve grown used to the same one over the course of months or years. Being able to do it quickly, however, makes you valuable, both on the open market and within your organization. This skill allows you to be plugged into projects where extra help is needed, obviously, but it also gives your organization flexibility. If they know you can be quickly proficient, they might be able to buy out competitor applications or ask you to tackle face-lifting a legacy project that had previously been considered untouchable.

When it comes to getting up to speed in short order, there’s really little besides practice that will give you the needed skill set. As such, going into a bunch of codebases in your spare time and poking around is really the best way to become skilled at going into foreign codebases and figuring them out.

Learn Architectural and Design Patterns

Practicing looking at lots of codebases gives you more than just familiarity and facility with the task itself. As you look at more codebases, you’ll also start to see and recognize patterns of development more easily, both good and bad. Maybe, for better or for worse, your application is a web-based one that uses an anemic domain model (domain objects basically have only properties). Looking at a lot of code will show you how desktop/app developers doing things, and what patterns are relevant there.  Alternatively, they may show you how other teams with similar kinds of applications solve similar problems differently from you.

Starting to recognize these things is the first step to understanding common usages and being able to make recommendations.  If you’ve looked at a lot of codebases, you’ll know when people tend to favor active record versus using an ORM. You’ll understand the tradeoffs between using DI frameworks with indirection and being more explicit but less flexible. You’ll feel and empathize with the cost of doing things in different ways so that you can speak with more experience when it comes to what you should do.

Expand Your Bag of Tricks

It’s not just the weighty architectural decisions that you’ll pick up, either. You’d be amazed at how many quick, little wins you snag with this practice. One day you’ll see a unit test naming scheme that you fall in love with. The next day you’ll notice a new language feature that will save you twenty lines of code in a lot of your classes. Or, maybe you’ll observe someone using semantics that makes mistakes a lot harder.

Whatever the case may be, looking at a lot of code means taking advantage of a lot of others’ experience. It’s not quite the same as having tons of people review your code, but you can realize some of the same benefits.

Feel a Little Better About Yourself

The last benefit that I’ll offer may surprise you. It’s certainly in a different vein from the first three: feel a little better about yourself.

Doing this will let you feel a little bit better about yourself because it will quickly show you that everyone is human. It’s easy to read books and listen to podcasts or talks and conclude that the experts out there are completely out of your league. But if you go out and review enough code you’ll start to realize that we’re really all just doing our best in a profession with a lot of changes and uncertainty.

In one codebase you’ll see dozens of global variables in every project, and in another, you might see some kind of weird convention that obviously seemed like a better idea than it turned out to be. Looking at a lot of other codebases and realizing that they’ve made and paid for mistakes can make you feel a lot less out of your own depth.

Do What You Can

There are 186 hours in a given week, and you probably spend 50 of those sleeping and 40 of them working, leaving only a paltry 78 for living your non-work life.  And I realize that it’s hard to make a case for spending some of those randomly reviewing strangers’ code on Github.

I’m not suggesting that you go nuts or that you radically alter your life. Rather, I’m suggesting that when you’ve got some downtime or a lull in what you’re doing at work, there are worse ways that you could spend your time than finding projects and learning from that code.