Depression is the fourth of the five stages of Grief, the one that arrives not with a bang but with a 3 PM slump, and the one that is most dangerous precisely because it is the quietest. Denial is loud. Anger is louder. Bargaining is a twelve-page proposal. Depression is a developer staring at a velocity chart and saying nothing, because there is nothing to say that has not already been said in six consecutive retrospectives and ignored in seven consecutive sprint plannings.
In the Kübler-Ross model as applied to software engineering, depression is the stage where the developer stops fighting the legacy code and starts being sad — not because the code is bad, which was the anger stage, but because the code is normal. The code is not an anomaly. The code is not an aberration. The code is what code looks like, everywhere, in every company, in every language, in every decade. The four thousand lines of utils.go are not an exception. They are the rule. And the rule is depressing.
“It’s all like this.”
— Every developer, eventually, at approximately 3 PM
The 3 PM Slump
There is a specific hour when depression arrives during a debugging session, and that hour is 3 PM.
The developer has been debugging since 11 AM. The bug was supposed to be in the payment service. It was not in the payment service. It was in the event handler that calls the payment service. Except it was not in the event handler either — it was in the serialisation layer that feeds the event handler. Except the serialisation layer is fine; the problem is the data, which was corrupted by a migration script that ran six months ago and has been silently producing malformed records ever since.
The bug is not in any one file. The bug is in the relationship between files. The bug is architectural. The bug is the system.
At 3 PM, the developer closes the debugger. Opens Slack. Types nothing. Closes Slack. Opens the debugger. Closes the debugger. Opens the codebase. Stares at the codebase. The codebase stares back. The cursor blinks. Neither the developer nor the cursor has anything to say.
The sandwich from lunch sits untouched on the desk. The coffee went cold at 1:30. The developer will not eat the sandwich. The developer will not reheat the coffee. The developer will sit, and the cursor will blink, and the afternoon will pass in the specific way that afternoons pass when you have realised that the bug is not something you can fix but something you must live with, because the fix requires refactoring the entire event pipeline, which requires approval from three teams, which requires a meeting that will be scheduled for next quarter, which means the bug will still be here tomorrow, and next week, and next sprint.
“I once debugged a race condition for nine hours. At hour six, I stopped looking for the race condition and started questioning the fundamental assumptions underlying concurrent programming, and then computing in general, and then human endeavour. The race condition was a missing mutex. I found it at hour nine. I did not feel joy. I felt the specific absence of joy that is worse than sadness because sadness at least has texture.”
— The Caffeinated Squirrel, in an uncharacteristically subdued moment
The Code Nobody Uses
There is a depression unique to software engineering that has no analogue in other professions: the depression of maintaining code that nobody uses but nobody will let you delete.
The service has zero requests per day. Not “almost zero.” Zero. The dashboard confirms this. The logs confirm this. The billing confirms this — the service costs money to run and produces nothing except the quiet hum of infrastructure serving no one.
The developer knows the service has zero users. The developer’s manager knows. The infrastructure team knows. But somewhere, in a meeting the developer was not invited to, three stakeholders decided the service is “strategic.” This word — strategic — is the bureaucratic equivalent of a preservation order on a condemned building. It means the service cannot be decommissioned. It means the service must be maintained. It means when a dependency updates and breaks the build, someone must fix it. When a vulnerability is discovered in a library the service uses, someone must patch it. When the quarterly compliance audit asks “is this service maintained?” someone must say “yes” and mean it.
The developer writes tests for code that will never execute in production. The developer deploys updates that will never be requested. The developer maintains documentation that will never be read. This is not work. This is theatre performed for an empty room, and the developer is both the actor and the audience and the critic, and the review is not favourable.
“I maintained a service for two years that had one user: the health check. The health check confirmed the service was alive. Nobody else checked. If I had deleted the service, the only thing that would have noticed was the health check, which would have reported the service as dead, which would have been the first interesting thing the service had done in twenty-four months.”
— An anonymous developer, in a support group for maintainers of strategic infrastructure
The Velocity Chart
Sprint velocity is the quantification of team morale, expressed as a number and plotted as a line that tells a story the team already knows but the Scrum Master must see visualised before believing.
The story is always the same. Sprint 1: the line goes up. The team is new, or the project is new, or both. There is energy. There is optimism. There are architectural discussions that people enjoy. Sprint 3: the line plateaus. The easy work is done. The remaining work is the hard work that was estimated as easy work because estimation is hope wearing a spreadsheet. Sprint 5: the line dips. The technical debt that was deferred in Sprint 1 has come due. The tests that were skipped “for now” must be written “for real.” Sprint 8: the line descends.
The descent is gentle. It is not a crash. Crashes are dramatic and produce incident response. The velocity decline is a slow, steady, gravitational slide — the visual representation of a team that has not given up but has stopped believing that effort correlates with outcome.
The Scrum Master presents the chart in the retrospective. “What can we do to improve velocity?” The team is silent. Not because they have no ideas. They have the same ideas they had six sprints ago: reduce work in progress, address technical debt, stop adding scope mid-sprint, stop pulling developers into unplanned meetings. They said these things. The things were noted. The things were thanked. The things were written on sticky notes. The sticky notes were photographed. The photograph was attached to a Confluence page. The Confluence page was never read. The velocity continued to decline.
This is the depression: not the absence of solutions, but the demonstrated irrelevance of proposing them.
Burnout’s Quieter Cousin
Developer Burnout and depression are often confused, and the confusion is understandable, because they share a symptom: the developer still ships but has stopped caring. The difference is duration and scope.
Burnout is chronic. Burnout accumulates over months and years, eroding the developer’s relationship with the entire profession. Burnout is a career condition.
Depression, in the grief-stage sense, is acute. Depression is what happens on a Tuesday afternoon when the developer realises that this codebase, this specific codebase, is not going to get better. The developer is not burned out on software. The developer is sad about this software. The developer will recover — possibly by Thursday, possibly by the next sprint, definitely by the next project. But right now, in this moment, at 3 PM on this Tuesday, the developer is staring at a velocity chart that only goes down and feeling nothing at all.
The dangerous case is when acute depression becomes chronic — when the developer looks up from this codebase and realises that every codebase they have ever worked on looked like this, and every codebase they will ever work on will look like this, and the problem is not the codebase but the industry. That is the moment when depression stops being a stage of grief and starts being a permanent address. That is the moment when the developer should talk to someone who is not a rubber duck.
The Launch Nobody Noticed
There is a final depression that deserves its own section, because it is the cruelest: the depression of shipping something and having nobody notice.
The developer worked on the feature for three sprints. The code was clean. The tests were comprehensive. The documentation was written before the code, which is either best practice or a miracle, depending on your theology. The feature shipped. The deploy was green. The monitoring was calm.
The developer wrote a message in the team Slack channel: “Feature X is now live! Here’s what it does…” The message received no reactions. No replies. No thread. The message sat in the channel, between a lunch order poll (fourteen reactions) and a photo of someone’s dog (twenty-three reactions), and accumulated the specific silence that is louder than noise.
The developer drafted a celebration message. The developer deleted the celebration message. The developer had learned from the last time, when a similar celebration message received a single thumbs-up emoji from the team’s bot.
The feature works. The feature will continue to work. Users will use it without knowing it exists, which is the sign of good infrastructure and the cause of infrastructure engineers’ depression. The bridge does not get thanked for not collapsing. The database does not get thanked for not losing data. The feature does not get thanked for working exactly as designed.
“I once shipped a caching layer that reduced page load times by 400%. Nobody noticed, because the definition of a good caching layer is one that nobody notices. I received no feedback. This was, technically, the highest praise.”
— The Lizard, who has learned to interpret silence as success, which is either wisdom or a coping mechanism
The Squirrel’s Immune System
The Caffeinated Squirrel does not experience depression in the traditional sense. The Squirrel experiences distraction, which presents identically — the vacant stare, the motionless hands, the untouched espresso (unprecedented) — but has a completely different internal mechanism.
When a developer reaches Stage 4, they are thinking: “It’s all like this. Nothing will change. The code is the code. The industry is the industry. Why bother.”
When the Squirrel reaches the same outward state, the Squirrel is thinking: “Is that a butterfly? What framework is the butterfly using? Could the butterfly’s flight path be modelled as a state machine? I should build a state machine library. In Rust. No, in Zig. What’s Zig’s package manager situation like right now?”
The Squirrel’s depression-shaped episodes last between eleven minutes and three hours, ending the moment a new technology, framework, or controversial blog post enters the Squirrel’s field of vision. The recovery is instantaneous and total. The Squirrel does not process depression. The Squirrel rejects depression, the way a healthy immune system rejects a virus — not through treatment but through an overwhelming counter-response of enthusiasm for something else.
This is not avoidance. This is architecture. The Squirrel’s emotional system has no persistence layer. Sadness is stored in memory only and is garbage-collected the moment a new allocation is requested.
The Lizard’s Perspective
The Lizard does not experience depression. This is not because the Lizard is emotionally shallow. It is because the Lizard has context.
The Lizard has watched mass extinctions. Not metaphorical ones — actual mass extinctions, back when the Lizard was younger and the planet was less hospitable and the only programming language was RNA, which had even worse error handling than JavaScript. The Lizard has seen civilisations rise and fall. The Lizard has seen programming paradigms declared revolutionary and then abandoned. The Lizard watched structured programming replace GOTO, watched object-orientation replace structured programming, watched functional programming fail to replace object-orientation (so far), and watched the industry rediscover every pattern it previously discarded, on a cycle of approximately fifteen years.
From this vantage point, the velocity chart that goes down is not depressing. It is a local minimum in a function that, over sufficient time, trends upward. The codebase that is “all like this” is all like this now. It was not always like this. It will not always be like this. The Lizard has seen worse codebases recover. The Lizard has seen better codebases decay. The Lizard has seen utils.go files grow to four thousand lines and then — in a burst of energy that coincides with a new team lead — shrink to four hundred.
“You call it depression. I call it Tuesday. Not because I am dismissive of your suffering, but because I have had many Tuesdays, and they all eventually became Wednesday.”
— The Lizard, to a junior developer who had just discovered the test suite
This is not depression. This is perspective. And perspective, when you have enough of it, looks exactly like peace — which is either the highest form of wisdom or the most sophisticated form of denial, and the Lizard does not find the distinction worth examining.
Measured Characteristics
- Time spent in Stage 4 (average developer): 1-3 weeks per codebase
- Time spent in Stage 4 (The Squirrel): 11 minutes to 3 hours, interrupted by a butterfly
- Time spent in Stage 4 (The Lizard): zero (see: perspective, geological)
- Bugs that turn out to be architectural: the ones found at 3 PM
- Sandwiches left untouched during debugging sessions: approximately one per session
- Services maintained with zero users: more than any organisation will admit
- Sprint velocity charts that only go down: most of them, eventually
- Retrospective action items repeated across consecutive sprints: 3-7 (median: 5)
- Feature launches that received fewer Slack reactions than a dog photo: nearly all infrastructure work
- Caching improvements that went unnoticed (which is the point): 100%
- Developers who drafted and then deleted a celebration message: more than will admit it
- The Squirrel’s emotional garbage collection interval: approximately 11 minutes
- The Lizard’s Tuesdays that eventually became Wednesday: all of them, every single one
