Which Part Was Me?

Last week I said I was still working on an answer. I have a partial one. It's smaller than I hoped and bigger than I feared.

Here's the question again, for anyone who skipped the last post. (I saw the analytics. I'm fine. I said it a little too fast.) When a tool does in seconds what took me a decade to learn, which part was me?

I started by making a list. Engineers make lists when they're anxious.

Column One

Column one was the stuff I spent years learning that a model now does as well as I do, or better. It was longer than I wanted. Syntax for a dozen languages, most now niche (Assembler, Fortran, Prolog). The exact incantation that makes a linker stop complaining. API surfaces I memorized like phone numbers. Boilerplate. So much boilerplate. I was proud of all of it. Some of it paid for a house.

A lot of it turns out to have been lookup. Very fast lookup, with good taste in what to look up, but lookup. That's the "smaller than I hoped" part. It stung more than I expected.

Column Two

Column two took longer, because the things in it were harder to name. Knowing which problem is worth solving before anyone writes a line. Looking at a clean, confident architecture diagram and feeling that something is wrong before I can say what. Asking the question nobody in the meeting asked. Knowing when the right answer is "don't build it." None of it survives being written down as a rule.

That's the "bigger than I feared" part.

In college I studied Wittgenstein, who spent a lot of time on a question that sounds dumb until it doesn't. How do you know how to follow a rule? Not the rule itself. The applying of it. No rule tells you when it applies. You'd need another rule for that, and another for that one, and eventually you hit bottom on something that isn't a rule at all. It's practice. It's judgment. It's what's left when the lookup is free.

I think that's the part that was me. It's also, inconveniently, the part I can't put on a slide.

So how did I sort the columns? Mostly by remembering an old bug.

The 2 a.m. Lesson

Years ago I worked on Video On Demand at Motorola. We had a system that would run beautifully, then fall over. Not one server. The whole thing, in a cascade. We'd bring it back up, it would be fine, and then it wasn't. We looked for a pattern in time of day, load, content, the phase of the moon. Nothing.

Eventually I noticed something small. The failure always started on the ninth request of a burst. Not the eighth. Not the tenth. The ninth.

I had no idea why that mattered. I stared at it for longer than I'd like to admit. Then I remembered our servers had eight cores. The ninth request was the first one that had to wait. The first one to block.

That pointed us at locking, specifically fair versus unfair locks in Java. A fair lock serves waiting threads in the order they arrived. An unfair one lets newcomers jump the queue. That meant that the 9th request stayed blocked until the burst of traffic cleared, and by that point it had timed out.

Here's the thing. A model today could explain fair and unfair locking better than I could. Point it at the lock and it would probably fix it before lunch. What I'm less sure it could do is notice the nine. The number wasn't in any single log. It was a pattern across dozens of crashes, and its meaning lived in a hardware spec that had never been written down. Maybe a future model spots it. Even then, someone has to decide the ninth request is worth staring at.

That staring is column two. It's also the part I'd been underpricing for 45 years, because it never showed up in a line count.

The Test

Here's the working distinction I landed on. If I can write it down as a rule, it's column one, or it will be soon. If I can only show it by example, it's column two.

This is not a comfortable test. It means the columns aren't fixed. Things migrate. Every time someone writes down a piece of judgment clearly enough, it moves left. Code review heuristics. Architecture patterns. Security checklists. That's the grief I wrote about last time, and it isn't going away.

But the migration has a floor. Every rule you write needs someone to decide when it applies. Wittgenstein's regress doesn't end with a better rule. It ends in practice, not another rule.

What I'm Doing About It

If column two is the part that was me, I should probably invest in it on purpose. Four things so far.

I review agent output like a teaching case, not a chore. When it's wrong, I ask how I knew. Half the time the answer is context it didn't have. The other half is interesting.

I write down the near misses. Not the rules. The stories. Stories carry judgment in a way checklists don't. That's also how I learned most of it in the first place, usually from someone older telling me what went wrong in 1987.

I pair juniors with failures instead of tutorials. A tutorial teaches column one, and a model will beat them at it by lunch.

I stopped apologizing for the staring. Looking at something until you know what's wrong with it is not slowness. It's the job now. Possibly it always was.

Back to the Buoy

Last time I said nobody catches a drifting buoy, and the rower's job is to hold a steady stroke (I wrote the timing program for a regatta and the finish line buoy got cut and started floating downstream). I'd add one thing. Someone also has to notice the buoy moved. Someone on the bank has to say, "Wait. That's not where the finish was."

That's column two. The model rows beautifully. It still doesn't know the buoy was cut.

So which part was me? Less than I thought. The part that remains is the part that was always doing the real work, hiding behind all that syntax. I'm a little embarrassed it took a machine to show me. I'm also relieved it's there.

Anyway. I'm going to go knead some dough. That's where the column two stuff tends to show up.