Comment by StopHammoTime | Hacker News Reader

Comment by StopHammoTime | Hacker News Reader

Parent Full thread

If you’re a team of 6, and 66% of you can go into a room and without prompting, why can’t you just dial in the people who are working remote (if they’re available). If they’re constantly not available, maybe there are other reasons they can’t come that should be followed up on. I just don’t believe that most of your team is not busy and then all of the remote workers are never available at the same time. Working remotely is a culture. It is very easy to turn your ad-hoc in-person meetings into ad-hoc “here’s a link to an online meeting”. Get your work to buy you an iPad Pro and an Apple Pen and you even get the whiteboard experience. I have worked in many places where teams are located in different states or offices (but still work in the office). Is it okay to not engage a 1/3 of your team because they work at a different office? 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?

because 9 out of 10 times I'd ping someone saying "Hey X, got a minute we want to discuss Y and Z" then I'd get a response 40 minutes later of "sorry I was focusing on W. What's up? How can I help?". Then I look around and 2 of the 4 people are not at their desks anymore and it's all just a shitshow.

If I need the 6 of us to be on anything I need to send a meeting invite for a specific time to eliminate that type of bullshit. Then deal with all the bullshit that entails

So let me break something down for you real quick. Higher up you say the following:

> You do far more pointless meeting and verbal communication when everyone is working remotely anyway.

In this situation, you ping someone and are upset that they're focusing on work. You are angry that you didn't interrupt someone in the middle of deep focus to do what someone else might consider a pointless meeting.

The last statement proves my point. You don't actually seem to consider the employees time or work to be important, but rather that you need the six of them NOW, no matter what they're doing. You're exactly the problem you describe. What you describe as avoiding red tape to me sounds controlling and nightmarish.

Even in an office environment if people want to do quick talks, white board stuff etc I vastly prefer setting up quick meetings or something ahead of time so that I don't constantly get interrupted by some jackasses fighting for my attention when I got a problem to solve.

It's a lot easier to look around, see that 1 out of 6 has headphones on, think "they must be busy", let's wait for them to put their headphones down or the next major office interruption or to pull people first thing in the morning next day when we're all are getting in vs everything you've mentioned.

You can do the same thing in a remote environment. Schedule a meeting in the morning of the next day as people are logging onto work. Or schedule stuff for after lunch before people get back into focus mode. All of this stuff can be done with proper scheduling rather than just grabbing people as they go and assuming that it's not interrupting their work.

of course. The whole point of OP and that I was responding to is that an organization needs to make a decision. Are you a 100% remote organization or are you a predominately in-office with occasional WFH type allowance. WFH isn't a new thing. Long before the pandemic we had plenty of people who would WFH every Friday or when they had a contractor or a delivery they needed to be home for. Or when they had one part of the project they wanted extra focus on.

An organization should have the balls to say "fuck it, we're 100% remote work" then let employees figure out how that would work for everyone and hoe to organize their meetings and work schedule for everyone. Or they should equally have the same amount of balls to say "we're 100% work from office with the occasional exceptions like we did before and you should figure it out".

I've been wanting a commitment to one of the approaches from management for a long time. I'd also like some form of commitment from other companies when I'm applying for jobs. I have no interest in working in a "hybrid" team. You're either 100% remote or you're not. Just tell me which you are and let me pick.

How on earth do you know when a remote worker takes lunch?

If you're going to wait for me to take my headphones off in an open office, your going to wait till I'm heading out. Your better off sending a meeting invite, I'll make sure I'm available.

What's funny is your solution "or to pull people first thing in the morning next day when we're all are getting in" should be a meeting invite rather than a morning ambush.

> If you're going to wait for me to take my headphones off in an open office, your going to wait till I'm heading out.

That’s fine. I’ll catch you next morning or when you’re grabbing a soda or water or …

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.

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

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.

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.

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

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

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.

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

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

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.

If it took you a day to write a branch, do you really want to sit quietly watching me read and think for an hour? Anyway, everything I can’t understand without asking you needs to get written down for the on-call eng next year.

> If it took you a day to write a branch, do you really want to sit quietly watching me read and think for an hour?

Yes, absolutely, if that hour is going to be productive and collaborative in coming up with ways to make the code better (which every in-person code review I've been in has been)

> everything I can’t understand without asking you needs to get written down for the on-call eng next year

No, everything that you can't understand without asking me should be fixed by both of us so that it can be understood by everybody. Approving hard to understand code just because it's been "documented" hurts the entire codebase.

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

Correct, yes. Your current problem is at a state of being done, beyond any code review feedback you may receive. Expecting people to immediately cancel everything they're doing and review your code is not only absurd but also leads to poor quality code reviews. Because rather than actually think about the code and spend time on it, you want them to approve it as fast as possible so you are unblocked as soon as possible.

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

The reviewer has to context switch and juggle multiple tasks. They have to understand what your code does, why it does it and why it was necessary in the first place. They have to open the ticket, read what it's about, read any conversations and then figure out any potential concerns.

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

If you have one person review your code then I question that your code review process even matters. For extensive reworks, redesigns etc you are going to pull in more individuals and there is going to be more time taken.

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

They take far more time in my experience. I've had review turnaround be a few hours to a day in an async context for major reviews. They review the code, we hop on a call when convenient and go over the issues in 15m and we're done. If it's nothing major or understandable over text, then comments are good enough.

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

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.

Reply on news.ycombinator.com