Community Benefits from Peer Code Review

Nobody likes being told that they’re wrong, right? Unless, I guess, you’re some kind of masochist. Personal quirks aside, though, everybody can benefit from somebody else taking a looking at their work and providing feedback. It happens informally all of the time; you post some non-working code to Stack Overflow so you can get some help from folks whom you hope will have a better sense of whatever you’re trying to tackle. Is this code review? Sort of. You’re asking for help, and while you’re not specifically asking for feedback, you’re sure going to get it.

Before you know it, users will be chiming in with what you’re doing wrong, what you should be doing instead and (hopefully) why those things are true. The next time you attempt to write some functionality similar to what you had previously posted, you’ll already have the knowledge to avoid the same problem from happening again.

Aside from solving a one-off problem, how else can you benefit from peer code review?

Standardizing Your Code

For one, you can standardize your practices. Here at WDS, we strive to standardize our code and processes at every level. We’re not only following WordPress’ coding standards, but standards for Sass, JavaScript, the whole nine yards! The point is to make sure that if someone else needs to pick up where you left off they’ll be getting a bit of a head start and won’t feel so lost when diving in. Hopefully, you’ve documented your code well enough that a new person can immediately know what you were doing and why. If we’re using standardized naming conventions then someone new should be able to search, find, and fix or change anything needing adjustments.

Standardizing your code even helps you in the long run. You won’t have to second-guess yourself on how to name a variable or a function. You’ll have it ingrained within you that you always use this type of naming convention for A and this type of naming convention for B. Gone are the days of milling over a function name for six or seven hours. Now you’re just pounding those puppies out like Mavis Beacon!

The mere possibility of handing your code off for someone else to work on, however, shouldn’t be the only reason you strive to write better code. We should always be in the mindset of learning and improving even if we’re the only ones who will be working on a particular project or feature. So, how do we do that? We ask for help.

Getting Help and Advice

Even when we do not need it, we ask for help. If our code works fine and does the exact thing we want it to do, we ask for help. In this case, we’re not asking for help with a problem – we just want someone with perhaps more experience to look over our code. To read our code. To judge our code. To scrutinize every bit of our code, and then come back to us with what we did well and what could be tuned up.

In time, and with enough positive feedback, you’ll pick up on these little changes, and you’ll be putting them into action without necessarily needing that aspect of your code reviewed. Now you’re moving onto something more complex and you need eyes on that, while at the same time someone else is now coming to you for advice on how they can write a piece of code more efficiently. It’s all cyclical, but not if we don’t first admit that we are a part of a team and that we can all lean on one another to get better, smarter, faster.

This works both ways, however. When you present code for someone else to review, they may see something that they never thought of. You could BLOW THEIR MIND. Imagine that? Writing something and asking for feedback, then being told that because of what you wrote, you’re changing the way someone else will work? The feedbacker has become the feedbackee!

The Beauty of Teamwork

That’s the beauty of this whole thing – this whole “internet” and “working in a team” and “trying to get better” business. Nobody ever stops improving, and if you think you’ve got no improving left to do, then you’re probably stagnant and not pushing yourself anymore. Try something you’re unsure of. Force yourself out of your comfort zone. I’m uncomfortable for almost all of the hours I’m awake, and I’m doing just fine!

I’ve had the pleasure of working with an incredible team here at WDS, who is always open to provide and ask for feedback. It can be a little scary first starting out with a new company or a new team; you don’t want to ask too many questions because you don’t want people to think you don’t know what you’re talking about. After all, they hired you because you know how to do your job – how dare you ask questions!

Only nobody reacts that way. We want questions. We YEARN for questions. If you’re asking questions, it’s because you want to get better at what you’re doing or because you see something that seems off, and you’re unsure of why it’s being done. In either case, you’re not letting your brain get lazy and bored. You’re pushing yourself to learn more and to know more and, in the end that’s what’s important because that’s what keeps us all rolling forward.