Re-thinking developer experience β’ Product @Gitpod π Helping folks get their start in cloud β’ @openupthecloud βοΈΒ AWS Community Builder π Replies in GIFS π
Code Review is a terrible reactive concept that is overly relied on by teams and used as a crutch for bad communication. Pair Programming is significantly more effective at spreading ideas, communication and critiquing code.
Howβs it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK π¬π§
Education
10 plus years* active enterprise development experience and a Fine art degree π¨
I agree. I always found it daunting looking at a PR with 40+ files changed without even knowing what the PR should be doing. In the end, it always seemed to just end up being more efficient sitting down with the owner of the PR and them walking through what changed and reviewing it with them.
Oh and also actually getting the person to RUN the code to see it actually is doing what they expect it to do rather than assuming its working correctly.
Code review should include reviewing the history, it is such an important log, those in person conversations need written down for the poor maintenance folks when both of you aren't available.
I agree with your thought on pair programming, but I haven't experienced your view on code reviews. Are you saying that pairing can be a viable substitute for retroactive review?
Unfortunately pairing doesn't happen much in my current environment, and I don't do much to encourage it. In its absence, I think code reviews are better than nothing, but reviewing code effectively is just as challenging as delivering constructive feedback (because that's exactly what it is) and there aren't nearly as many devs who are good at this as there ought to be.
Re-thinking developer experience β’ Product @Gitpod π Helping folks get their start in cloud β’ @openupthecloud βοΈΒ AWS Community Builder π Replies in GIFS π
I find that often by the time code is up for review it's "too late" to make important changes. As you're wrestling with factors like the sunk cost fallacy and the de-motivating effects of suggesting that a colleague re-do their work seemingly to appease you.
Not only is it often "too late" to make changes but sometimes it's also hard to convey larger feedback via text. Complex changes are often only realistically conveyed in person going through piece by piece. Naturally over time though the amount of "explaining" is asymptotic as you get more and more inline with each others viewpoints.
My take is not that code review is bad (it's important to stress this point) it's just that I see code review is used as a crutch for not having adequate conversations prior and during the creation of code (since it's reactive in nature). And pair programming in my opinion is superior at type of communication.
However I know that my opinion is unpopular since I'd say the majority of developers I've worked with would admit that they dislike pair programming, which seems to tally your experience too so until the day comes that the industry invites more pairing I'll be over here shouting into the void! π
Honestly I quite enjoy pairing, but I've recently found myself in a remote work position that is also separated by about 8hrs from my teammates, which makes any sort of synchronous communication difficult. I've been experimenting with opening up a PR as soon as I make a first commit to a branch, and tagging my teammates with the hopes of exchanging feedback "early and often." I've met with mixed success, depending on how available my teammates are.
For large stories, I try to push my team's / teammates to use a two-phased PR: one for the interfaces/design, a second for the code.
This promotes discussion on the approach early on.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Code Review is a terrible reactive concept that is overly relied on by teams and used as a crutch for bad communication. Pair Programming is significantly more effective at spreading ideas, communication and critiquing code.
God yes!
I agree. I always found it daunting looking at a PR with 40+ files changed without even knowing what the PR should be doing. In the end, it always seemed to just end up being more efficient sitting down with the owner of the PR and them walking through what changed and reviewing it with them.
Oh and also actually getting the person to RUN the code to see it actually is doing what they expect it to do rather than assuming its working correctly.
Plug
Git is a Communication tool
Jesse Phillips γ» Dec 12 '18 γ» 2 min read
Or a little more specific
Partnered Code Reviews
Jesse Phillips γ» Feb 13 '19 γ» 1 min read
Code review should include reviewing the history, it is such an important log, those in person conversations need written down for the poor maintenance folks when both of you aren't available.
Do you even CI, bro? :D
I'd consider looking into Continuous Integration. Smaller commits are oftentimes safer commits.
I agree with your thought on pair programming, but I haven't experienced your view on code reviews. Are you saying that pairing can be a viable substitute for retroactive review?
Unfortunately pairing doesn't happen much in my current environment, and I don't do much to encourage it. In its absence, I think code reviews are better than nothing, but reviewing code effectively is just as challenging as delivering constructive feedback (because that's exactly what it is) and there aren't nearly as many devs who are good at this as there ought to be.
Hey Daniel! :)
I find that often by the time code is up for review it's "too late" to make important changes. As you're wrestling with factors like the sunk cost fallacy and the de-motivating effects of suggesting that a colleague re-do their work seemingly to appease you.
Not only is it often "too late" to make changes but sometimes it's also hard to convey larger feedback via text. Complex changes are often only realistically conveyed in person going through piece by piece. Naturally over time though the amount of "explaining" is asymptotic as you get more and more inline with each others viewpoints.
My take is not that code review is bad (it's important to stress this point) it's just that I see code review is used as a crutch for not having adequate conversations prior and during the creation of code (since it's reactive in nature). And pair programming in my opinion is superior at type of communication.
However I know that my opinion is unpopular since I'd say the majority of developers I've worked with would admit that they dislike pair programming, which seems to tally your experience too so until the day comes that the industry invites more pairing I'll be over here shouting into the void! π
Thanks for elaborating!
Honestly I quite enjoy pairing, but I've recently found myself in a remote work position that is also separated by about 8hrs from my teammates, which makes any sort of synchronous communication difficult. I've been experimenting with opening up a PR as soon as I make a first commit to a branch, and tagging my teammates with the hopes of exchanging feedback "early and often." I've met with mixed success, depending on how available my teammates are.
For large stories, I try to push my team's / teammates to use a two-phased PR: one for the interfaces/design, a second for the code.
This promotes discussion on the approach early on.