Why Programmers Really Work Overtime: Broken Software Engineering, Not Code Volume

The article opens with a Zhihu question about why programmers work overtime, then catalogs surface-level complaints: answering cross-team queries, debugging, meetings, writing reports, pre-requirement discussions, platform-mandated upgrades, and alert handling are all excluded from official work-hour accounting, while the only tasks that count are constantly pressured to be compressed.

Several Zhihu respondents identify the fundamental driver: fear of job loss. In an environment where labor law enforcement is weak and replaceability is high, engineers work overtime to signal commitment. The author contrasts this with civil servants who do not overtime because they cannot be fired at will. Overtime becomes a performative protest against unrealistic schedules — "we maxed out hours and still missed the deadline, so the plan was flawed."

A quantitative argument follows: chronic overtime drops efficiency by roughly 30%. Compensating for that loss requires a 50% increase in hours (e.g., 40 → 60 hours/week) just to break even. Most companies operate within that 50% overtime band, meaning they gain zero net output. The extra hours only serve as theater for management.

The core analysis attributes overtime to systematic violation of software engineering principles across four dimensions:

Requirements: Stakeholders replace formal specs with one-liners, boss whims, or product-manager "gut feelings." Analysis is compressed into five-minute meeting notes; version 1.0 drafts go straight to code. Mid-project contradictions and last-minute logic changes force all-night patching.

Technical decisions: Deadlines override architecture reviews, coding standards, and automated testing. Copy-paste duplication, misusing databases as config stores, and skipping unit tests become normalized. Each shortcut saves minutes today but creates technical debt that later demands full-team firefighting and "refactoring" sprints.

Process: "Agile" is misused to justify no planning, no documentation, and no process. Daily stand-ups become pressure sessions; sprint planning pulls random large tickets; retrospectives end with "same next time." No requirement freeze, no technical spikes, and compressed test windows shift all uncertainty onto developers.

Resource allocation: Managers apply linear scaling — "10 people for 1 week instead of 1 person for 1 month" — ignoring Brooks's Law from The Mythical Man-Month . Onboarding burns ~30% of existing capacity; parallel work multiplies integration friction; new requirements trigger context-switching storms. Actual coding time shrinks while coordination overhead balloons.

The article concludes that management is the primary culprit: when schedules slip, blame falls on engineers' "lack of grit"; when quality suffers, test coverage is faulted; when tech lags, teams are accused of not self-studying. Overtime is the symptom of front-loaded process shortcuts that explode late in the cycle.

A closing rant criticizes short-video creators who claim to build complex products in months, misleading non-technical stakeholders into demanding similar speed. Real R&D involves months of paper surveys, reference chasing, hardware procurement, and algorithm validation before a single line of production code is written.