Competence Theatre

1. The claim

A pilot logs hours. A surgeon logs procedures. We log tabs.

Somewhere in the last decade this industry discovered that watching a competent person work is more pleasurable than being one, and, more importantly, that from the inside the two feel nearly identical. A twelve minute video of someone untangling a difficult module ends in the same warm, settled feeling as having untangled it yourself. That is the business model of the medium rather than a defect in you, and it works because it is pointed at something real: the pleasure of watching craft is one of the oldest pleasures there is.

Notice what a demo is engineered to remove. There is no data migration. There is no colleague who left in 2019 carrying the only working mental model of the billing service. There is no compliance officer, no partial failure, no clock skew, no forty page procurement questionnaire asking whether the vector store is FIPS validated. A demo is a jet engine bench tested at sea level and sold as a mountain crossing. Everyone involved knows this. Nobody is lying. The removal is what makes it watchable.

For its first year this paper was about watching, because watching was the door I had walked through. There is a second one, and it works from the opposite posture: you are not sitting still consuming anything, you are working hard, assembling. It produces the same signal. That is Section 8, added later, because it took me a year to notice the two were one argument.

2. Why the numbers look fine

We have more available knowledge per practitioner than at any point in this industry’s history, and a persistent, widely reported sense among practitioners that they are behind. Those two facts look like a tension and are the same fact. The supply of things that resemble learning has outgrown the hours in which learning can actually occur, and the surplus has to go somewhere. It goes into the feeling.

3. Who absorbs the cost

Not, mostly, the person watching. This is the part of the argument I had to rewrite after the correction recorded in the June 2026 revision, and it is where the paper stopped being about individuals.

The cost lands on whoever inherits the decision. A demonstrated architecture arrives in a design review carrying the authority of having been seen working, and the evidence for it is a recording in which the hard parts were removed by construction. The person who adopts it pays the removed costs later, one at a time, and pays them in an environment where the demonstration is no longer available to argue with.

  what the demo removed        who pays it back
data migration        ->  the team, in month four
partial failure       ->  whoever is on call
compliance review     ->  a person you never met
the departed colleague->  everybody, forever
procurement           ->  the deal, six weeks late

The reader correction that produced the June revision was this: the effect is strongest where tooling is locked down, not where it is abundant. An engineer in a bank with a restricted toolchain watches more demonstrations, not fewer, because watching is the only form of access available. That inverts the naive version of the mechanism, in which abundance causes substitution. Constraint causes it too, and by a different route.

4. What survives contact with production

The useful test is whether the demonstration carried the information you would need to operate it, rather than whether the technique is good. Almost none do, and the gap is systematic rather than accidental.

This is the same structure as 5.2. Assembly produces the knowledge of what a thing does and not of how it fails; watching produces even less, and produces it with more confidence, because watching has no compile step to disagree with you.

5. The remedy, which is not “log off”

Abstinence advice is both unrealistic and wrong. Watching skilled people work is a legitimate and efficient way to learn, and the apprenticeship objection in Section 6 is strong enough that I will not argue otherwise. The remedy is to attach a consequence to the watching, because the consequence is the only thing the medium removed that you can put back yourself.

• Convert one thing per week into a claim with a cost. Not notes. A change to something you own, small enough to ship, that can fail in front of somebody.
• Predict the failure mode before you look it up. Write one sentence on how the demonstrated system breaks. Then find a postmortem. The gap between your sentence and the postmortem is the measurement, and it is the only calibration signal available.
• Prefer artefacts with the hard parts left in. Postmortems, migration write-ups, capacity notes with a stated breaking point. They are less pleasurable, which is the point: the pleasure was being produced by the removals.
• Count what you shipped, not what you consumed. A pilot logs hours because hours flown is the quantity that predicts competence. The industry has no equivalent, so the substitute measure is whatever is easiest to count, and what is easiest to count is consumption.

None of this is a cure and I am not claiming it as one. It is an attempt to reintroduce the feedback loop with consequences attached, which is the distinction Section 6 says I cannot yet state cleanly.

6. The strongest objection, unanswered

Apprenticeship. All pedagogy involves watching. The apprentice watches the master, and this has worked for several thousand years. I do not yet have a clean line between apprenticeship and spectatorship, and until I do, this paper is weaker than its prose sounds. The distinction I am reaching for involves the presence of a feedback loop with consequences attached, but I cannot yet state it in a way that survives a determined counterexample. This objection is the entire reason confidence sits at 0.80 rather than 0.90.

7. What this paper does not claim

Technical content is not worthless. The sharpest version of the objection above is that it is the primary way most people learn, and I have no answer to that. The producers are not dishonest either: the removals are what make the form work, and everybody involved knows they are there.

Section 4 is an argument, not a measurement, and it should be read as one. The retirement conditions state the evidence that would end this paper, and the first of them is the study I would most like somebody else to run.

8. The second mechanism: assembly

Added 2026-08-31. Sections 1 through 7 are about consumption. This one is about production, and it arrives at the same place.

The IKEA effect is the finding that people place higher value on things they assembled themselves. The part that matters to engineering is the sensation rather than the valuation: competence produced by assembly feels, from the inside, nearly indistinguishable from competence produced by comprehension. You did real work. The system runs. The feeling that arrives is the correct feeling for having understood it, and you did not.

This is the uncomfortable half of the paper. Section 5’s remedy was to build instead of watch, and building is exactly what this describes. Follow that advice literally, wire together six services you never opened, and you arrive at the same deficit by a route that feels like effort the whole way. Effort is what makes it hard to see. Having recommended the route is what makes it hard to admit.

8.1. The shared signature

Both mechanisms deliver knowledge, and both deliver the same two thirds of it.

The third row is the whole argument and it is the same row in both columns. Error paths are the least-read code in any system: rarely exercised in development, rarely covered by the happy-path tests that assembly produces, rarely present in the example the code was modelled on. A demo removes them because they are boring. Assembly skips them because the thing already works.

   two doors, one room
watching  --------+
|
v
what it does      [supplied]
how it does it    [sometimes]
how it fails      [never]
^
|
assembling -------+
the gap is invisible while the system works,
and becomes the entire problem when it stops

8.2. Why they are one argument

These are the same substitution sold at two prices, and the industry shipped both. Watch one engineer’s week: they consume an architecture on Tuesday, assemble one on Thursday, and by Friday hold a confident, sincere and unearned model of a system that has never failed in front of them. Both days felt productive. One of them involved a keyboard.

Split them into two problems and you get two wrong remedies. Treat it as a watching problem and the prescription is “build more”, which is Thursday. Treat it as an assembly problem and the prescription is “read what you assembled”, which sends people to read happy-path code they already understand. One substitution, one narrower remedy: read the error paths, in what you watched and in what you built. That is the row neither route ever fills in, and it is the only row an incident asks about.

8.3. What this section borrows

The assembly mechanism is compressed here. It is developed at length in paper 5.2, which has the three-kinds-of-knowledge table this section abbreviates, the account of why the confidence signal misfires, four practices that address it, and the objection it cannot answer, which is that nobody reads their TLS library either. 5.2 remains the authority on assembly. This section states only the part that makes it the same argument as Sections 1 through 7, and it does not supersede the paper it draws on.