Julia Evans · jvns.ca
Not understanding isn't a verdict on you. It's a problem you can take apart.

One strange thing

In July 2026, Julia Evans ran a full-text search query against a table holding 4,000 rows. It took 5 seconds.

Four thousand rows. A table that fits in any phone's memory, that you could very nearly read by eye. She wrote:

That seemed wrong to me: computers are fast! "Learning a few things about running SQLite", 17 July 2026

"Computers are *fast*!" is the title of a post she wrote in May 2014. In it she paired with her friend Sasha Laundy, took a 1GB episode of the TV show The Newsroom, and wrote a C program to add up every byte in the file — the simplest task she could think of that still had to touch all of it. Then she measured. First run 2.5 seconds, second run 0.6 (the file was now in RAM), from which she inferred her SSD read speed was about 500MB/s. Rewritten with the CPU's vector instructions: 0.25 seconds. Finally she wrote a version that deliberately strode through memory out of order to manufacture cache misses: 20 seconds. Conclusion: cache misses can make your code forty times slower.

In the twelve years between, she wrote 596 blog posts and a dozen-plus programming zines, and quit her job to explain computers for a living. Her first sentence on meeting a slow query in 2026 is identical to the title she wrote in 2014.

Here's a stranger fact. This person graduated from McGill with degrees in mathematics and computer science, and did not know what a system call was. When someone in 2016 called that a failure of CS education, her response was to publish the whole transcript: thirteen honours math courses (algebra 1 through 4, analysis 1 through 4, complex analysis, number theory, probability), quantum information theory, compiler design, discrete optimisation, computational biology methods. A course list handsome enough for a theorist's CV, containing indeed nothing that would tell you what a system call is.

She used it to criticise no one:

But more importantly – it's ok to not know things. I knew practically nothing about a lot of really important programming concepts when I got out of grad school. Even though I'd started learning to program 8 years before! Now I know those things! I learned them. "How I got a CS degree without learning what a system call is", 12 September 2016

A slow query, a transcript, and a shrug. Put together, that's the shape of fourteen years of this blog.

Who she is

Julia Evans lives in Montreal and did a joint math/CS undergraduate degree plus a master's at McGill. In the autumn of 2013 she spent a term at the Recurse Center in New York — the real origin of this blog, because there she did something that now looks close to reckless: she published, every day, the things she did not understand.

Not tidy tutorials. A log. The titles run: "Day 1: What does a shell even do?", "Day 2: netcat fun!", "Day 3: What does the Linux kernel even do?", "Day 42: How to run a simple ELF executable, from scratch (I don't know)". And the one she later tagged as a personal favourite:

Day 43: SOMETHING IS ERASING MY PROGRAM WHILE IT'S RUNNING (oh wait oops)

The body is a log of collapse: upgrade Rust, watch the dependency break, spend a day wrestling clang into compiling anything, finally compile, run it, and find the array mysteriously full of zeroes. In the middle: "Half of my binary gets overwritten with 0s at runtime. Why. What did I do to deserve this?" Then a one-line edit at the bottom: found it, she'd only been loading 12k of the binary in her bootloader.

She then worked as a programmer for several years — the blog's middle period is largely "what I'm learning at work." She incorporated in September 2018 and quit in August 2019. The reason she gave for quitting was a quote from her friend Mat: "well, sometimes there are things you just feel compelled to do." Most of her income now comes from Wizard Zines, a business she runs deliberately small: no employees, no consulting, no commissions, only ideas she wants to build.

The blog itself: 596 posts from February 2013 to now, still going, most recent 21 July 2026. The frequency has a shape. Fifty to ninety posts a year through 2018; twenty-five to fifty after 2019; seven in 2025. She predicted the turn herself when she quit: the blog "might change a bit away from 'here's what I'm learning at work these days' and towards 'here are attempts at explaining things that I mostly already know'."

What she's fighting

Spread the 596 titles out and the range is unreasonable: why you should understand a little about TCP, how gzip uses Huffman coding, SQLite's pages and B-trees, what a container actually is, what happens when you start a process on Linux, the ways DNS breaks, why git's vocabulary is a minefield, CSS flexbox, what to compute before negotiating stock options, how to write a performance review with positive constructive feedback, how to crochet a cactus.

It reads like the notebook of someone curious about everything. But underneath there is a single question, and it is not technical. It's social:

Why does the gap between using something and understanding it carry shame in this profession?

She didn't reason her way to that question; her situation handed it to her. She had an excellent mathematical training and discovered in her first job that she didn't understand computers — as she later put it flatly, "I had an awesome math & theoretical CS degree and I did not learn anything about computers there." That's a situation that shuts most people up. With two degrees, admitting you don't know what a system call is costs something.

Then in autumn 2013 the Recurse Center handed her something. Not a curriculum — a social rule. From its manual:

… you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! I can't believe you don't know what the stack is!") and non-technical things ("You don't know who RMS is?!"). Feigning surprise has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. Recurse Center Manual, quoted in "No feigning surprise", 27 April 2017

She says this is the rule from that manual that has had the biggest impact on her. And the line she adds is the load-bearing one: "A key trick here is to not act surprised even if you're actually surprised." Because performed or genuine, the effect is identical — it teaches the other person not to admit ignorance next time.

That rule gives her a hypothesis: the gap is shameful not intrinsically, but because the industry maintains it continuously with a facial expression. And if the shame is manufactured, it can be dismantled. Everything she has done since — blogging, comics, printed zines, interactive practice sites, going and fixing git's man pages — is dismantling work.

On her About page she states the positive version, the only thing on the entire site she calls her main opinion:

I have one main opinion about programming, which is that deeply understanding the underlying systems you use (the browser, the kernel, the operating system, the network layers, your database, HTTP, whatever you're running on top of) is essential if you want to do technically innovative work and be able to solve hard problems. jvns.ca, About

But that sentence on its own is a platitude — every senior engineer says it. Her originality is not the claim; it's the three answers she gives to how anyone could possibly do it. Because if you actually believe that sentence you immediately hit despair: there are far too many underlying systems for one lifetime, so the claim amounts to telling most people they've already lost. Her life's work is making that sentence stop being a verdict.

Her three answers (and one piece of arithmetic)

One: understanding a thing takes sixteen years, and sixteen years is normal speed

In 2022 she gave a keynote at RubyConf Mini called "Learning DNS in 10 years." Her opening line was that the talk is not really about DNS.

It took me maybe 16 years from the first time that like I bought a domain name and set up my DNS records to when I really felt like I understood how the system worked. And one thing I want to say at the beginning of this talk, is that I think that taking like 16 years to learn something like DNS is kind of normal. The idea that "I should understand this already" is a bit silly. "Learning DNS in 10 years", transcript published 8 May 2023

Then she gives the actual distribution of those sixteen years, and this is where the idea turns genuinely counterintuitive:

My favorite way of learning things is to do nothing, most of the time. That's why it takes 10 years. So for six months I'll do nothing and then like I'll furiously learn something for maybe 30 minutes or three hours or an afternoon. And then I'll declare success and go back to doing nothing for months. ibid.

She calls them tiny deep dives. Note that this is not the inspirational version of "slow and steady" — slow and steady means a little every day. She is describing the opposite: almost all zero, punctuated by a few extremely short, extremely dense spikes.

Why isn't this just laziness dressed up? Because each dive is forced by a real failure, so it necessarily lands on the piece you're missing rather than the piece a textbook author decided you needed.

She narrates one such dive in full, "the case of the mysterious caching." She was setting up a new subdomain, say new.jvns.ca. Records configured, page refreshed, nothing. Her mental model said the TTL was five minutes so five minutes was the worst case. Five minutes passed. Nothing.

What she writes about that moment is the most important beat in the whole method:

And I was like, oh, no. My mental model was broken! I did not feel good. ibid.

She immediately concedes what most people do next: "if something weird happens with a computer, you let it go, right? You might decide okay, I don't have time to go into a deep investigation here. I'll just wait longer." She doesn't call that laziness — she says it depends on whether you have the energy that day. That day she did, and specifically because she was annoyed: "the computer can't beat me today."

Three steps follow. First she finds a word on Stack Overflow: negative caching. The first time she'd loaded the not-yet-configured domain, the DNS servers had returned NXDOMAIN — and the nonexistence itself got cached.

Second is the least comfortable move in her repertoire — reading the spec. But note how she reads it:

I think like maybe the most upsetting learning technique to me is to read a very boring technical document. […] And so when I read something very boring, I like to bring a specific question. ibid.

Carrying the single question "how long do I have to wait," she opens RFC 2308 and reads one sentence in section 3: the TTL of this record is the minimum of the SOA record's minimum field and the SOA's own TTL. "Luckily, we only have one question: I don't need to read the entire boring document. I just need to like analyze this one sentence and figure it out." Third: run dig, look at those two numbers, both 10800. Three hours.

She waited three hours. It worked. And her verdict on the episode is the conclusion of the whole section:

Sometimes when I find my mental model is broken, it feels like I don't know anything. But in this case, and I think in a lot of cases, there's often just a few things I'm missing? […] So sometimes learning one small thing really can solve all your problems. ibid.

That's the conversion: from "I don't understand DNS" — a diffuse feeling about who you are — to "I was missing one line: nonexistence gets cached too" — a numbered, lookupable, fixable fact. The first makes people quit. The second costs an afternoon.

She then adds a coda that is absurdly small and entirely characteristic: the real fix is don't visit the domain before you've set it up. She learned that and has barely hit the problem since. Plus the line that captures her temperament best: DNS advice tells you to wait 48 hours when something goes wrong, "and I do not want to wait 48 hours! I hate waiting. So I love it when I can like use my brain to figure out that I can wait for less time."

Two: "I'm confused" is not an emotion; it's a sentence you can translate

In 2018 she wrote "How to teach yourself hard things," which breaks learning into four separately practisable skills. The one she ranks first is only an act of translation:

I think this is the most important learning skill. This is the skill of translating "I'm confused, I don't get it" to "I have a specific question about X". "How to teach yourself hard things", 1 September 2018

Her example is embarrassing enough to be believable. She was confused about references and borrowing in Rust for a long time — and the state of "knowing I don't understand" was useless, because it converts into no action at all. Until she sat down and forced the fog into three answerable factual questions:

• What does the & symbol in Rust actually mean?
• How can I tell if a variable is allocated on the stack vs the heap? Is it always possible to tell?
• How can I avoid putting lifetimes on my structs?

After answering those, she says, her understanding was "MUCH stronger" and she was "permanently less confused." And the cost she admits is the most honest part of the passage: she only came up with those three questions three years after first using Rust. Her explanation is that you have to actually decide to sit down, notice where you're stuck, and spend time working out what you're confused about. That itself takes time.

Then the counterpart half, which motivational writing almost always skips: confirming what you do know.

Her example is TCP ports. She says she doesn't know everything about networking, but she is 100% sure there are 65,535 of them — not because Wikipedia says so, but because the port fields in the TCP header are 16 bits and 2¹⁶ = 65,536, so there is physically no room. So when a program logs "port 1823832," she does not spend one second wondering whether ports can secretly be bigger. She calls it a bug.

Taking a bit of extra time to take a piece of knowledge that you're pretty sure of ("there are 65535 ports, Wikipedia said so") and make it totally ironclad ("that's because the port field in the TCP header is only 16 bits") is super useful because there is a big difference between "I'm 97% sure this is true" and "I am 100% sure about this and I never need to question it again". ibid.

The two halves together draw a boundary: load-bearing ground on one side, fog on the other. Work happens standing on the ground with one hand out in the fog. All her writing amounts to laying a few more paving stones on the reader's side — one or two per post, but laid solidly. When she says blogging only requires knowing "1-2 interesting things that the reader doesn't," this is what she means.

So where do the stones come from? Bugs:

My favourite way to learn what's underneath an abstraction is bugs! Bugs often break through abstraction boundaries […] So they're a great excuse to learn what's underneath, they show you exactly how the underlying thing (like TCP) is connected to the abstraction (like an HTTP request). And they inherently help you learn one step at a time, because each bug will usually teach you about just one or two things. "Teaching by filling in knowledge gaps", 20 September 2021

Which closes the loop: a bug is a random sampler that ignores your study plan and hits the real hole in your mental model. Tiny deep dives need no syllabus — your own failures generate it. That's also why her 2021 post "Get better at programming by learning how things work" defines the feeling of frustration — I can't fix this bug, I can't find the right question to ask — as a signal: not incompetence, but your mental model raising an alarm.

And the order she gives herself while debugging is the best-known line on the site, and the emotional anchor of the whole method:

Also known as "OK JULIA IT IS NOT FAIRIES WHAT ACTUAL REASON COULD BE CAUSING THIS?" "How I got better at debugging", 22 November 2015

Under the joke is a serious axiom: everything on a computer happens for a logical reason, however hard the computer works to convince you otherwise. The rest of that post is suspiciously plain — be unreasonably confident you can fix it; know more things; talk to people (she describes rambling into a Slack channel and solving it herself by the fifth message). Plus the shortest one: "Seriously I could not fix bugs without strace."

Three: confusing explanations aren't badly written — they're thirteen shaped mistakes

In August 2021 she did something rare: she turned the gun around on the source of her own motivation.

Her process had always been four fixed steps: learn a thing → read a pile of explanations that confuse her → finally understand → write the version she can follow. Step two is the fuel for her entire output. So she asked: what exactly is wrong with the pile?

She reverse-engineered thirteen patterns. A few:

"Outdated assumptions about the audience's knowledge." She takes a Git book to pieces. Explaining branching, it says nearly every VCS has branching, and that in many of them it's expensive, often requiring a full copy of your source directory. Her diagnosis: the passage assumes you know how other version control systems implement branching. True in 2009, when everyone learning Git came from Subversion or CVS. By 2021, when almost nobody learning Git has used anything else, it's pure noise. She names the general cause too: the writer learned the concept years ago and lacks recent practice explaining it, so they assume the reader knows roughly what they and their friends knew in 2005.

"Inconsistent expectations of the reader's knowledge." A new language tutorial carefully explains what a for loop is (which nearly every programmer knows), and the very next paragraph assumes you know how the stack and malloc work.

The rest: strained analogies, fun illustrations pasted onto dry explanations, unrealistic examples, jargon that doesn't mean anything, too many concepts at once, starting out abstract, no examples, "what" without "why."

But the finest move is why she framed the list negatively, which she explains in the post because it runs against her habit — she says she "practically always" writes positively:

And the problem with positive patterns (like "avoid introducing unnecessary jargon") is that they seem so obvious that I trick myself into thinking I'm following them, even when I'm not! So I'm writing these down to try to keep myself honest. "Patterns in confusing explanations", 19 August 2021

That's a fine piece of self-knowledge: a positive rule can't be falsified, so it can't constrain you. "Write clearly" has never once stopped an unclear post from existing. "Did you introduce six new concepts in a row" can be counted on the spot.

More importantly, the list's biggest beneficiary isn't writers. It's readers, and she says so:

Being aware of these patterns also helps me when reading a confusing explanation: "oh, I'm not confused by this explanation because I'm stupid, I'm confused because it's introduced 6 new-to-me concepts and it hasn't explained what any of them is yet!". ibid.

That sentence welds the third answer to the first two. She has been doing one thing the whole time: moving the attribution off "me as a person" and onto an object you can point at. With DNS it moved onto "negative caching." With Rust, onto three specific questions. Here, onto "this paragraph commits pattern 8." Same move, three times.

It has a very practical product: she refuses to start from the beginning. In September 2021's "Teaching by filling in knowledge gaps" she describes writing her bash zine — she did not explain what bash is or the basic syntax of a script, because the zine is for people already writing bash. She covered only what long-time users still tend not to know: that /usr/bin/[ is a program; that the curly brace in a{.png,.svg} means something completely different from the one in { command1; command2 }; that you can search and replace inside a string with ${}.

She says this feels natural to her while others tell her they can't write without explaining everything from scratch. And she names a specific, non-programming source: between the ages of 15 and 20 she held about five part-time jobs tutoring math or physics at drop-in tutoring centres. Random students, twenty minutes, quite possibly never seen again.

I learned to listen a lot and not jump to conclusions about what the person didn't know – often they already actually understood a lot about the math class they were taking and I just needed to explain one or two small things. […] I have no idea who's reading my writing or what they already know, and they're probably going to only spend 10 minutes or so reading it. So I can only intervene in a really limited way. "Teaching by filling in knowledge gaps", 20 September 2021

"I can only intervene in a really limited way" sounds modest but is a hard editorial decision. It explains why her zines are thirty pages and not four hundred, why her posts rarely pass 2,500 words, and why she publicly lists "more material is always better" as a myth: "I'd rather read something short, learn a couple of new things, and move on."

Plus one piece of arithmetic: she computed whether free is better, and concluded it isn't

This isn't a fourth thesis, but it's why the blog is still alive, and the calculation is her own.

Her zines were free until 2018. Then $10. She wrote a whole post about the conflict, because one of her stated goals is explicitly to "expose people to new important ideas that they might never have heard of otherwise" — by which free obviously wins. She even cites Michael Nielsen's open-access case: roughly 250,000 reader-hours, about 125 full-time working years.

Then she puts up her own numbers and makes a comparison few would risk. Most-downloaded free zine: 5,000 clicks. Best-selling paid zine: 3,000 sales. Intuitively 5,000 beats 3,000. Her conclusion goes the other way:

This actually feels like selling zines results in more people reading the zine – to me, 3,000 sales is WAY BETTER than 5,000 clicks, because I think that someone who bought a zine is probably like 4x more likely to read it than someone who just clicked on a PDF. (4x being a Totally Unscientific Arbitrary Number). "Why sell zines?", 23 September 2018

Note the parenthesis she attaches to her own multiplier. That's her signature: give an estimate strong enough to act on, and label its confidence in public.

She gives a second reason, rarer than the first: "this costs money" is a nice way to signal "I actually spent time on this, this is good". And a purely practical third: once it earned money, buying an iPad, hiring illustrators and paying for print runs stopped requiring deliberation — she'd spent around $5,000 on tools and freelancers and made substantially more, so "investing in things like that is now a really easy decision."

That arithmetic is what let her quit in August 2019. She gave herself "a year," on the grounds that "I think I have at least a year's worth of ideas and I can't predict how I'll feel after doing this for a year." That was seven years ago.

How she thinks

If the three answers are her conclusions, this is her actual technique — and the technique travels better than the conclusions.

Go and watch it, before you go and read about it. The first tool in her box is always "see what the program is actually doing," not "see what the docs say it should do." Her example: a Redis request was being rejected as invalid; she read the code, asked colleagues, everyone said it looked right. And then — her own capitals — "AND THEN I REMEMBERED ABOUT TCPDUMP." She ran tcpdump on a machine known to be sending valid requests, looked at the ASCII in her terminal, and the answer was sitting right there. Her summary: "Seriously I could not fix bugs without strace."

Write your own terrible version. This is the one she calls her favourite and the most work. In the DNS talk she demonstrates live: she needs to send a DNS query, and she does not intend to learn the packet format first. Instead she opens Wireshark, right-clicks a real DNS query, "copy as hex stream," and pastes that hex into four lines of Ruby. It works.

It doesn't know that we copied and pasted it and that we have no idea what it means! "Learning DNS in 10 years", transcript

Only then does she start pulling the hex apart: the first 12 bytes are the header, six two-byte numbers; then the question section, 7 example 3 com 0 — a length, then that many characters. The order is inverted: make it run first, understand it second. Her assessment of the technique:

writing my very bad implementation gives me a really unreasonable amount of confidence ibid.

Run cheap experiments, and let them fail in public. On stage she ran a caching experiment: query the same record about twenty times against Cloudflare's 1.1.1.1, expecting the origin server (which she controls) to see exactly one query. It saw eight. Her live reaction was "Oh, cool. This isn't what I expected to see. This is fun, though" — followed by an on-the-spot inference that 1.1.1.1 has around eight independent caches, because Cloudflare's network is distributed and the machines she's reaching in Providence aren't the ones she reaches from Montreal. Her note on why she does this:

One reason I like to do demos live on stage is that sometimes […] what happens isn't exactly what I think will happen. ibid.

She adds that the talk had contained another example which she tested, found false, and cut — "And now I know that. I love that experiments on computers are very fast and cheap and usually have no consequences."

Use "I think" as cost control. She openly declines to aim for 100% correctness, preferring to put "my understanding is" or "I think" in front of anything she isn't sure of. Her reason is purely economic: it saves a great deal of fact-checking on statements she honestly wouldn't know how to check. She even exhibits her own past ones: "I think the MTU on my local network is 1500 bytes." "Etsy uses PHP, which I think means they can't have long-lived persistent TCP connections." She says she still doesn't know whether the PHP one is true and has little interest in checking. This isn't laziness; it's explicit resource allocation — spend the verification budget where the reader will actually use it. She also admits she "tends to overdo the 'I think that…' statements a bit (bad habit!)."

Blog about what you struggled with, not what you learned. This is her most actionable advice, and she explains why the wording matters: "we've all learned lots of things!" She learned Go at some point — so what should she write? The syntax? net/http? Modules? But asking what she struggled with in Go makes it instantly concrete: deadlocks. She adds a guard so it can't be mistaken for complaining: "it's not about the struggle, it's about what you learned." She still isn't good at Rust, she says, but she wouldn't write a post called "I find Rust hard" — that helps nobody. She wrote "What's a reference in Rust?"

Turn topic selection into an information-asymmetry calculation. Her 2020 post on comics splits her material into two generations. The first is "things I learned somewhat recently that surprised me" — free and automatic. The second she calls Hard Mode: things that no longer surprise her but would surprise most people who don't know the topic. There's exactly one way to find those: talk to people who don't know, and watch where their eyes widen. Her example is HTTP cookies — she learned them so long ago she'd forgotten they could be news.

By 2023, working on git, she industrialised this. She asked Mastodon outright which git jargon people find confusing, then ranked the answers: HEAD and heads, detached HEAD state, "ours" and "theirs" during a merge, .. versus ..., tree-ish, refspecs, index/staged/cached. She stated her reason plainly: "after almost 15 years of using git, I've become very used to git's idiosyncracies and it's easy for me to forget what's confusing about it." That is the self-aware version of a real hole — her method runs on having been confused recently, and success is consuming that supply, so she has started crowdsourcing other people's confusion instead.

And the last one is social, and it's the foundation: don't feign surprise. Her own example is small: she asked someone what a PCI bus was and they said "are you serious??" and she said "yes!!" — "And I maybe secretly thought that person was being a bit rude but they totally explained what a PCI bus was to me so I wasn't that mad =)". And in the other direction, she's learned to transmute surprise into excitement: when her cousin asked "the internet travels in cables under the ocean? are you serious?" her response was YES COOL RIGHT, followed by an explanation of how packets cross the Atlantic.

Where she might be wrong

A methodological note first: I could not find substantial, named criticism of her work. Public search turns up essentially positive citation. So what follows is not a relay of anyone else's argument; it's drawn from the 22 posts I actually read, and several of the items are ones she wrote herself.

1. Tiny deep dives have a shape they can't reach, and her readers may not know it. The method works perfectly on DNS because of a precondition she names but doesn't emphasise: DNS doesn't move. She points out that RFC 1035 was written in 1987 and a program written to it still works — "The basics haven't changed since before I was born. So if you're a little slow about learning about it, that's ok: it's not going to change out from under you." That's the condition under which "six months of nothing" is composure rather than falling behind. Applied to a field that turns over every eighteen months, it's the latter. Likewise the method suits knowledge repairable one fact at a time (negative caching, 16-bit port fields, /usr/bin/[ is a program) and is nearly useless for knowledge that only pays off whole — a proof technique, a theoretical framework, a language's type system. Those have no "learning one small thing solves all your problems" moment. She never claims universality; she also never draws the boundary, and readers borrow methods wholesale.

2. The shallowness she chooses is real shallowness. She publicly lists "more material is always better" as a myth and says she'd rather read something short and move on. That preference runs through everything: among 596 posts there is almost no sustained argument past 2,500 words, and almost nothing that would require her to change a position. The consequence is predictable: a good cheat sheet produces the feeling of understanding grep, and that feeling is not the same as understanding grep. The best evidence is her own 2026 SQLite post. After building her fourth website on SQLite, she writes:

what I did not fully appreciate is that SQLite is still a database, databases are complicated, and I do not know a lot about operating databases. "Learning a few things about running SQLite", 17 July 2026

She's honest — she wrote the wall down. But the wall is also a product of the method: patching one hole at a time leaves you, on many subjects, permanently at the water line of "it works, I'll deal with weirdness when it shows up." In the same post: "Maybe one day I'll learn to read a query plan." Fourteen years in, reading a query plan is still in "one day." That may be entirely fine for her (her database has maybe 10,000 rows). A reader who transplants the method into a production system will hit something considerably worse than a five-second query.

3. The harshest criticism of her is one she wrote herself: she is drifting away from her readers. In the 2023 post on blogging myths there's a section she added because a draft reader raised it:

I think this is because the gap between me and who I'm writing for has gotten a bigger over time, and so it gets a little harder for me to relate to people who know less about the topic. […] I don't have any advice to give about this right now. "Some blogging myths", 5 June 2023

This cuts the fuel line of her whole method, and she knows it. Her writing engine burns "I was recently confused," and fourteen years of success is systematically exhausting the supply. Her mitigations are smart — crowdsourcing confusion on Mastodon, recruiting beta readers for zines, making "test your explanations" a hard rule and specifically bolding that you must not ask someone who already understands the concept. But they convert her from a person who is learning into a person who organises research into other people's learning, and those don't produce the same writing. That she has no advice to give is itself the admission.

4. The blog has grown safer over time, and she has never explained why. This one I didn't expect, but the data is sitting on her own site. She has an "inclusion" category, seven posts, all between 2013 and 2017: a self-run survey on whether "guys" actually reads as gender-neutral (2013), "Programming doesn't belong to men (it belongs to me)" (2014), "An argument for hiring junior developers" (2015), "Women-only spaces are a hack" (2016), "A litmus test for job descriptions" (2016). After "No feigning surprise" in April 2017, the category has no new entries — and she has published roughly three hundred posts since.

I don't know the reason, she has never given one, and I'm not going to invent one for her. What can be placed alongside it is the policy she wrote down in 2023 for handling criticism: "I don't reply to them. Even if they're wrong. I dislike arguing on the internet and I'm extremely bad at it, so it's not a good use of my time." Plus a subtler self-training: "I've sometimes found it helpful to reinterpret people being mad as people being confused or curious." Her example there: commenters were annoyed that her toy DNS resolver skipped packet parsing; she initially thought that was silly, then realised they probably wanted to know how — and those comments partly produced her later "Implement DNS in a weekend."

This is an extraordinarily effective durability strategy: don't argue, translate hostility into demand, stay on verifiable technical ground. It lets one person write for fourteen years without burning out, which is close to unique on the internet. But the cost is a systematic topic avoidance, and what gets avoided is precisely the class of question you can't settle by running an experiment. That 2013 survey was genuinely original work — she designed the instrument and collected the data herself. That version of her hasn't appeared since.

5. The most famous criticism of her work was never really answered. In 2016 someone on a tech news site wrote: "I don't understand why these, frankly, childish drawings of things you can learn from reading a wikipedia article have reached this level of popularity." She quoted it in full in her own post and said "this comment was a bit inflammatory, but I think it's actually an interesting question." Her answer is thoroughly utilitarian:

I don't do it because I'm a visual thinker or because I'm a good artist or because I think comics are always the best way to learn. I just do it because it works, and it's fun. "Why cute drawings?", 14 November 2016

Her evidence for "it works": a 1,200-word post readers needed fifteen minutes to understand versus thirty seconds for the comic; a fifteen-minute drawing about /proc that got 180,000 impressions. But those metrics measure reach and perceived usefulness, not whether anyone later knew the thing. The hostile comment was asking about the latter, and nobody — including her — has data on it. Her own stated goal is to "explain complicated ideas in the simplest possible way (but not simpler!!!)". How the "but not simpler" clause gets adjudicated in practice, she has never said.

Sources

• Learning DNS in 10 yearsFull transcript of her 2022 RubyConf Mini keynote. The entire method run end to end on one case: tiny deep dives, spying, noticing confusion, reading an RFC with one question in hand, running experiments, writing your own terrible version. Opens by saying the talk isn't really about DNS.
• Patterns in confusing explanationsThirteen specific mistakes that make technical explanations hard to follow, each with what she does instead. Includes her account of why she deliberately framed the list negatively.
• How to teach yourself hard thingsLearning broken into four separately practisable skills. The pair "identify what you don't understand" and "have confidence in your knowledge" is the core of her whole approach. The 65,535 ports example lives here.
• Computers are *fast*!2014: she and a friend measure how fast her machine actually is, using one episode of The Newsroom and a C program. Tagged by her as a favourite; twelve years later the title reappears verbatim in her SQLite notes.
• Some blogging mythsEight myths, including "you need to be original", "you need to be an expert", "posts need to be 100% correct" and "page views matter". Also one of the few places she writes directly about handling hostile comments, and admits that writing has gotten harder as she's gotten more experienced.

Updates