Engineering maturity isn't years served: 3 belief updates
Thomas Dullien says maturity is three specific belief updates, not years on the job. Here's what those look like for a Sri Lankan engineer on shared infra and a small budget.
Engineering maturity in Sri Lanka is usually measured in years served and job titles collected. Five years, "Senior". Eight years, "Tech Lead". Nobody checks whether anything in your head actually changed.
Thomas Dullien (Halvar Flake) published Three important steps in my maturation process on 21 August 2026. It proposes a different measure: three specific beliefs you had to update. Two of the three land harder here than in Mountain View.
🧠 Step 1: your incentive structure is writing your opinions
Dullien's first realisation comes from his 0day years: he agonised over whether holding an exploit nobody else had made him responsible for what followed. His conclusion was that the agonising was partly vanity.
"Anxiety about the impact of your work is self-flattering, and you have to recognize it as such."
He pairs it with von Neumann's line that "some people profess guilt to claim credit for sin." The instruction is blunt: do not believe everything you think, and ask "how might I be the villain in this story?" Translate that to a Colombo engineering career and it stops being philosophy:
| The belief you hold | The incentive quietly holding it up |
|---|---|
| "Our stack is fine, rewriting is a waste" | You are the only person who knows the stack |
| "Remote USD work is the only sensible path" | Your last local interview went badly |
| "Local companies never pay properly" | You've never actually negotiated hard |
| "I should stay 3 more years for the title" | Leaving means admitting the title was the point |
None of those beliefs are automatically wrong. The point is that you acquired them in an order that flattered you, and never tried the other side.
The cheapest version of this discipline is arithmetic. Before deciding a job or a rate is unfair, work out the real number instead of the felt number: our salary and rate tools do net-to-gross and freelance hourly maths in seconds. A belief that survives a spreadsheet beats one that only survives your friends.
⚡ Step 2: determinism is a luxury our infrastructure does not grant
This is the section I'd hand to every CS undergraduate in the country. Dullien argues that the monocausal determinism young programmers get used to is an illusion maintained by generations of electrical and process engineers: computing machines are physical devices subject to wear, unit-to-unit variation, and "probabilistically deterministic behavior." Push on temperature, voltage, electromagnetic fields, or repeated accesses to adjacent DRAM rows, he writes, and it collapses.
"The real world is one where very few things that happen have a single reason, and very few truly deterministic transmission mechanisms. Everything is probabilistic, and everything is multicausal."
Here's my angle. In a well-funded environment that illusion holds for years, because money buys it: dedicated instances, redundant power, generous headroom. On a shared 4-core VPS with a few gigabytes of usable RAM, which is what most Sri Lankan side projects run on, the illusion never gets a chance to form.
| The deterministic model | What actually happens on shared, budget infra |
|---|---|
| Build passes or fails on code | Build gets OOM-killed because something else spiked at the same moment |
| Failed test = real bug | Failed test = contention, timeout, or a cold cache |
| Lab performance score = user experience | Lab score looks good; real field data still fails Core Web Vitals |
| The deploy caused the outage | The deploy, plus a health check, plus a redirect loop, together caused it |
I've been on the wrong side of every row in that table. The costliest was assuming a failed build meant broken code. It usually meant two heavy jobs had landed in the same minute on the same box, and the fix was scheduling, not debugging.
His corollary is worth sitting with: the scientific method is a classifier deliberately biased against accepting things as true, so a large class of true things will never be scientifically demonstrated. If you are chasing an intermittent production issue with no reliable reproduction, you are not failing at engineering. You are working where proof is unavailable and probability is all you get.
💡 Step 3: emotion is information, not interference
The third update gets dismissed fastest by technical readers, which is roughly the evidence for it. Dullien argues the reason-versus-emotion split is a western cultural construct, not a neurological fact, and that in most non-western cultures integrating deliberation with emotion is the normal model.
His trivia hook: your gut's enteric nervous system contains as many neurons as the entire cerebral cortex of a dog, and your body forward-deploys neurons into muscles and extremities as latency optimisation. That information reaches you as feeling, not sentences. Then the logical argument, which is the part that convinces:
"Attempting to eliminate a particular source of information almost certainly makes the quality of your decisions worse."
That is an information-theoretic claim, not a self-help one. If a codebase makes your stomach drop every time you open it, that reaction encodes pattern-matching your verbal brain hasn't finished compiling. Same for the client whose emails you keep postponing, or the review where you couldn't articulate the objection but knew there was one.
Note his caution: this is not an argument for acting on impulse, but for treating the feeling as a signal to investigate rather than noise to suppress.
Key takeaway: Maturity here isn't years on the job. It's noticing your incentives before they finish writing your opinions, dropping the assumption that one cause explains one effect, and treating your gut reaction as unlabelled data rather than a defect.
🛠️ Four things I'd actually change on Monday
- Write down the counter-narrative. For your strongest technical opinion this quarter, write the best version of the opposite case. If you can't write a good one, you don't understand your own position.
- Stop saying "the root cause". Say "the largest contributing cause". Running things on cheap infrastructure, I have almost never found a single cause.
- Log the environment, not just the error. Free RAM, load average, and concurrent jobs at failure time. Half of your "bugs" will resolve into contention.
- Treat dread as a ticket. When part of the codebase or a client relationship consistently makes you avoid it, open an issue for the avoidance itself.
🚀 What this means for you
If you are a student or a junior engineer here, take the second update seriously first. Coursework and tutorials run inside a deterministic sandbox that production, especially production you can afford, does not provide. Probabilistic thinking is the difference between an engineer who can operate a system and one who can only write code for it.
If you are further along, the first update is the expensive one. Nobody will tell you that your architectural preference is really a job-security preference, or your rate opinion really a confidence problem. You catch that yourself, and the only tool that works is arguing against yourself in writing.
The third is free. It costs nothing to stop treating your own discomfort as a bug in your reasoning. It is data. Check it, but don't throw it away.
The original post is short and has no signup wall. Read it in full rather than trusting my summary.
Original source
Three important steps in my maturation process