There is a doomscrolling trap that shows up after you open a pull request.
The work is not done, but it is also not fully in your hands anymore. You push the branch, write the PR description, request review, and suddenly there is a weird empty pocket of time.
That pocket is dangerous.
You tell yourself you are just waiting for CI or checking whether someone reviewed it yet. Then one notification becomes TikTok, Reels, YouTube Shorts, Reddit, Hacker News, or whatever feed is closest.
The problem is not that you lacked motivation. The problem is that the waiting period had no boundary.
The PR waiting rule
After opening a pull request, block your highest-risk apps for the next 20 minutes.
Not for the whole day. Not as a dramatic detox. Just for the first 20 minutes after you hand work off.
Use that time for one of these instead:
- reread the PR description like a reviewer
- add the missing test note
- write the rollout or rollback note
- clean up the commit message
- review one small PR from someone else
- start the next tiny task before the phone becomes the task
This works because the worst scroll often happens during the handoff, not during deep work.
Why Screen Time is weak here
Apple Screen Time can tell you later that you spent 42 minutes in social apps.
That is useful information, but it arrives after the feed already ate the gap.
The PR waiting scroll starts earlier than that. It starts when you are mentally done, slightly anxious, and looking for a tiny hit of progress. A soft limit is easy to ignore because part of you thinks you earned the break.
A better Screen Time alternative should protect the first opening attempt, especially during the transitions where you already know you are vulnerable.
What an iPhone app blocker should handle
For this loop, I think an iPhone app blocker needs four things:
- App and website blocking, because the browser fallback matters
- Open limits, because repeated tiny checks are the pattern
- Strict modes, because the first override is usually the failure point
- Blocked-attempt logs, because the attempts show when the habit actually appears
The website fallback is important. If the app is blocked but the mobile site is open, the habit just changes doors.
Open limits help when you genuinely need one quick check but do not want ten quick checks.
Blocked-attempt logs make the pattern visible. You may find that your worst window is always after opening a PR, after CI starts, after review comments arrive, or after you merge.
A simple setup
Try this for one week:
- Pick the 2 or 3 apps that become your waiting-room scroll
- Add the matching websites too
- Create a 20-minute focus session after opening a PR
- Use a strict mode if you normally override your own limits
- Review blocked attempts at the end of the day
The goal is not to remove every break.
The goal is to stop a useful break from turning into an automatic feed loop before you notice it happened.
Why I am building Monk Mode this way
I am building Monk Mode around the belief that distraction is not a motivation problem, it is an enforcement problem.
Monk Mode is an iPhone app blocker for people who keep losing time to automatic opens, social feeds, TikTok/Reels/Shorts loops, and backup websites. It supports hard app and website blocking, open limits, schedules, strict modes, challenge alarms, focus sessions, recovery analytics, and blocked-attempt logs.
If Screen Time keeps explaining the damage after the fact, and you want something stricter at the moment of the first tap, Monk Mode is here:
https://www.monk-mode.lifestyle/index.html#pricing
The practical test is simple: after the next PR handoff, can your blocker protect the waiting window before the feed opens?
Top comments (0)