There is a specific doomscrolling loop that starts after you send a pull request for review.
You did the hard part. You pushed the branch, wrote the description, requested review, and now there is nothing useful to do for a few minutes.
That empty space is dangerous.
It is where the phone unlock happens. Then one feed opens. Then another. Then the review comes back and you are no longer in the same mental state you were in when you shipped the change.
That is not always a motivation problem. Most of the time, it is an enforcement problem.
The code-review wait rule
Here is the app blocker for iPhone rule I like for this moment:
- Trigger it right after requesting review on a PR.
- Block the apps and sites you normally check while waiting.
- Include the browser fallback, not just the native apps.
- Set the window to 25 to 45 minutes.
- Use an open limit of 0 or 1 for short-video and social feeds.
- Turn on strict mode if you know you will negotiate with yourself.
- Leave work tools, messages, email, docs, and calendars alone if you need them.
The point is not to block your whole phone forever. The point is to protect one predictable weak spot.
Why Screen Time usually fails here
Apple Screen Time is useful as a baseline, but it is too easy to bargain with during tiny waits.
A daily limit asks you to make the right decision after the impulse has already started. The better Screen Time alternative for this case is a rule that removes the decision before the feed loads.
That difference matters.
If the PR review wait usually turns into TikTok, Reels, YouTube Shorts, or a social feed, the useful blocker is not a guilt report at 9 PM. It is a hard boundary at 11:14 AM when your thumb reaches for the app.
Block the fallback path too
A lot of app blocker setups fail because they only block the obvious app.
You block one feed, then open the same thing in Safari. Or you block a short-video app, then open a different feed that scratches the same itch.
That is why the rule should include app and website blocking together.
For a code-review wait, I would rather block a small cluster tightly than block everything loosely. The cluster might be:
- short-video feeds
- social feeds
- news feeds
- browser versions of those sites
Everything else can stay available.
Measure blocked attempts, not only time
The most useful signal is not always total screen time.
If your blocker catches 6 attempts in 30 minutes, that tells you something important: the rule was not overkill. It caught the automatic loop you normally would not notice.
That is why blocked-attempt logs and recovery analytics are more useful than a generic productivity score. They show the moments where your system saved you from renegotiating the same decision.
The practical version
Next time you request PR review, try this once:
- Start a 30 minute focus session.
- Block the feeds and their browser versions.
- Keep the tools you need for work unblocked.
- When the review comes back, check the blocked-attempt log.
If there were no attempts, great. The rule was harmless.
If there were several attempts, you found the exact loop that keeps stealing your attention.
I built Monk Mode around this kind of enforcement: app and website blocking, open limits, schedules, strict modes, challenge alarms, focus sessions, blocked-attempt logs, and recovery analytics.
If you want an app blocker for iPhone that acts more like enforcement than a suggestion, Monk Mode is here:
https://apps.apple.com/us/app/monk-mode-block-distractions/id6755029966
Top comments (0)