News for hackers. Stuff that matters.
Re:Code reviews aren’t just for catching bugs by geophile on Thursday May 12, 2016 @05:23PM (#11686881)
What? And keep the other developer waiting?
Re:Code reviews aren’t just for catching bugs by phasmantistes on Thursday May 12, 2016 @10:36PM (#11688264)
Code reviews should be asynchronous. Everyone on your team should be able to be working on multiple small changes/commits/whatever in parallel. While one is out for review, they're working on the others. Different people keep different schedules: I do all my reviews first thing in the morning, to settle in, and then often do another round after lunch. Other people do them at the end of the day, or don't mind the interruptions (e.g. follow a pomodoro schedule anyway) and do them as they come in.
Re:Code reviews aren’t just for catching bugs by koja86 on Friday May 13, 2016 @07:07AM (#11689686)
Context switching also creates some overhead. YMMV as the time it takes to switch tasks IMHO depends on particular person, context scale and problem difficulty.
Re:Code reviews aren’t just for catching bugs by devishard on Saturday May 14, 2016 @04:29PM (#11697899)
This has nothing to do with code review. If you're finished with a task, you're going to have to switch contexts; you can't just keep working on something that's done.
Re:Code reviews aren’t just for catching bugs by koja86 on Wednesday May 18, 2016 @11:51AM (#11722786)
It was related to "Everyone on your team should be able to be working on multiple small changes/commits/whatever in parallel."
Re:Code reviews aren’t just for catching bugs by devishard on Saturday May 14, 2016 @04:26PM (#11697891)
Waiting to do what? Why can't they just go off and do something else?