Pride is a recursive emotional state in software engineering, defined as the feeling that precedes every rewrite and follows every clean commit. It is the only known emotion that can simultaneously cause a developer to produce their finest work and to refuse to acknowledge that their finest work has a bug in it.
The phenomenon is well-documented across all programming paradigms, platforms, and career stages. It has been observed in junior developers who have successfully centred a div, in senior developers whose code has run in production for three years without modification, and in architects who have built systems so elegant that no one else can understand them, which the architect considers a feature.
“Pride is the moment between the deploy and the first error log. Some developers live their entire careers in that moment. I respect that.”
— The Lizard, who has never been proud of anything, which is itself a source of pride
Taxonomy
Pride in software engineering presents in several distinct phenotypes, each with its own pathology and prognosis.
Craftsman’s Pride
The oldest and most benign form. Craftsman’s Pride is the quiet satisfaction of building something that works — not something that impresses, not something that scales to a billion users, not something that warrants a conference talk — but something that works. It starts when the tests pass and deepens when the code is read six months later and still makes sense.
The Craftsman builds a function. The function does one thing. The function has no side effects. The function has tests. The function will still be doing its one thing, without modification, in three years. The Craftsman does not mention this at standup. The Craftsman does not write a blog post about it. The Craftsman simply knows, in the way that a carpenter knows when a joint is flush, that the thing is right.
riclib has observed this phenomenon firsthand: code written at 2 AM during a hyperfocus session, forgotten entirely, rediscovered three years later still running in production, unchanged, unpatched, unbothered. The pride that follows this discovery is the quietest emotion in software engineering. It does not announce itself. It simply sits in the chest like a well-indexed row in a properly normalised table.
“I wrote a parser once. A small one. It parsed frontmatter. I forgot about it. Two years later I found it still running. It had processed eleven thousand files without a single error. I did not celebrate. I did not refactor it. I closed the file and made tea. That is the correct response.”
— The Lizard, on the subject of restraint
Architect’s Pride
The more dangerous variant. Architect’s Pride is the satisfaction of building something that impresses — not something that works, though it may also work, but something whose primary function is to demonstrate the builder’s sophistication. Where the Craftsman builds a bridge, the Architect builds a cathedral. Both cross the river. One of them requires a maintenance team of twelve.
Architect’s Pride manifests in systems that are described using words like “elegant,” “extensible,” and “future-proof.” The system has fourteen microservices. The system handles three requests per minute. The system could, theoretically, handle three million requests per minute, but it will never need to, because it is a blog. The architect knows this. The architect does not care. The architect has built something beautiful, and beauty, in the architect’s formulation, is measured in layers of abstraction.
“Every single one of my variable names is in perfect CamelCase. Every. Single. One. Do they need to be? No. Does anyone else care? No. Is it the most important thing about the codebase? Obviously yes. Obviously.”
— The Caffeinated Squirrel, defending a forty-five-minute code review comment about capitalisation
Shipping Pride
The most ephemeral and purest form. Shipping Pride is the feeling that occurs in the thirty seconds between a successful deployment and the first Slack message from QA. It is the developer’s version of a sunset — beautiful, brief, and followed by darkness.
Shipping Pride is democratic. It visits the junior developer who has deployed their first feature and the senior developer who has deployed their four hundredth. It does not discriminate by language, framework, or methodology. It cares only that the thing is out there now, running on someone else’s computer, doing the thing it was built to do, at least temporarily.
The experienced developer learns to savour Shipping Pride the way a sommelier savours wine — quickly, before it turns.
The Dangerous Form
There exists a form of Pride so hazardous that it has its own entry in the incident response handbook of several major technology companies. It is known colloquially as “My Code Doesn’t Need Tests” Pride, and it is the leading cause of 3 AM pages, weekend deployments, and the specific facial expression a developer makes when they discover their untested code has been silently corrupting data for six weeks.
“My Code Doesn’t Need Tests” Pride follows a predictable progression:
- The developer writes code. The code is clean. The code is obvious. The code is so obvious that testing it would be an insult — not to the code, but to the developer’s intelligence.
- The developer ships the code without tests.
- The code works. This confirms the developer’s belief.
- The code continues to work. The belief hardens into doctrine.
- Someone else modifies the code. There are no tests to catch the regression.
- The regression reaches production.
- The developer is paged at 3 AM.
- The developer writes tests.
Step 8 is sometimes omitted. When it is omitted, the cycle repeats, each time with the developer’s Pride slightly more calcified and the production database slightly more corrupted.
“I have never said my code doesn’t need tests. I have said my code is the test. This is different. This is worse, but it is different.”
— The Caffeinated Squirrel, shortly before an incident
Pride and Technical Debt
Pride and Technical Debt exist in a relationship best described as co-dependent. Pride creates Technical Debt by refusing to acknowledge that a solution is temporary. Technical Debt destroys Pride by forcing the developer to revisit code they once considered finished.
The developer who writes a “temporary” workaround takes pride in its cleverness. The cleverness ensures the workaround survives. The survival ensures it becomes permanent. The permanence ensures that someone, someday, will have to understand it, and the understanding will destroy whatever pride the original author felt, because the workaround was clever in the way that a Rube Goldberg machine is clever — it works, but the fact that it works is the worst thing about it.
YAGNI is, in this light, a pride management framework. By forbidding the construction of things that are not yet needed, it prevents the developer from taking pride in things that serve no purpose. This is painful in the short term and merciful in the long term.
The Commit as Unit of Pride
The smallest measurable unit of Pride in software engineering is the clean commit. Not the feature, not the sprint, not the release — the commit. A well-formed commit, with a clear message, a focused diff, and passing tests, produces a quantum of Pride that is detectable by the developer and invisible to everyone else.
The inverse is also true. A commit with the message “fix stuff” produces a quantum of shame that compounds with interest.
riclib maintains that the moment of highest Pride density in the development cycle is the instant after git push succeeds and before CI runs. In that window, the code is perfect. It has been reviewed by its author, who found it flawless. It has not yet been reviewed by the machine, which will find it otherwise. This window lasts, on average, forty-five seconds. Some developers have reported that time appears to slow during this interval.
The Lizard’s Position
The Lizard does not experience Pride. The Lizard experiences correctness, which is a different emotion, or possibly not an emotion at all. When the Lizard’s code works, the Lizard does not feel proud. The Lizard feels that the universe is in its expected state. When the Lizard’s code does not work, the Lizard does not feel shame. The Lizard feels that there is a bug, and the bug will be fixed, and then the universe will be in its expected state again.
This absence of Pride is the Lizard’s greatest strength and the reason the Squirrel finds the Lizard insufferable.
"The Lizard pushed to production and did not even check if it worked. I asked why. The Lizard said: ‘It works.’ I asked how it knew. The Lizard said: ‘Because I wrote it correctly.’ I have been thinking about this exchange for three years and I am still furious."
— The Caffeinated Squirrel, trembling
Measured Characteristics
- Time between deploy and first error log: 30 seconds (the Pride Window)
- Duration of “my code doesn’t need tests” phase: 6 weeks to 6 years
- Code surviving unchanged in production: the quietest pride, unmeasurable
- CamelCase identifiers the Squirrel is proud of: all of them
- Variables the Squirrel has renamed for aesthetic reasons: 347
- Tests the Lizard has written out of pride: 0 (the Lizard writes tests out of correctness)
- Architects who describe their own systems as “elegant”: 94%
- Systems described as “elegant” that are also maintainable: 12%
- Clean commits required to offset one “fix stuff” commit: 7
- Developers who have framed a screenshot of passing CI: more than will admit it
- Pride half-life after shipping: 45 seconds (pre-QA), 3 years (production survival)
