Podcast
Get Unstuck
Most teams have some sort of code review process. When you're the developer submitting your code for review, and then you get back a list of questions or corrections, it's really easy to feel defensive. Over time, you can even start to view this process as "a waste of time" or something that becomes adversarial.
I get it. I've had these feelings at times too, but I've come to really appreciate the value of code review to not only make a better application, but to make me a better developer.
Probably the easiest feedback to value is when the reviewer finds a bug in our code. No one wants to ship bugs, so it's easier to be grateful that the reviewer paid enough attention to catch that before it got merged and deployed.
Some feedback is more along the lines of "why not do this instead?". For example, in a recent code review, Aaron pointed out I was doing a conditional check in a Blade view to optionally add a CSS class name, but Blade gives us a simpler @class directive for exactly that purpose. My code worked as expected, but it could have been simpler and more conventional to use the helper Laravel provides. This makes the code easier to work in, and it also was a good reminder to me about this useful feature I forgot about. Over time, reminders like this make us better developers, and sharpen our skills.
Probably the hardest feedback to accept is when the reviewer doesn't quite agree with something, but they can't fully explain why, or they don't have a specific suggestion to improve it. For example, Aaron recently added a comment in a PR like "this function name just doesn't feel quite right to me" and my initial reaction was to dismiss it or argue that it was fine. When we talked it through (sometimes a quick pairing to talk through review comments is the most productive way to resolve it), and I tried explaining why I gave it that name, I did eventually see his point. We paired on it for 10 minutes and came up with a much clearer name, and it actually led to a refactor which made the feature easier to maintain overall. So this vague "gut feeling" which initially annoyed me turned into a tangible improvement to the code.
So the next time you get feedback during a code review, try to put aside those initial feelings of defensiveness, and appreciate that this teammate has the same goal as you: to ship quality code. And, it just might make you a better developer along the way too.
Here to help,
Joel
P.S. Ever wonder if your Laravel app could be more secure? Download our free book for 7 steps to review.