If you write code for a living, you've heard "take regular breaks" a hundred times. It's easy to agree with and easy to ignore, mostly because the reminder tends to show up at the worst moment: halfway through a stack trace, with six things held in your head.

I wanted answers to two questions. What does the research actually say about short breaks from computer work, and how strong is that evidence? And can a reminder arrive at a moment when stopping costs almost nothing? This post covers both. It ends with a small shell script and git hook that nudges you after a commit once you've gone too long without a break.

What the studies found

NIOSH's data-entry field studies

The most practical work I found comes from NIOSH, the US National Institute for Occupational Safety and Health, which ran NIOSH-IRS field studies with data-entry workers.

In the first study (Galinsky et al., 2000, Ergonomics), workers alternated between two break schedules in 4-week blocks. The conventional schedule had two 15-minute breaks per shift. The supplementary schedule kept those and added a 5-minute break in each hour that didn't already have one, for 20 extra minutes of break time a day. With data from 42 workers, discomfort in several areas of the body, and eyestrain, were significantly lower on the supplementary schedule. On the conventional schedule, discomfort in the right forearm, wrist and hand rose over the work week. On the supplementary schedule, that rise was eliminated. In the authors' words, these benefits came "without reductions in data-entry performance."

A follow-up study (Galinsky et al., 2007, American Journal of Industrial Medicine) used the same two schedules with 51 workers. Discomfort and eyestrain were again significantly lower with supplementary breaks. Data-entry speed was significantly faster with the extra breaks, so work output was maintained even though 20 minutes of work time had been replaced with break time.

That study also tested stretching. Half the workers were randomly assigned to do brief stretches during breaks. They reported stretching during only 25% of conventional breaks and 39% of supplementary breaks, and no significant effect of stretching on discomfort or performance was observed. The authors say low compliance prevented a valid assessment of stretching. So the honest reading is "unknown", not "stretching doesn't work". The break itself was the part with a measurable effect.

Shorter breaks, and whether people take them

Henning et al. (1997, Ergonomics) went shorter. Computer operators at two work sites (73 people and 19 people) were prompted to take three 30-second breaks and one 3-minute break every hour, on top of their normal breaks. Two findings stood out to me:

  • Operators complied with about half of the added breaks, and they favoured the 3-minute breaks over the 30-second ones.
  • At the larger site, there was no improvement in productivity or well-being. At the smaller site, productivity and eye, leg and foot comfort all improved when the short breaks included stretching exercises.

The authors conclude that frequent short breaks can benefit productivity and well-being "when the breaks integrate with task demands." That phrase shaped the tool below.

The meta-analysis

Albulescu et al. (2022, PLOS ONE) pooled 22 study samples from 19 records (2,335 participants) on micro-breaks, which they define as breaks of 10 minutes or less. Micro-breaks gave small but significant boosts to vigor (d = .36) and reductions in fatigue (d = .35). The overall effect on performance (d = .16) was not statistically significant.

Breaking performance down by task, the effect was significant for creative tasks and for clerical tasks (the clerical result rests on only two studies). For cognitive tasks it was very small and non-significant, and that category is probably the closest match to most programming work. Longer breaks went with bigger performance gains, and the authors suggest that recovering from highly depleting tasks may need more than 10-minute breaks. They also note that no study found significantly decreased performance when a break was introduced.

Realistically, a short break probably won't make you code faster. It's more likely to leave you less tired, without costing output.

How strong is all this?

Not very, and that's worth saying plainly. A 2018 Cochrane review of ergonomic interventions for office workers (Hoe et al.) rated the evidence that supplementary breaks reduce neck, shoulder and forearm/wrist/hand discomfort as very low quality, based on two studies of data-entry workers. In the Albulescu review, most included studies had an unclear risk of bias. Data entry also isn't programming: OSHA notes that a proficient typist "can easily perform more than 18,000 keystrokes per hour," and most developers don't type nonstop.

Still, the cost is a few minutes an hour, the field studies didn't find a productivity penalty, and OSHA's computer workstation guidance says much the same thing in practical terms: "Every hour, take a five-minute break from computer tasks. Look away, stretch, get up, or walk."

What I took from it

  1. Roughly hourly, a few minutes long. That's what the NIOSH studies tested and what OSHA recommends.
  2. Compliance is the real problem. In both Henning and Galinsky 2007, people skipped much of what they were asked to do. A reminder you ignore does nothing.
  3. Timing matters. Henning's point about integrating with task demands matches my experience. A break that interrupts a hard thought feels expensive. A break right after finishing something feels free.
  4. Make the break a real change. OSHA suggests standing, stretching and moving around. For your eyes, the American Academy of Ophthalmology (AAO) notes that we normally blink about 15 times a minute but only 5 to 7 times a minute at a screen, and suggests looking up and away at a distant object. There's a separate write-up on the 20-20-20 rule if you want the eye side in more detail.

A commit is a natural pause. You've finished a unit of work, and whatever was in your head has just been written down. So that's where the reminder should go.

The tool: a post-commit nudge

Git runs a post-commit hook after a commit is made. The git docs say this hook "is meant primarily for notification, and cannot affect the outcome of git commit," so it can't block or break your commits.

The script keeps a single timestamp: when you last took a break. After each commit it checks how long it's been. If it's been 50 minutes or more, it prints a reminder and, where possible, shows a desktop notification. When you come back, git break resets the timer. It's plain POSIX sh with no dependencies.

Save this as ~/.local/bin/microbreak (or anywhere on your PATH):

#!/bin/sh # microbreak: nudge me to take a short break at a natural stopping point. # Usage: microbreak [check|done|status] state="${XDG_STATE_HOME:-$HOME/.local/state}/microbreak" limit="${MICROBREAK_MINUTES:-50}" now=$(date +%s) mkdir -p "$(dirname "$state")" [ -s "$state" ] || echo "$now" > "$state" last=$(cat "$state") mins=$(( (now - last) / 60 )) case "${1:-check}" in done) echo "$now" > "$state" echo "microbreak: timer reset" ;; status) echo "microbreak: ${mins} min since your last break" ;; check) [ "$mins" -ge "$limit" ] || exit 0 msg="${mins} min since your last break. Stand up, look at something far away, move for a few minutes. Then run: git break" printf '\n >> %s\n\n' "$msg" >&2 if command -v notify-send >/dev/null 2>&1; then notify-send "Microbreak" "$msg" elif command -v osascript >/dev/null 2>&1; then osascript -e "display notification \"$msg\" with title \"Microbreak\"" fi ;; *) echo "usage: microbreak [check|done|status]" >&2 exit 2 ;; esac exit 0

Make it executable and add a git alias for resetting the timer:

chmod +x ~/.local/bin/microbreak git config --global alias.break '!microbreak done'

A git alias that starts with ! is run as a shell command, so git break just calls microbreak done.

Hook it into one repo 

printf '#!/bin/sh\nmicrobreak check\n' > .git/hooks/post-commit chmod +x .git/hooks/post-commit

Git ignores hooks that don't have the executable bit set, so don't skip the chmod. If the repo already has a post-commit hook, add the microbreak check line to it instead of overwriting it.

Or hook it into every repo 

mkdir -p ~/.config/git/hooks printf '#!/bin/sh\nmicrobreak check\n' > ~/.config/git/hooks/post-commit chmod +x ~/.config/git/hooks/post-commit git config --global core.hooksPath ~/.config/git/hooks

Careful: core.hooksPath tells Git to look for hooks in that directory instead of .git/hooks, so any repo-local hooks (from a hook manager, say) will stop running. If your projects rely on repo hooks, stick with the per-repo setup.

What it looks like

After a commit that crosses the limit:

$ git commit -m "Handle empty config" >> 55 min since your last break. Stand up, look at something far away, move for a few minutes. Then run: git break $ git break microbreak: timer reset

microbreak status tells you how long it's been. To change the limit, set MICROBREAK_MINUTES in your shell profile, for example export MICROBREAK_MINUTES=45.

Limitations

  • It only knows what you tell it. It can't tell a lunch break from a long debugging session, so if you step away without running git break, your next commit will nag you.
  • If you go two hours without committing, you won't hear from it. That's on purpose: it's a commit-time nudge, not a clock. If you want a hard timer, an ordinary timer app is the better tool.
  • GUI git clients may not show hook output. The desktop notification (via notify-send on Linux or osascript on macOS) is there to cover that case.
  • 50 minutes is a starting point based on the hourly schedules above, not a number with evidence of its own.

What to do with the few minutes

Stand up, get some water, look out a window, roll your shoulders. For well-being, the Albulescu review concludes that the answer to "what should I do on a break?" "seems to be 'any type of decoupling activity'", meaning anything that takes you away from the work. If your forearms are the part that complains, here are some wrist stretches you can do at your desk. Galinsky 2007 couldn't show that stretching adds anything beyond the break itself, so treat stretches as an option, not a requirement.

When to see a clinician

Breaks are a habit, not a treatment. OSHA lists warning signs that include numbness or a burning sensation in the hand, reduced grip strength, swelling or stiffness in the joints, pain in the wrists, forearms, elbows, neck or back, reduced range of motion, aching or tingling, cramping and weakness, and it stresses reporting signs and symptoms as early as possible. The AAO says that if your eyes are consistently red, blurry or watery, or become sensitive to light or painful, you should see an ophthalmologist. If any of that sounds familiar, talk to a doctor or physiotherapist rather than tuning a git hook.

Sources

This post was drafted with AI assistance and reviewed by the MotionLab team.