Stack Overflow: Developers Have to Work Too Much

Every year, Stack Overflow’s developer survey includes questions about work hours, satisfaction, and workload. Every year, the numbers tell the same story: developers are working too much. Not in the dramatic, Silicon Valley “sleeping under the desk” sense — in the quiet, grinding sense of consistently having more work than time, more responsibilities than capacity, and more deadlines than breathing room.

The Data

The survey consistently shows that a significant majority of developers report working more than 40 hours per week. Not occasionally — regularly. The extra hours are not overtime in the traditional sense (compensated, temporary, agreed upon). They are the baseline expectation: the sprint is planned for 40 hours of work, but the meetings, code reviews, on-call duties, and context-switching overhead consume 10-15 hours, leaving 25-30 hours for the “planned” work. The difference is made up in evenings and weekends.

Why the Workload Keeps Growing

Scope creep normalized. Features get added mid-sprint. Requirements change after implementation starts. “Can you also add…” becomes the most dreaded phrase in a developer’s vocabulary. Each addition is small in isolation. Collectively, they add 30% to every project.

Fewer people, same expectations. Layoffs and hiring freezes reduce team sizes, but the roadmap does not shrink proportionally. The remaining developers absorb the work of departed colleagues while maintaining the same delivery timeline.

Operational overhead increases. As systems grow more complex, the operational burden — monitoring, incident response, security patches, dependency updates, infrastructure maintenance — grows with them. This work is invisible in sprint planning but very real in the developer’s week.

Meetings multiply. Standups, sprint planning, retrospectives, design reviews, architecture reviews, cross-team syncs, all-hands, one-on-ones. Each meeting is individually justified. Collectively, they fragment the day into blocks too small for deep work.

The Consequences

Overworked developers write worse code. This is not a character judgment — it is a cognitive reality. Fatigue impairs the working memory and abstract reasoning that programming requires. Bugs increase. Shortcuts multiply. Technical debt accumulates. The overwork creates problems that create more work.

The personal consequences are equally clear: burnout, health issues, relationship strain, and eventual turnover. When a developer leaves because they were consistently overworked, the team loses institutional knowledge, the remaining members absorb more load, and the cycle accelerates.

What Would Actually Help

Honest capacity planning: plan sprints at 70% of theoretical capacity to account for interruptions, maintenance, and the unexpected. Protect focus time: designate meeting-free blocks and enforce them. Staff adequately: if the roadmap requires more hours than the team has, either hire or cut scope. Track operational burden: include maintenance, on-call, and support work in sprint capacity calculations.

None of this is complicated. All of it is uncommon. The industry continues to treat overwork as a badge of honor rather than a failure of management.