Anger

Anger is the second of the five stages of Grief in the Kübler-Ross model, the loudest stage by a considerable margin, and the only stage that can be reliably detected from an adjacent room by sound alone. In software engineering, anger is the natural emotional response to reading code you did not write, code you did write but do not remember writing, code reviews that use the word “interesting,” deployments that fail for reasons that are technically your fault, and dependencies that publish breaking changes in minor version bumps.

It follows Denial — the stage in which the developer closes the file and opens it again, hoping the architecture has rearranged itself — and precedes Bargaining, the stage in which the developer proposes to refactor just this one module, which is a lie, but a productive one.

“WHO WROTE THIS.”
— Every developer, universally, in all caps, without a question mark, because it is not a question

The Anatomy of “WHO WROTE THIS”

The phrase is always capitalised. It is always rhetorical. It appears in Slack channels, in muttered desk-side monologues, in code review comments that have been edited three times to remove profanity, and in the private thoughts of every developer who has ever opened a file they were not expecting to open and found something they were not expecting to find.

The capitalisation is important. “Who wrote this?” with a lowercase W and a question mark is a genuine inquiry. It suggests curiosity. Perhaps even respect. “WHO WROTE THIS” with capital letters and a full stop — or, more commonly, no punctuation at all, because punctuation requires a composure the developer does not currently possess — is not a question. It is a scream formatted as a question, and everyone in the channel knows it.

The scream is followed, inevitably, by git blame.

git blame is the weaponisation of version control history. It was designed as a tool for understanding code provenance — who changed what, and when. In practice, it is used as a tool for assigning responsibility, which is a different thing entirely, in the same way that a kitchen knife is designed for preparing food but can also be used to open letters, threaten furniture, and — in extreme cases — settle arguments about tabs versus spaces.

The developer runs git blame. The developer traces each architectural decision to its author. The authors have, universally, left the company. This does not reduce the anger. This increases it, because the authors are now beyond the reach of code review comments, performance reviews, and the specific Slack message that begins with “Hey, quick question about this function you wrote —” and ends with a paragraph that is not a question and is not quick.

“The git blame showed fourteen authors over three years. Nine had left. Two denied any involvement. The remaining three blamed the nine who left. I blamed all fourteen. This was, I am told, not a productive use of the retrospective.”
— The Caffeinated Squirrel, vibrating at a frequency normally associated with industrial equipment

The Git Blame Revelation

There is a moment in every developer’s career — not a hypothetical moment, not a “this could happen to you” moment, but a moment that will happen, has happened, and is probably happening right now to someone reading this article — when the developer runs git blame, follows the commit hash, reads the author field, and discovers their own name.

The silence that follows is unlike any other silence in software engineering.

It is not the silence of confusion. It is not the silence of denial. It is the silence of a person whose anger has just been handed a mirror and told to look. The developer stares at the screen. The developer reads the date. Eighteen months ago. A different project. A different sprint. A different self, apparently, because the current self would never write a function like that. The current self has opinions about variable naming. The current self writes tests. The current self would leave a comment explaining why this particular piece of logic exists.

Except the developer who wrote this code was the current self, eighteen months younger, eighteen months less experienced, and almost certainly under a deadline that made writing tests feel like a luxury and writing comments feel like procrastination.

The anger has nowhere to go. You cannot be angry at someone who no longer exists. You cannot leave a Slack message for your past self. You cannot request a code review retroactively. The anger turns inward, briefly, and then — if the developer is healthy — transforms into something quieter. Not acceptance, exactly. Something closer to humility. The recognition that every codebase is a geological record of its authors’ competence over time, and the strata do not always improve as you move upward.

“Every developer is, on a long enough timeline, the author of their own legacy code.”
— The Lizard, who has never run git blame because the Lizard remembers every line it has ever written, which is either a gift or a punishment

Anger in Code Reviews

The code review is the formalised arena for engineering anger, the Colosseum where opinions about architecture go to fight and only one of them leaves alive, and the surviving opinion is always the reviewer’s, because the reviewer has the merge button.

The vocabulary of code review anger is a masterpiece of professional restraint. Direct anger is unprofessional. Direct anger gets you a meeting with your manager. So the anger is compressed, filtered, and emitted through a series of phrases that read as constructive feedback to anyone who has never participated in a code review and as declarations of war to anyone who has:

• “Interesting approach.” This means: your approach is wrong. Not interestingly wrong. Not wrong in a way that provokes intellectual curiosity. Wrong in a way that makes the reviewer question whether the author has read the team’s coding standards, which the reviewer wrote, which the reviewer is now questioning the purpose of, because apparently no one reads them.

• “Have you considered…” This means: I have considered. I have considered it extensively. My consideration has led me to the conclusion that your implementation is incorrect, and I am now presenting my conclusion as a question because questions are less confrontational than statements, and I have already been spoken to about being confrontational in code reviews.

• “Nit:” This prefix, short for “nitpick,” is theoretically used for minor stylistic suggestions that the reviewer would not block the PR over. In practice, a comment labelled “nit” is never a nit. A comment labelled “nit” is a fundamental architectural objection wearing a small hat.

• “Could we add a test for this?” This is not a request for a test. This is a statement that the reviewer does not trust the code and would like the author to prove it works, because the reviewer has looked at it and cannot convince themselves that it does.

“I once received a code review that consisted entirely of the word ‘Why?’ on fourteen separate lines. No elaboration. No context. Just ‘Why?’ fourteen times. I spent three hours rewriting the entire module. It was, I later realised, the most effective code review I had ever received.”
— A developer, requesting anonymity, because admitting that unconstructive feedback was constructive is professionally complicated

The Rage-Quit as Debugging Technique

The most paradoxical property of anger in software engineering is that it is productive, but on a delay. Anger at the moment of occurrence produces nothing useful — Slack messages that should not be sent, refactoring commits that should not be pushed, and architectural proposals that are revenge fantasies disguised as technical documents.

But the aftermath of anger — the period immediately following the rage-quit, defined as the act of closing the laptop, standing up, and walking away from the code with the specific body language of a person who has been personally betrayed by an abstract syntax tree — is one of the most productive states in software engineering.

The developer walks away. The developer makes tea, or coffee, or simply stands outside staring at a tree. The developer’s conscious mind is busy being angry. The developer’s subconscious mind, freed from the conscious mind’s insistence on the wrong approach, quietly works through alternatives. Twenty minutes later, the developer returns. The developer sits down. The developer opens the laptop. The developer writes the solution.

This is not a metaphor. This is not an exaggeration. This is a documented phenomenon in cognitive science: the incubation effect, in which stepping away from a problem allows unconscious processing to resolve it. Anger is the accidental trigger. The rage-quit is the accidental mechanism. The walk around the building is the accidental incubation period.

The developer does not understand this. The developer believes they “calmed down” and “thought it through.” What actually happened is that anger, having flooded the prefrontal cortex with enough neurochemical noise to drown out every wrong approach, then receded, leaving the one correct approach standing alone in the silence like the last person at a party who actually knows where the car keys are.

The implication is unsettling: the optimal debugging workflow may be to get angry, walk away, and come back. No one has proposed this in a sprint retrospective, because proposing “have you tried getting angry” as a process improvement would require a degree of self-awareness that retrospectives are not designed to accommodate.

Anger in Slack

Slack is where anger goes to become passive-aggressive, because Slack has no tone, no facial expression, and no way to communicate that the period at the end of “Fine.” is load-bearing.

The taxonomy of angry Slack behaviour is well-documented:

The Period. “Fine.” versus “Fine” versus “Fine!” — three different emotional states encoded in punctuation. “Fine” is neutral. “Fine!” is enthusiastic. “Fine.” is a declaration of war that the sender will deny is a declaration of war, which is itself an act of war.

The Emoji Reaction. The thumbs-up emoji (👍) on a message is, depending on context, either sincere acknowledgment or the most passive-aggressive gesture available in digital communication. A thumbs-up on “I’ve decided to rewrite the authentication service this sprint” is not agreement. It is the emoji equivalent of a raised eyebrow and a slow exhale.

The Typing Indicator. The three dots that indicate someone is typing a response, followed by the three dots disappearing, followed by the three dots reappearing, followed by the three dots disappearing again, followed by no message. The developer typed something. The developer deleted it. The developer typed something else. The developer deleted that too. The developer is angry enough to respond but professional enough not to. The absence of the message communicates more than the message would have.

The Delayed Response. An immediate response to a Slack message means engagement. A response after two hours means the person was busy. A response after exactly twenty-four hours means the person saw the message immediately, spent twenty-four hours composing a response that would be both professional and devastating, and then sent it at a time calculated to suggest they only just now noticed.

The Characters and Anger

The Caffeinated Squirrel is angry at everything simultaneously. The Squirrel is angry at the architecture and the deployment pipeline and the testing framework and the dependency graph and the code review process and the sprint planning meeting and the retrospective and the standup and the tools and the languages and the operating system and the hardware and the laws of physics as they apply to network latency. The Squirrel’s anger is not sequential. It is parallel. It runs on all cores.

The Squirrel’s anger is also, it must be noted, frequently correct. The architecture is suboptimal. The deployment pipeline is fragile. The testing framework is insufficient. The Squirrel sees all of this clearly, because the Squirrel’s anger is not blind — it is caffeinated. The problem is not that the Squirrel is wrong. The problem is that the Squirrel is angry about everything at the same time, which makes it difficult to prioritise, and prioritisation is the one thing the Squirrel has never been angry enough to demand.

The Lizard has never been angry. Not once. Not at code, not at architecture, not at dependencies, not at breaking changes, not at the developer who pushed to main on a Friday, not at the configuration file that interprets Norway as a boolean.

This is either enlightenment or a metabolic limitation.

The Lizard’s resting heart rate is seven beats per minute. The Lizard’s cortisol levels have never been measured above baseline. The Lizard’s response to a production outage is the same as its response to a sunny Tuesday: a slow blink, a calm assessment, and a solution implemented in fewer lines than the error message. The Lizard does not get angry because anger requires the belief that things should be different from how they are, and the Lizard does not hold this belief. The Lizard accepts the system as it is, fixes what can be fixed, and ignores what cannot. This is either profound wisdom or the emotional range of a reptile, and the Lizard does not find the distinction interesting.

“Anger is information. It tells you something is wrong. But it tells you in the same way a fire alarm tells you there is a fire — loudly, persistently, and without any suggestion of what to do about it.”
— The Lizard, offering advice it has never personally needed

Measured Characteristics

• Time between opening a legacy codebase and first “WHO WROTE THIS”: 4-47 minutes
• Volume of “WHO WROTE THIS” (decibels): 0 (typed) to 85 (spoken in open plan office)
• Percentage of git blame sessions that reveal the developer’s own name: 23% (self-reported); 61% (actual)
• Code review comments edited to remove profanity before posting: 3.7 per PR (industry average; higher in enterprise Java)
• Rage-quits per week (industry average): 2.4
• Solutions found within 20 minutes of rage-quit: 74%
• Solutions found during the rage-quit itself: 0%
• Load-bearing periods in Slack messages per team per day: 4-12
• Typing indicators that resulted in no message: 31% of all typing events
• Things The Caffeinated Squirrel is currently angry about: all of them
• Things The Lizard is currently angry about: none of them
• Things The Lizard should be angry about: a matter of ongoing debate
• The Lizard’s resting heart rate during a production outage: 7 bpm
• The Squirrel’s resting heart rate during a production outage: not measurable with current instrumentation
• Keyboards replaced due to anger-related mechanical failure per year: 1.2 per developer (Cherry MX Blue switches are over-represented)

See Also

• Grief — the parent phenomenon; anger is its loudest child
• Denial — what precedes anger; quieter, but no less delusional
• Bargaining — what follows anger; calmer, but no less futile
• Depression — what follows bargaining; the silent stage
• Acceptance — the destination, if you survive the journey
• Sarcasm — anger’s eloquent cousin
• The Caffeinated Squirrel — angry at everything, correct about most of it
• The Lizard — angry at nothing, which is either wisdom or cold blood
• Legacy Code — the primary fuel source for engineering anger
• Git — the tool that makes anger traceable