How to Get People to Review Your Code

Editorial Note: I originally wrote this post for the SmartBear blog.  Go check out the original here, at their site.  If you like this content, there’s a lot more over there, by numerous authors, to check out.

On the bus ride of my career, the stops have been numerous and eclectic, much like a line that runs through an entire city.  On the subject of code review alone, I’ve seen the gamut.  I’ve worked in an environment that prided itself on mandating that every line of code, written anywhere, be reviewed by several people.  Because HIPAA or ISO or something.  I don’t recall.  I’ve also been in a situation where my instructions were “here’s a bunch of C code on a hard drive, and if anyone else ever looks at what you do with it, that will be because you’ve done something terribly wrong.  Oh, and you should probably backup the C code from time to time.”

I mention this because I’m anticipating varied reactions to the title of this post, which is very much “what you see is what you get.”  I’m going to offer you advice on how to convince people to review your code.

A lot of you reading are probably thinking, “that’s crazy — what kind of shop doesn’t do code reviews?”  Some of you are probably thinking, “I wish I had that problem because I’m sick of micromanagement.”   But, even if it seems improbable to these two groups, there’s a cross section of folks reading and thinking, “Yes!  I’d love to get some feedback for once.”

Believe me when I tell you that there are legions of folks out there, particularly less experienced developers, that would love more feedback.  They’d love to understand the tricks of the trade from grizzled veterans.  They’d love to learn to anticipate mistakes and pitfalls before getting calls outside of working errors because they’ve dumped some avoidable bug into production.  They’d love to improve their craft in ways more interactive than online training videos and books.  But, they don’t have much luck.

It might be that they’re lone developers in their small companies, and, if that’s the case, there’s not all that much to be done as long as their solo labor remains the status quo.  But, more likely, they just work in a group where the development labor is heavily siloed and/or where all of the experienced developers are extremely busy.  In this scenario, there is plenty that can be done to secure meaningful feedback.

Appeal to Career Goals

If you’re early in your programming journey and career, the senior developers around you probably seem like impressive figures, full of worldly knowledge of the industry and battle scars from noble fights.  You’ll have a natural tendency to view them with some degree of reverence, or at least deep respect.  And that tendency is going to make what I’m about to say seem surreal to you.

A significant cross-section of the senior developers whose advice you want are trying to figure out how to advance their careers.  It’s hard for you to fathom, since you’re aspiring to be them, but they’re aspiring to roles with titles like, “architect,” “team lead,” “principal,” or, perhaps even, “dev manager.”  And, even more interestingly, a lot of them really have only a vague idea of how to get there.

Their way forward is vague to them because they’ve probably heard a line manager offer them vague advice on how to move forward, such as, “you need to focus more on how IT serves the business” or “I need to see more leadership out of you.”  That last one is your key.  You need to get them to view reviewing your code as something that aligns with their career goals.

This really isn’t as daunting as it sounds.  It’s mainly a question of using slightly different words.  Phrase the review activity less in terms like “performing code review” and more in terms like “mentoring.”  Make it clear that you’re asking for leadership and not just a favor.

Appeal to Management for Structure

While it’s great if you can help the technical leaders in your group view reviewing your code as beneficial for their careers, there’s a parallel tack that you can take as well.  You can talk to actual line management about how more feedback can be baked into your organization’s workflow.

If you’re going to do this, it’s important that you frame the situation correctly and that you don’t come off as saying, “the experienced folks don’t make enough time for me.”  That’s not going to win you friends or favors.  Instead, approach management by suggesting that the senior folks currently have workloads too heavy to provide this kind of feedback for you, and brainstorm creative ways to alleviate that.  Maybe the company could buy everyone pizza once a week for lunch, provided they spend the lunch reviewing code and offering feedback.

Ask for Important Assignments

If the approach of soliciting more time from senior folks, either directly or indirectly, isn’t for you, consider creating a natural situation where you’ll get additional eyeballs on your work.  Lobby for assignments that are higher profile or more critical path for collaboration on your team.  This will naturally give rise to more people looking at what you’re doing with interest.

If your group is responsible for a public-facing website, and you’re toiling away on some internal line of business automation, none of the developers are going to care what you do.  If, on the other hand, you’re responsible for an admin screen in the upcoming release, other developers in the group are going to be dependent on your work.  They will thus have a natural, vested interest in reviewing your code.

If you go this route, however, be prepared that all feedback may not be sugar-coated.  People tend to be more blunt when the pressure is on.

To The Internet!

If all else fails, have the internet review your code.  You’ll find no shortage of opinions, I assure you.  You can post gists to Github and ask people on Twitter or some other venue to review them for you.  There’s even a stack exchange site dedicated to code review.

If you’re going to do this, be careful that you aren’t posting proprietary code.  It may be necessary to obfuscate what you’re going, removing telling variable names and references to objects specific to your domain.  That’s fine.  Take a little time and create a generic example of what you’re doing to see if internet reviewers think you’re on the right track.

You need to figure something out.

I can think of no faster way to improve than having people review your code and provide feedback to you.  If that isn’t happening for you, there is a very real risk that you’ll languish in your career without much meaningful improvement.  You need to figure something out.  You need to get your code reviewed, even if it means getting creative.