We are interviewing former AWS engineer and creator of "Master the Code Review", Curtis Einsmann. What should we ask him?
Hi Dev.to community, let's start an AMA thread.
On September 20th, we will have a live talk: “Becoming a Code Review Master”, with Codacy CEO Jaime Jorge and guest speaker Curtis Einsmann, a software engineer at Gumroad and previously six years at Amazon Web Services. Curtis is an advocate of empathic and effective code reviews, and is passionate about helping developers and organizations level up in that space.
What would you like to ask him? Post your questions in the comments.
👉 Save your spot for the live talk here
Oldest comments (10)
Oooo cool! This sounds like an interesting interview.
Maybe ask him for tips on how to respond to someone who has given you a particularly unhelpful, harsh code review. I'm curious if there's an empathetic way to respond someone who gives ya this kind of review.
Good question.
Ideally, code review feedback shouldn't ever be unhelpful, or harsh. If the person is being mean or abusive, it's important to know when to talk to somebody about it.
That being said, reviews that come across as unhelpful and harsh are all too common. Unfortunately many code reviewers aren't trained in the art of empathic feedback. I'll continue, giving the reviewer a benefit of the doubt — that their written communication is coming across as more harsh than they intend.
First, it's important to see code review feedback as an opportunity. Your peers have unique experiences and perspectives. Any time you receive feedback, you should seek to leverage these perspectives to improve your own abilities.
In order to do this, you must first understand (1) what they're saying, and more importantly (2) why they're saying it.
Given a harsh review, it helps to read their code review comments in monotone — imagine they're speaking to you verbally in a steady voice and calm demeanor. This suppresses instincts to get defensive, and allows you to assess their feedback objectively.
Once you get to what they're saying objectively, the next step is to figure out why they're saying it. When a code review comment is "unhelpful" most of the time this means that the reason why behind the comment is ambiguous. Sometimes it's possible to put yourself in their shoes — "Why caused this person say that?" Other times it's necessary to seek clarification. For example, you could comment: I'd like to understand the reasoning behind this a comment a bit more, could you please clarify?
Once you have this clarity on the what and the why, you can make a decision on how to go about addressing the comment.
And in the meantime, maybe show them this video on how to comment with more empathy (a shameless plug from my video course).
What a thorough and awesome (thoroughly awesome, haha) response — thank you! 🙌
I really appreciate your advice around reading the comment in a calm manner to focus on the concrete advice versus how it's being delivered. You're absolutely right that it's an opportunity to get someone else's perspective and improve your code; ultimately that's what it's all about, and that can and should still happen even if there happens to be a personality clash.
I also appreciate your guidance around being sure to understand why what's being said is being said. In order to improve, I definitely want to know the context of why, otherwise I'm likely to keep repeating the same mistakes. Good advice to follow up and ask the reviewer why if ya don't understand their reasons.
And haha, shameless plug accepted, thanks for sharing!
Thank you for your question! I'm really looking forward to the live talk for more knowledge sharing like this with @curtiseinsmann 💪. Hope to see you there (link in the post).
Thanks a bunch! I will certainly consider it.
How we should deal with code reviews when the reviewers are in completely different time zone and the comments they give aren't completely clear? I often end up replying like "this is what I think you meant and took this route..." But code reviews end up taking more than a couple of days to get them done...
Every software engineering team should have a documented set of team-level code review guidelines. These guidelines should set expectations for authors and reviewers.
The documented guidelines for reviewers should include how to comment, among other things. For example:
Generally, I wouldn't recommend addressing a code review comment until you're clear on what the ask is. You'll end up wasting a lot of time if you make the wrong assumption. If the comment isn't clear, get clarity by asking first. It sounds like you're working asynchronously — so it's probable that you could work on another task while waiting for a response.
Thanks...I will adopt this as my default approach...
Another one: in your experience, how have you dealt with stubborn reviewees? Often, I see replies like "I don't agree. I won't do it", when the comment suggests an improvement.
Usually this is due to a lack of a compelling argument coming from a reviewer. A reviewer should always include a reason why, and that reason should be compelling enough, such that the code review author will take it in stride. Perhaps the author has a stronger reason why for their original approach. If so, a healthy debate is encouraged.