Companion piece: Heads Down — what the same night taught me about how to drive a screen at all.
Back on those green screens, you could bring up a record and it would come up with values already in it. Pulled from the master file. Customer's address, a price, whatever the system already thought it knew.
The operator could type over any of it. That was the whole point. The paper in front of her was the real world and the master file was just the system's best guess about the real world, and when the two disagreed, the paper won.
So she'd type over it and carry on. It took her a second. It probably happened a dozen times a day.
Now here's the thing I want you to notice, because it took me thirty years and a robot to notice it.
When she was done, the record showed the right number. And a record where she'd corrected something looked exactly the same as a record where she hadn't. Identical. Same fields, same values, no mark on it anywhere.
Which meant nobody ever found out the master file was going stale. Not because anyone was hiding it. Because there was nowhere for it to show up.
The same job, handed to a machine
A few weeks ago I had a few hundred rows to enter into a form. Same shape of work. Pick the item, and the form fills in what it already thinks the price is. My paperwork says what the price actually is. When they disagree, the paperwork wins.
I gave the job to an agent.
And a machine can't do what she did.
A person looks at a pre-filled number, decides in a quarter of a second that it's close enough, and moves on. That's not carelessness. That is exactly what a filled-in default is for. If you stopped and audited every pre-filled field on every screen you'd never finish anything. Accepting the default is good judgment, and a person does it correctly a hundred times a day.
The machine had no way to do that. It had no feel for "close enough." Every single field, it had to look at what the form said, look at what my paperwork said, and make a call it could justify.
That sounds like a weakness. People complain about it constantly — the thing is pedantic, it needs a rule for everything, it can't just use its judgment.
But because it couldn't skim, it caught something.
About a quarter of the rows had a stored price that didn't match the paperwork. Not one or two. A quarter.
Nobody at that shop knew. Not through anybody's fault. Everyone doing the job by hand had been doing what the operator did — seeing it, fixing it, moving on. The correct thing, a hundred times over. And every correction disappeared the second it was made.
The machine found it by being unable to look away.
Then I nearly lost it
Here's where I almost made the same mistake the mainframe made.
I finished the batch. The form was filled in, the total came out right, everything checked. A clean piece of work.
And it showed me nothing. Same as her record. A price I'd corrected and a price that was right sat there looking identical, because that's what a finished form is — it's a list of answers. It doesn't keep the arguments.
The most useful thing that whole job produced only existed while the job was happening. Once it was done, it was gone, and all I'd have had left was some hours saved.
So I made it write them down as it went. Every time it disagreed with the form: what the form said, what the paperwork said, which one won, and why. Written at the moment of the decision, not reconstructed at the end.
That last part matters more than it sounds. I tried reconstructing it at the end and I was wrong about my own work within the hour. You don't remember a decision you made two hundred rows ago. Neither does the machine — its memory of the early part of a long job gets compressed away as it goes, same as yours.
Why I care about this more than the time it saved
Nobody is going to re-check a few hundred rows. Not me, not the person whose job it actually is. So a finished form you can't verify is a thing you either trust completely or don't trust at all, and neither of those is any way to run something.
Thirty rows, though — anybody will check thirty rows. Five minutes.
The list of disagreements is what turns a job you can't check into a job you can. That's the whole value of it. It isn't a report anyone asked for. It's the thing that makes handing the work over safe in the first place.
I don't think this is special to forms. Any time you hand a real piece of work to a machine, what comes back is the finished thing, and finished things don't show their arguments. A batch of edited code doesn't show you the three places the old code contradicted its own documentation. A moved pile of data doesn't show you which rows were judgment calls. The work is the answer sheet. Everything interesting happened on the scratch paper and the scratch paper got thrown out.
So the question worth asking about any job you delegate is a plain one. Where does this hide its judgment calls, and how do I get them out?
The part I got wrong
I should tell you that I got ahead of myself in the middle of this.
After the first few batches I saw a pattern — the stored prices were always low, never high. I said so. It seemed obvious.
Then a later batch went both ways and killed it dead. Some too low, some too high, no pattern at all.
If I'd stopped after the first few batches I'd have handed over a confident, tidy, wrong conclusion. Which is a worse outcome than handing over nothing, because a tidy wrong conclusion gets acted on.
Write down what happened. Work out what it means last, and only when it stops changing.
Back to her
She was doing this the whole time. Every day, for years. She caught the drift between what the system believed and what was true, and she fixed it on the spot, and she was right to.
Nobody ever asked her to keep a list of the ones she typed over. So nobody knew there was anything to know.
That's the part the machine gave me. Not the hours. The chance to ask a question that nobody had been in a position to answer.