Developer Burnout Warning Signs in Your Git Data

TL;DR: Burnout rarely announces itself. It shows up in the work rhythm first: hours spreading into nights and weekends, collaboration quietly shrinking, rework climbing, months before any of it shows up in a resignation letter. Your git history carries these traces. Read them honestly and they're an early-warning system. Read them as a verdict and you've built a surveillance tool that guarantees you'll never see the truth again.

The resignation that "came out of nowhere" almost never did. By the time someone quits from burnout, the pattern has usually been sitting in your commit history for months: the Saturday pushes that used to be rare, the review queue they stopped touching, the half-finished branches from a person who used to finish everything.

Nobody was looking. Or worse, somebody was, and called it dedication.

What burnout actually is (per the WHO, not LinkedIn)

The World Health Organization classifies burn-out as an occupational phenomenon, explicitly not a medical condition, defined as "a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed," with three dimensions:

1. Feelings of energy depletion or exhaustion
2. Increased mental distance from one's job, or feelings of negativism or cynicism
3. Reduced professional efficacy

That classification matters more than it looks. "Occupational phenomenon" places the cause in the workplace rather than in the person's character, and it places the fix in the same building. A manager who treats burnout as an individual resilience failure is treating the smoke and protecting the fire.

Developer burnout warning signs in git data

Each WHO dimension leaves a plausible trace in the work record. Read these as hypotheses that deserve a conversation. Every single one has innocent alternative explanations, and we'll get to those.

Exhaustion: the rhythm loses its off switch. Work hours spreading later into the night. Weekend commits creeping from never to sometimes to standard. The gap between someone's first and last activity of the day stretching to fourteen hours. No single late night means anything - shipping weeks happen. The signal is the trend: a rhythm that had edges and lost them, and a recovery weekend that stopped arriving.

Distance and cynicism: the collaboration shrinks. Someone who used to be all over the review queue goes quiet. PR descriptions shrink from paragraphs to "fix." Design discussions proceed without a voice that used to be central. Withdrawal is mental distance made visible, and it's doubly costly because collaboration is the C in SPACE that knowledge flow depends on.

Reduced efficacy: finishing gets hard. Rising rework and churn, the same files revised again and again. Branches that stall at 80 percent. Longer gaps between starting and shipping from someone whose signature move was landing things. The mechanics here are cruel. An exhausted brain is an interrupted brain, and the Parnin & Rugaber research on 10,000+ programming sessions found only about 10 percent of resumptions get back to editing code within a minute, while roughly 30 percent take over half an hour. Fatigue turns every task into a series of expensive resumptions, which reads in the data as someone getting "slower" - right before it reads as someone leaving.

The overload prequel. Burnout's most common origin story is visible even earlier: work concentrating on one person. The go-to reviewer. The sole owner of the scariest system. That concentration is simultaneously a key-person risk and a burnout forecast. Two problems, one root, one fix: spread the load before it breaks the person carrying it.

The other explanations (read before acting)

Every signal above is honestly ambiguous, and pretending otherwise is how monitoring becomes surveillance:

• After-hours commits may be a night owl's chosen schedule, a parent time-shifting around a school run, or a distributed team's normal timezone spread.
• Withdrawal from reviews may mean someone's heads-down on a hard, legitimate project, possibly at your own request.
• Stalled work and rising rework may be a brutal legacy area, shifting requirements, or dependencies that keep them waiting. A system problem wearing a person costume.

This ambiguity is why the double interpretation is the method, not a disclaimer. The data can tell you a pattern changed. It cannot tell you why, and any tool or manager claiming otherwise is selling diagnosis without a license. The pattern earns a question, asked with care, in private: "I noticed the weekends. How are you actually doing?"

How to respond without surveilling

1. Team-level first, person-level only with care. Watch rhythm and load distribution as system properties in the open. Treat any individual pattern as a private, human conversation. Never a dashboard tile, never a metric in a review.
2. Suspect the workload, not the person. The WHO's definition points at unmanaged workplace stress. So: rebalance the concentrated load, cut work-in-progress, fix the always-waiting queues that stretch every day, and kill the after-hours expectations - starting with your own 11pm Slack messages.
3. Stop rewarding the fire. If the last three promotions went to visible overworkers, your incentives are manufacturing burnout faster than any wellness program can absorb it. Praise outcomes and sustainability, loudly, or the rhythm data will keep telling the same story with new names in it.
4. Make recovery structural. Real off-call rotations, actually-quiet weekends, post-crunch paybacks. A team's health shows in whether its rhythm has edges: protected time the job reliably does not cross.

The kindest thing about work-pattern data is also the most damning: it means "we had no idea" is rarely true. The traces were there. The team that reads them early, and answers with support instead of scores, keeps the engineer, the knowledge, and the trust. The team that reads them as performance data gets to practice writing job postings.