Curiosity is a persistent, low-level interrupt in the human cognitive stack that causes the afflicted individual to investigate how things work, especially things that are already working, and most especially things that would continue working indefinitely if left alone.
It is not a desire for improvement. It is not troubleshooting. It is the specific, unjustifiable need to know — to understand the mechanism, the architecture, the reason behind the reason — even when that knowledge has no practical application, no business value, and no chance of being mentioned in a sprint review. Curiosity does not care about your sprint review. Curiosity was already three abstraction layers deep before the standup started.
The phenomenon is widely considered the root cause of both civilisation and the inability to finish anything on time.
Etymology and Taxonomy
The word derives from the Latin curiositas, meaning “desire to know,” which the Romans considered a vice. They were not wrong. They were also not curious enough to invent the transistor, so the matter remains unresolved.
Curiosity manifests in three recognised variants:
Passive Curiosity. Wondering how something works. Harmless. Brief. Easily satisfied by a Wikipedia article. Does not occur in software engineers.
Active Curiosity. Opening something up to see how it works. The dehydrator variant. Characterised by the phrase “I just want to understand the PID controller logic” spoken to no one in particular at 11 PM on a Tuesday. The device was functioning correctly. The dried mangoes were excellent. None of this mattered.
Terminal Curiosity. Needing to understand how something works at the lowest possible level of abstraction, then building something new with that understanding, then becoming curious about that. This is the variant that produces operating systems, programming languages, and people who read CPU datasheets for recreation.
“The dehydrator works. The mangoes are perfect. But there’s a PID controller in there, and I don’t know what constants they chose, and I don’t know why they chose them, and that — that is not a state I can remain in.”
— riclib, not fixing anything
The Z80 Proof
The earliest documented case of terminal curiosity in the lifelog corpus occurred at approximately age fourteen, when a young riclib — already in possession of a perfectly functional home computer — decided that using the computer was insufficient. He needed to know how the computer worked. Not at the BASIC level. Not at the operating system level. At the register transfer level. At the level where electrons become instructions.
Z80 Assembly was not a career decision. It was not a pedagogical exercise. It was curiosity — pure, undiluted, and utterly impractical for a teenager in the 1980s who could have been outside. The Z80 had an 8-bit data bus, a 16-bit address bus, and 252 instructions, and the boy needed to understand every single one of them. Not to build something specific. To know.
This is the critical distinction. Curiosity does not ask “what can I build with this?” Curiosity asks “how does this work?” The building comes later, as a side effect, almost an afterthought. The Z80 led to the 68000, which led to the Amiga bootblock, which led to systems programming, which led to a career. But the career was not the point. The career was what happened when curiosity accidentally became marketable.
“I did not learn assembly to get a job. I learned assembly because the machine was doing things and I did not know how. That was intolerable.”
— riclib, explaining thirty-five years of career decisions in one sentence
The Squirrel Origin
It is a matter of historical record — well-documented in the Caffeinated Squirrel entry and corroborated by multiple eyewitness accounts — that the Squirrel was not always caffeinated.
Before coffee, the Squirrel was merely curious. A woodland creature of ordinary metabolic rate, investigating acorns, examining bark patterns, disassembling pinecones to understand their seed distribution architecture. The curiosity was there. The velocity was not.
Then the Squirrel encountered a coffee bean.
A non-curious squirrel would have ignored it. A passively curious squirrel would have sniffed it and moved on. But the Squirrel — possessed of the terminal variant — needed to know what it was, what it did, and what would happen if she ate it.
What happened was caffeine.
The curiosity did not increase. The clock speed increased. The same questions — “What is this? How does it work? What if I—” — now arrived at approximately forty times their previous frequency. The Squirrel who had been methodically investigating one acorn per afternoon was now proposing React, Alpine, a seven-layer trust fabric, and “a really small Redis” before breakfast.
Curiosity created the Squirrel. Coffee weaponised her.
“I wasn’t always like this. I used to be curious at a reasonable pace. Then I found the bean.”
— The Caffeinated Squirrel, in a rare moment of self-awareness (0.3 seconds, then she proposed a microservice)
The Lizard Distinction
The Lizard is also curious. This fact is consistently overlooked by those who mistake the Lizard’s patience for indifference. The Lizard is not incurious. The Lizard is curious slowly.
The Lizard will investigate a problem for weeks. Months. The Lizard will read the RFC. The Lizard will read the RFC that the RFC references. The Lizard will understand the problem so thoroughly that the solution, when it arrives, is self-evident, minimal, and correct.
The difference between the Lizard’s curiosity and the Squirrel’s curiosity is not one of magnitude but of temporal resolution. The Squirrel is curious about everything simultaneously. The Lizard is curious about one thing completely. The Squirrel’s curiosity is a scatter plot. The Lizard’s curiosity is a depth-first search.
Both are curiosity. Both produce understanding. One produces understanding and a proposal for a Kubernetes cluster. The other produces understanding and a single, correct function.
“I am curious about everything you are curious about. I am simply curious about it one thing at a time. This is not a limitation. It is completion.”
— The Lizard, to the Squirrel, who had already stopped listening
Curiosity and the Yak
The yak-shave is not a failure of planning. The yak-shave is curiosity’s natural byproduct.
The developer sets out to fix a bug. Fixing the bug requires understanding the module. Understanding the module requires understanding the dependency. Understanding the dependency requires reading its source code. Reading its source code reveals an interesting algorithm. The interesting algorithm uses a technique the developer hasn’t seen before. The developer is now reading a 1978 paper on balanced binary trees at 1 AM, and the bug is not fixed, but the developer understands the dependency, which is what curiosity wanted all along.
The bug was the pretext. The understanding was the objective. The yak-shave is the path curiosity takes when it is nominally constrained to a task. The task is a corridor, and curiosity has found every door.
This is why curious developers spend three days finding an elegant solution instead of applying the quick fix that would have taken twenty minutes. The quick fix solves the problem. The elegant solution satisfies the curiosity. The problem was never the point. Understanding the problem was the point, and an elegant solution is proof of understanding in the way that a quick fix is proof of expedience.
“The quick fix works. The elegant fix teaches you something. We are not here to work. We are here to learn.”
— riclib, justifying three days of yak-shaving with a philosophical framework
The Dehydrator Incident
In March 2026, a food dehydrator in a kitchen in Estonia was functioning correctly. It dried fruit. It dried vegetables. It dried herbs. Its PID controller maintained temperature with admirable precision. It had no bugs. It required no maintenance. It was, by every engineering metric, a solved problem.
riclib disassembled it.
Not because it was broken. Not because the dried mangoes were unsatisfactory. Because there was a PID controller in it, and the PID controller was running firmware, and the firmware contained constants that someone had chosen, and riclib did not know what those constants were, or why they had been chosen, or whether they were optimal, or what “optimal” even meant in the context of mango dehydration.
The dehydrator is currently in pieces on a workbench. The firmware is being decompiled. The PID constants will be understood. The mangoes remain excellent — this was never about the mangoes.
This is curiosity in its purest form: the investigation of a functioning system not to improve it but to comprehend it. The dehydrator will be reassembled. It will work exactly as it did before. Nothing will have changed except the developer’s understanding of PID control theory as applied to tropical fruit, which is knowledge that has no market value, no practical application, and no place on a CV, and which the developer considers essential.
Measured Characteristics
- Systems disassembled that were working fine: 94% of all systems disassembled
- Time from “I just want to understand” to complete teardown: 4-45 minutes
- PID controller firmware decompilation sessions initiated at 11 PM: at least 1
- Z80 instructions memorised at age 14 for no practical reason: 252
- Quick fixes rejected in favour of elegant solutions: ~70%
- Additional days spent per elegant solution: 2-5
- Squirrel proposals traceable to curiosity rather than necessity: ~100%
- Coffee beans investigated by pre-caffeinated squirrels: 1 (sufficient)
- Yaks shaved as direct consequence of curiosity: uncountable
- Career decisions explainable by curiosity: all of them
- Dehydrators reassembled with no functional improvement: 1 (projected)
- Regret: 0
