Why five years at the same job feels like a long weekend
A colleague once told me he had fifteen years of experience. His manager, in a rare moment of honesty, replied: "You have one year of experience, fifteen times."
Brutal. Also, physiologically accurate.
Here is the mechanism. Your brain does not store duration. It stores change. It works like a version control system with aggressive deduplication: if today is byte-identical to yesterday, no commit gets written. Same alarm, same commute, same standup where six people say "nothing from my end", same lunch, same evening scroll, same bed. Nothing new to encode, so nothing gets encoded. And when you later ask your memory "how long was that?", it does not count days. It counts commits.
Empty log, short history. That is time compression - and it is why a week of travel feels longer in hindsight than the four months of office routine that funded it.
Researchers have a name for the small-scale version: the oddball effect. Drop something unexpected into a stream of repetitive stimuli and the brain rates the surprise as having lasted measurably longer than the identical repeats around it. Attention spikes, uncertainty spikes, encoding spikes. The stretch is on the order of tens of milliseconds in lab conditions - tiny, but it proves the machinery exists. Scale it up to weeks and you get the reason your thirties evaporated.
Three things kill small businesses that never appear in a business plan: the room you work in, the stories you absorb, and the money that was never yours.
I have been self-employed a few times. Before my enterprise career, between two of them, and on the side. None of it made me rich. All of it taught me things you cannot learn from a startup podcast, because podcasts talk about scaling and my problem was that a customer's dog did not like me.
Let me hand over the three lessons that actually cost me something
Your business has a physical address, even when you think it doesn't
Everyone starts in the bedroom, the garage or the study. Fine. Nobody plans the other rooms.
One of my ventures was classic IT service. Persuading stubborn printers to acknowledge the existence of WiFi. Removing pre-installed bloat from our favorite corporate operating system. Explaining, for the fourth time, that a tablet needs updates. Mostly on-site, at people's homes.
Some clients objected to travel fees. Reasonable. They wanted to come to me. Slight problem: I had no office and no presentable workshop. So I invited them into my dining room - statistically the least private room in the house, right up until a stranger sits in it holding a coffee cup and telling me about his divorce while I diagnose a random reboot.
I once watched a senior engineer - twenty years of experience, could read a stack trace like a bedtime story - try to learn to juggle at a company offsite. Three balls, two hands, zero dignity. She dropped everything for twenty minutes straight while interns filmed it.
Six months later she told me that offsite was the week she finally cracked a certification she'd been stuck on for a year. She was convinced it was the juggling. She might have been right.
Here's the mechanism, and it's backwards from what most people believe: the adult brain doesn't rewire because you feed it information. It rewires because you feed it errors. When your predictions about the world fail hard and repeatedly, your nervous system releases the neuromodulators - dopamine, norepinephrine - that mark active circuits for change. No errors, no chemical signal, no rewiring. Recent neuroscience even points to a dedicated brain-wide "model failure" alarm system (the locus coeruleus) whose whole job is shouting "your predictions are garbage, update everything."
That feeling of frustration? That's not a bug. That's the smell of the signal being released. The brain games industry sells you comfortable puzzles you're already decent at. Comfortable means low error rate. Low error rate means the alarm never fires. You're paying a subscription to not learn.
Compression as via negativa: the cheapest token is the one you never send
Take any coding agent session and open the raw request log. Not the pretty transcript - the actual payload. What you find is a JSON search result with 100 hits where 3 mattered, a log file where the interesting line is buried in 800 lines of "INFO: still fine," and a directory listing of a repo the model already walked twice.
Then apply the uncomfortable ratio: cost of the finished output versus the raw inputs actually required to produce it. The model needed maybe 2,000 tokens of real signal. You paid for 55,000. In manufacturing terms, that is a part made of solid gold to hold a plastic clip in place.
I spent a few weeks running everything - coding, research, boring text work - through a compression proxy called Headroom, and the interesting part was not the money. It was watching exactly how much of what I "sent" to the model was never information in the first place.
What it actually does
It sits between your agent and the API and squeezes everything the model reads - tool outputs, logs, retrieved chunks, conversation history - before it goes upstream. Compression happens locally, nothing gets shipped off to a third party to be shrunk. The model can pull the original back if it needs it.
The strangest math in enterprise hiring: paying sports-car money for output you then throttle by hand
A while back I sat in a coffee shop with someone from a very large, very admired technology company. Nine-figure revenue per quarter, the kind of place that puts "we hire only the top 1%" in its recruiting deck without irony.
He told me his last quarter honestly. Two weeks of real engineering. Ten weeks of alignment.
His compensation, fully loaded, was roughly the price of a mid-range sports car per year. So the company paid sports-car money and received, in terms of the thing they actually hired him for, a used scooter. Not because he was lazy. Because 80% of his calendar was owned by people whose job was to make sure nobody did anything surprising.
I hear a version of this story from nearly everyone I talk to who works inside the big names. It is consistent enough that it stopped being anecdote and started being physics.
The idiot index of a knowledge worker
There is a useful little instrument from manufacturing: take the cost of a finished part and divide it by the cost of its raw materials. A machined bracket that costs 200 euros but contains 8 euros of aluminum tells you something. Not that aluminum is expensive. That your process is stupid.
Rehearsing in your head is the corporate equivalent of "it works on my machine"
One estimate puts inner speech at around 4,000 words per minute. You speak out loud at maybe 130 to 150. So the version of you that rehearses the big presentation in your head is running at roughly 30x the clock speed of the version that has to show up in the room.
That is not confidence. That is a benchmark run on hardware you do not own.
I learned this from a colleague I'll call the Cathedral Builder. Brilliant systems engineer, the kind of power horse 🐎 who could hold an entire distributed architecture in his head and tell you which node would fail on a Tuesday. We had a customer escalation heading for the executive floor: eight weeks of instability, a CTO who had run out of patience and vocabulary, and a 15-minute slot to explain the root cause and the plan.
He prepped for three days. I asked him to run it past me. He said he had it, he'd been through it several times.
In his head.
He had, genuinely. Every argument in perfect order, every objection anticipated, every metaphor elegant. In there it was a TED talk with a standing ovation and a book deal.
There's one unmistakable smell that tells you a company has quietly entered its death spiral. It isn't mass layoffs or missed earnings. It's the moment management looks at a genuinely broken tool, UI, script, or workflow and decides the easiest fix is... another process.
An email goes out. A new KB article appears. Someone records a TOI video. A fresh Slack channel is born. The wiki gets another page that nobody will read after next week. And just like that, the organization has chosen to compensate for bad tooling with human friction.
I watched this exact pattern play out at a mid-sized software company that, on paper, still looked healthy.
The internal escalation tool had a nasty bug in its search function. Simple queries returned incomplete results about 40 % of the time. It had been that way for months. Instead of fixing the underlying indexing issue (which the devs swore would take "only a couple of sprints"), leadership sent the classic memo: "Please use this new workaround when searching for escalations." The workaround involved three extra steps, copying ticket IDs into a separate spreadsheet, cross-referencing with another system, and then posting in a dedicated Slack channel so someone else could verify you hadn't missed anything.
German is objectively denser than English. It still makes your prompts worse. And the reason tells you exactly where this is all heading.
A while ago, someone asked me, with the sincere enthusiasm of a person who had just had a Big Idea: "German is so precise. Wouldn't prompting in German be more token-efficient?"
As a German, I wanted this to be true so badly. Finally, a competitive advantage from the language that gave the world Schadenfreude, Kummerspeck and Weltschmerz.
It is not true. But the reason it fails is more interesting than the idea itself.
The German hypothesis is linguistically sound
German really does pack more meaning per word. Compound nouns fuse concepts into single unambiguous units. Datenbankverbindungspoolverwaltung is one word, one concept, and the structure tells you precisely what belongs to what. The English equivalent, "database connection pool manager", are four words that leave you guessing whether the manager manages the pool, the connections, or the database. Add a case system that encodes relationships without prepositions, plus a vocabulary that prefers specific terms over vague umbrellas, and in theory you get fewer words for the same instruction.
Fewer words, fewer tokens, cheaper and sharper prompts. Beautiful theory.
A while back I met an old colleague for cocktails. We do this every so often - two people who have seen enough server rooms and steering committees to know that the best incident reviews happen over a Negroni.
He was in a great mood. His company's vibe coding (quickly developing software using AI like Claude without writing (or sometimes even understanding) the code itself) adoption was through the roof. And not just among developers - consultants, architects, support engineers, basically anyone with a pulse and a Claude license was building tools. Management was celebrating. They threw around numbers like trophies: one engineer burned through 100 dollars a day in tokens. Applause. High fives. Slide decks.
And honestly? Fair enough. If a 100-dollar-a-day token bill produces a tool that saves ten hours of engineering time per week, that's the cheapest employee you ever hired. I am not here to rain on token budgets. Fun fact on the side: "vibe coding" went from a casual Karpathy tweet to Collins Dictionary Word of the Year within roughly twelve months. That's faster adoption than most companies manage for a new expense tool.
But while my colleague was celebrating, I was doing what 20+ years in support trenches trains you to do: listening for the alarm underneath the applause.
Why Most "Hard Workers" Stay Stuck on the Hamster Wheel
The inbox hits at 8:03 a.m. like clockwork. Twenty new tickets, three "urgent" Slacks from people who clearly didn't read yesterday's update, a fresh vanity dashboard from leadership showing likes on the internal town-hall post, and one passive-aggressive calendar invite titled "Quick sync on priorities." By 9 a.m. you're already exhausted, yet somehow the needle on actual customer outcomes hasn't moved a millimeter.
Welcome to the hamster wheel sponsored by modern corporate life. Most of us are reacting to noise and calling it productivity. The quiet power horses 🐎 figured out years ago that consistency doesn't amplify effort. It amplifies whatever you choose to respond to. Ignore that distinction, and you stay busy forever. Get it right, and you start moving like a rocket with afterburners.
I once watched a second-line support engineer I'll call Marcus live both versions in real time. Year one he was the ultimate firefighter: every ticket spike, every minor SLA blip, every random customer complaint got his full attention. He answered every Slack, joined every optional sync, chased every daily fluctuation in the support metrics. By December he was burned out, his actual impact flatlined, and the performance review read like a participation trophy: "Reliable team player who responds quickly." Translation: stayed on the wheel.
TrenchOps 🐎 
