Hacker News Reader

Comment by zeroonetwothree | Hacker News Reader

I love remote work but when it’s async I find things go a lot slower. Sometimes you need someone to quickly accept your PR and if they just went to bed because of TZ differences your project is delayed a full day.

View on HN

Bur this is not an async problem. It's a TZ problem, right? . OTOH you can avoid being paged in the middle of your sleep id your team has people in far time zones.

For the record, I struggle with timezone differences too. The non-async moments tend to always suck for someone.

This happens with remote teams even in the same timezone. Many people don't work 9-5 and you can get many hours of delay (often effectively a full business day).

You should avoid getting yourself into situations like this. Why is your PR blocking anything if it's pending for one day? It's not just communication which needs to be async but the work itself should be too. Nobody should be stuck waiting for that PR - they should do some other work while they wait. I've been working for nearly ten years with a team that is split across four continents and everything is smooth. It needs cooperation and understanding from everyone to work well.

That's not a problem, it's a feature, and the article states that.

Sometimes it may feel like you're blocked or stuck and can't progress as quickly, but the benefit of having every single decision in written form and most of the complexity thoroughly documented greatly outweighs that.

I've been working as the sole person in my timezone (GMT-3) for sometime while my whole team is on CET. That was only made possible because everytime I get stuck, I'll search the company knowledge base and/or Slack and have consistently been able to find the information I needed to progress. This benefits my use case, but also saves invaluable time during incidents, avoids redundancy, duplication, contributes to continuous improvement and shields the product against knowledge turnover.

That's a relatively low price to pay for waiting a day for a code review every now and then.

This is my experience as well, but it only works if there are fluid or no deadlines. As long as things progressively move every 24 business hours my product owners don’t seem too worried about the time spent waiting for another person.

On the flipside, it gives the other person hours instead of minutes to look at it before you get online the next morning, so they have time to actually think about it instead of just skim it and go "yeah, that's probably fine".

Ideally, someone accepting your PR shouldn't gate working on the next one. I would be more interesting in figuring out what process issue means you can't start work on the next item than in making everyone respond to PRs in real time.

No, but I've seen folks get laid off as a result of this. Granted they were in a PIP but they'd met the conditions established within with exception for accepted PRs, y'know points. So when their PR wasn't approved before standup the following day (end of sprint) they were let go that afternoon despite having done their work to the satisfaction of the PIP such as they could.

That's not an issue with remote work / TZ differences. That's an issue with stupid management. If the review was solved, they'd find some other system to abuse.

> Sometimes you need someone to quickly accept your PR and if they just went to bed because of TZ differences your project is delayed a full day.

Sounds to me like you missed your deadline. How is that situation different than not being able to finish your work until your colleagues in the same time zone go to bed?

Reply on news.ycombinator.com