One challenge is that there are some things which should distract us:
1. Pull Requests which we should review to unblock our teammates.
2. Production errors which should be investigated.
3. Slack messages from those 1-3 people we are immediately working with and which they'd want to interrupt us with.
4. Fire alarms which are not weekly tests.
5. Messages from spouse which they intend to inturrupt us with.
For me, one big win has come when I was able to put a Zeroable Inbox of PRs-to-review on my menubar. Instead of searching through github, I could just glance.
They shouldn't sit unreviewed for days, sure, but addressing them within a few hours should be sufficient. If your colleague can't get anything done during those few hours, you might not be decomposing work to a small enough granularity, or there could be problems with your application architecture.
> One challenge is that there are some things which should distract us:
> 1. Pull Requests which we should review to unblock our teammates.
For PRs, it's unlikely that the person making the PR needs you to review it right this second. It's ok if you finish what you are working on now while you are still in flow and after an hour or so, review the PR.
If your teammate has nothing to do during that time, that's a completely different problem.
I don't agree, except for the fire alarm of course. Almost nothing is so important that it needs my attention immediately. I will manually check for new notifications about every hour and never got complains for being unresponsive. As a side effect, I stopped ghosting people unintentionally by forgetting to respond later.
I've learned to get any deep focus, I need to eliminate emails and Slack for this time (including things by the closest collaborators, directly on the project, life partners, anyone).
There are exceptions and emergencies (then, and only then - unscheduled phone calls), but only in case when it is worth canceling all daily progress.
I think it is reasonable to expect pull requests to be reviewed within 24 hours but not necessarily sooner. From this it follows that one can pick a convenient time for them every day and for maximum efficiency one should do precisely that.
Re: 1, pull requests should not be blocking; if it is blocking, go for pair programming instead and/or in addition to. If a pull request not being merged blocks someone else then you need to review your planning.
2. Yes, but it should interrupt the whole team. Share the pain, the cause, the solution, and work on how to prevent it in the future.
3. If you're immediately working with them you should be in the same room with them. Or voice comms if you're in a remote situation, but I suspect most people working remote will work quite insulated anyway.
4. Yes.
5. If it's a message it can wait, messages are asynchronous communications. If it's time critical they need to call.
No, it should interrupt the team which owns that area of the codebase. If you're having an issue due to Postgres indexing, what value is there in pulling someone away from writing React.js hooks?
If your answer is "By making it painful, you force the problem to get solved." that is incorrect for the same reason that "If you throw a person into a 10-meter-deep lake, you force them to swim" is incorrect.
One challenge is that there are some things which should distract us:
1. Pull Requests which we should review to unblock our teammates.
2. Production errors which should be investigated.
3. Slack messages from those 1-3 people we are immediately working with and which they'd want to interrupt us with.
4. Fire alarms which are not weekly tests.
5. Messages from spouse which they intend to inturrupt us with.
For me, one big win has come when I was able to put a Zeroable Inbox of PRs-to-review on my menubar. Instead of searching through github, I could just glance.