DEV Community


Discussion on: Tell me an unpopular software opinion

loujaybee profile image
Lou — Cloud Engineer • Edited

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! 😂

Thread Thread
daniel13rady profile image
Daniel Brady • Edited

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.

Thread Thread
nickdrouin profile image
Nick Drouin

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.