Read on Twitter
What are your thoughts on code reviews?
I feel like they can either be extremely valuable or a huge hinderance and rarely in the middle
I feel like they can either be extremely valuable or a huge hinderance and rarely in the middle
Feel like written code reviews are not the best way to teach people. Much better to jump on a call and walk through the code like that, pointing out things as you go
Theyâre not the best way to catch bugs. Tests are better for that, or deploying straight to staging or production if you can tolerate it
Not the best for design either, unless youâre reviewing really early stage prototype code (which Iâm trying to do more of but doesnât seem too common). And again, I think design discussions are often best done through a mix of writing and face to face conversations
Not the best for small formatting and stylistic things. Use a code formatted and a linter for that. Especially important the bigger your team is. Smaller teams would probably settle on conventions naturally
By far the worst thing about required code reviews before merging is that itâs very hard to avoid accruing piles of work-in-progress and delays across the board... and delays are among the top killers of productivity in software
/rant
In all seriousness, Iâve seen people write about alternatives. Probably time for me to start seriously exploring them
In all seriousness, Iâve seen people write about alternatives. Probably time for me to start seriously exploring them
Iâve been encouraging more pair and group programming lately, and more demos in small groups. Both have been incredibly valuable and refreshing
Itâs also an excellent learning exercise for juniors to have them guide someone else through demoing their own functionality
It gives a real appreciation for all of the annoying little things that otherwise seem pointless (git, dependency mgmt, docker, simple docs)
It gives a real appreciation for all of the annoying little things that otherwise seem pointless (git, dependency mgmt, docker, simple docs)
Demos also make it painfully obvious when the UX is not the greatest, and sometimes even when the implementation/design is too complex
After reading through the discussions in the thread, I realise my issue is actually with *delayed code review* (as in PRs). It's not just about batch size, it's also about bringing review earlier in the cycle, whether that be pair programming or other written forms
On pairing, here are really great and particularly nuanced points on what it takes to make it work. As much as we might not like it, collaboration can be tricky, but it also unlocks unrivalled potential https://twitter.com/ashtonshudson/status/1351504954054365185?s=20
