On the journey of my career, the variety of stops has been numerous and eclectic.
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, must be reviewed by several people.
Usually this is because of HIPAA or ISO or some other sort of security/quality standard.
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. And you should probably backup the C code from time to time."
"That's crazy — what kind of shop doesn't do code reviews?"
You’d be surprised at the amount of shops who don’t have code review in their development process. Some of you are probably thinking, "I wish I had that problem because I'm sick of micromanagement."
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 those grizzled senior developers. 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.
Unfortunately, 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. Here are four ideas to consider:
1. 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 lot of these senior developers are trying to figure out how to advance their own 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 even to them because they've probably heard a line manager offer them vague advice on how to move forward. A few examples may be "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.
2. 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.
3. 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.
4. Turn 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.
So embark on a series of concrete steps. Convince senior developers that helping you helps their careers. Convince your manager to help you get more feedback. Get yourself some high profile assignments, and, if all else fails, crowdsource your code reviews. These are vital steps toward making yourself a better developer.
The Complete Guide To Approaching Your Development Team When They Write Bad Code
In our newest eBook, The Complete Guide to Approaching Your Development Team When They Write Bad Code, you will learn:
- How to approach your developer’s bad code
- How to build the appropriate strategy before having the conversation
- How to collectively take responsibility for bad code
- How to set a coding standard within your team
Get your copy!