13 ms·

What about the reviewer's "context-switch" to look at your precious code?

nightpool 3y ago
As I said, context-switching and interrupting my work to review code is going to be less of an impact then setting down a task entirely to work on implementing a completely different task. Reviewing already written code just doesn't require as much context as writing the code from scratch, and the other engineer (in theory) has already done the job of putting all the context into the pull request description so you can review it easily.
- jenscow 3y ago
  Then the same applies to you for receiving a review. But anyway, needing everyone into an office because you struggle isn't the fault of WFH
  - nightpool 3y ago
    No, it doesn't. What I'm saying is that context-switching what you're actually coding on to pick up a new task is a more costly endeavor than just context-switching in or out of a review. In the synchronous model, there are only two tasks involved—one per employee. In the asynchronous model, you need to pick up a second task to work on while you're waiting for me to review your code. So you'll need to context-switch fully onto the other task to work on it, and you're probably going to get less work done than if you can devote all of your attention to one task at a time. This isn't about "me struggling", it's about ways the entire team's productivity can be affected by choosing an asynchronous vs synchronous code review model. https://www.atlassian.com/blog/productivity/context-switching#:~:text=2.%20It%E2%80%99s%20easier,to%20crash.%20Exhausting https://www.atlassian.com/blog/productivity/context-switchin...! has some more info on how certain types of context switches can be more damaging than others. I've been working remote for 3 years now with a synchronous code review system, and I wouldn't give it up for the world.
    - jenscow 3y ago
      But to get any real value from a review, the reviewer will need to context switch. Reviewing code together is reasonable, but having to review it as soon as you say "done it" is an interruption.

As I said, context-switching and interrupting my work to review code is going to be less of an impact then setting down a task entirely to work on implementing a completely different task. Reviewing already written code just doesn't require as much context as writing the code from scratch, and the other engineer (in theory) has already done the job of putting all the context into the pull request description so you can review it easily.

jenscow 3y ago
Then the same applies to you for receiving a review. But anyway, needing everyone into an office because you struggle isn't the fault of WFH
- nightpool 3y ago
  No, it doesn't. What I'm saying is that context-switching what you're actually coding on to pick up a new task is a more costly endeavor than just context-switching in or out of a review. In the synchronous model, there are only two tasks involved—one per employee. In the asynchronous model, you need to pick up a second task to work on while you're waiting for me to review your code. So you'll need to context-switch fully onto the other task to work on it, and you're probably going to get less work done than if you can devote all of your attention to one task at a time. This isn't about "me struggling", it's about ways the entire team's productivity can be affected by choosing an asynchronous vs synchronous code review model. https://www.atlassian.com/blog/productivity/context-switching#:~:text=2.%20It%E2%80%99s%20easier,to%20crash.%20Exhausting https://www.atlassian.com/blog/productivity/context-switchin...! has some more info on how certain types of context switches can be more damaging than others. I've been working remote for 3 years now with a synchronous code review system, and I wouldn't give it up for the world.
  - jenscow 3y ago
    But to get any real value from a review, the reviewer will need to context switch. Reviewing code together is reasonable, but having to review it as soon as you say "done it" is an interruption.