4 ms·

It's just the reality of how scheduling time works remotely vs in-person. In-person you have immediate and implicit knowledge of who's available / what everybod

It's just the reality of how scheduling time works remotely vs in-person. In-person you have immediate and implicit knowledge of who's available / what everybody's schedules are, etc, so by using that knowledge you can seem to "magically" pick times that everybody is available. Remotely, you have a much larger coordination overhead because there's no passive knowledge of who is or isn't available, and people's schedules aren't synced up. > What if you’re the app team and your network has issues, but the network team is in another building? Do you just not dial them? I don't know, but I would honestly absolutely hate to work at a company like this just as much as I dislike working remotely. When you're already dealing with the large barriers / restrictions that naturally grow up between different teams and then you add in the mix of not being in the same physical location, it's bound to be a recipe for never-ending meetings and scheduling nightmares that make it impossible for work to get done without mountains of ritual.

stormking 3y ago
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
  - 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.

stormking 3y ago

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
- 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.