5 ms·

In reality you're just disrupting everyones work and bully them into putting your problem first.

nightpool 3y ago
No. In reality, I'm more able to find times that work for other people where I'm not disrupting them, by using context clues and non-verbal information to determine what the best time to talk to them is. And yes, sometimes it is important to let other people interrupt you. For example, if someone else needs their code reviewed, they should absolutely always interrupt me to get it reviewed. Unless I'm in an interview with a candidate or something similarly external, unblocking other engineers on my team is always a higher priority and return on investment than anything I could be working on alone.
- fzeroracer 3y ago
  If code reviews are absolute blockers on your team then your team is dysfunctional. There are a few rare scenarios where code reviews are higher priority (high chance of merge conflicts, hotfixes) but code reviews themselves should be asynchronous. But that situation should be rare and clearly signalled as higher priority.
  - nightpool 3y ago
    > If code reviews are absolute blockers on your team then your team is dysfunctional So what am I supposed to work on when I'm waiting for my code to be reviewed? Am I supposed to context-switch over to another task, losing all of my current built-up state about the current problem and making it take twice as long just because you think your task is more important? Async reviews slow the whole team down, because juggling more tasks in your head means that you can't retain the high-context information about all of them as easily and you lose a lot of time to context-switching. In the synchronous review model, only one team member has to do a context switch (and a much lighter one than a full context switch to work on another task). In addition, synchronous reviews over a voice/video chat just take significantly less time in general, because being able to ask "Why did you do it this way?" and have an immediate discussion about the trade-offs is strictly superior to having to have that same discussion back and forth over days of async responses.
    - jenscow 3y ago
      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.
- stormking 3y ago
  Sure, the same people that absolutely cannot get their remote coworkers into a group chat for five minutes or have an ad-hoc Zoom call without scheduling a meeting, resolving schedule conflicts and sending out an agenda, are suddenly able to pick up "clues".
eddythompson80 3y ago
That depends on the person. If your coworker is someone who requires pre-planed meetings for any type of interruption, you'd know. Oh boy would you know very quickly. I usually only feel bad for the cleaning or mail staff, but you and I would immediately know those people. Otherwise, most other people are either available, or will tell you when they are not and you can easily say back "no worries, ping all of us when you're done" and everything moves 100% more efficiently.

No. In reality, I'm more able to find times that work for other people where I'm not disrupting them, by using context clues and non-verbal information to determine what the best time to talk to them is. And yes, sometimes it is important to let other people interrupt you. For example, if someone else needs their code reviewed, they should absolutely always interrupt me to get it reviewed. Unless I'm in an interview with a candidate or something similarly external, unblocking other engineers on my team is always a higher priority and return on investment than anything I could be working on alone.

fzeroracer 3y ago
If code reviews are absolute blockers on your team then your team is dysfunctional. There are a few rare scenarios where code reviews are higher priority (high chance of merge conflicts, hotfixes) but code reviews themselves should be asynchronous. But that situation should be rare and clearly signalled as higher priority.
- nightpool 3y ago
  > If code reviews are absolute blockers on your team then your team is dysfunctional So what am I supposed to work on when I'm waiting for my code to be reviewed? Am I supposed to context-switch over to another task, losing all of my current built-up state about the current problem and making it take twice as long just because you think your task is more important? Async reviews slow the whole team down, because juggling more tasks in your head means that you can't retain the high-context information about all of them as easily and you lose a lot of time to context-switching. In the synchronous review model, only one team member has to do a context switch (and a much lighter one than a full context switch to work on another task). In addition, synchronous reviews over a voice/video chat just take significantly less time in general, because being able to ask "Why did you do it this way?" and have an immediate discussion about the trade-offs is strictly superior to having to have that same discussion back and forth over days of async responses.
  - jenscow 3y ago
    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.
stormking 3y ago
Sure, the same people that absolutely cannot get their remote coworkers into a group chat for five minutes or have an ad-hoc Zoom call without scheduling a meeting, resolving schedule conflicts and sending out an agenda, are suddenly able to pick up "clues".

eddythompson80 3y ago

That depends on the person. If your coworker is someone who requires pre-planed meetings for any type of interruption, you'd know. Oh boy would you know very quickly. I usually only feel bad for the cleaning or mail staff, but you and I would immediately know those people. Otherwise, most other people are either available, or will tell you when they are not and you can easily say back "no worries, ping all of us when you're done" and everything moves 100% more efficiently.