GoKawiilTom Hartmann had not planned to become a Software Mechanic. But then, nobody who was a Software Mechanic had planned to become one, because the job hadn’t existed seven years ago, and the people doing it had all been something else first.
This was true of most professions in the post-transition economy, and it had been true of most professions after containerization, and after electrification, and after the printing press, and probably after the invention of bronze. The first blacksmiths had not grown up dreaming of blacksmithery. They had been people who were good at hitting things with other things and who noticed, at some point, that metal responded interestingly to being hit. The first Software Mechanics were people who were good at diagnosing the gap between what technology was supposed to do and what it actually did. A skill that, before the transition, had been called “IT support” and had been compensated accordingly, which is to say: badly.
Tom had been an agricultural equipment technician, which meant he’d fixed tractors, combines, GPS guidance systems, and the increasingly complex control software that made modern farming possible. He’d worked for a John Deere dealership in Marshfield for eleven years. Then the transition happened, and the dealership’s software repair business evaporated; the machines still needed repair, but the software on the machines stopped being something you repaired. You regenerated it. You typed what you wanted, it appeared, and if it broke, you typed it again, which is to say: the concept of “broken software” had been replaced by the concept of “an inadequate specification,” which was the same problem wearing a different hat but which required an entirely different person to fix it.
The hardware still needed fixing. Engines, hydraulics, electrical systems, and so on. These remained stubbornly physical. But the software layer, which had been an increasingly large portion of Tom’s work, had been replaced by a churn of generated tools that his clients produced themselves, configured themselves, and broke in ways that were entirely new.
So Tom had adapted. He’d taken the certification course (eight weeks online, practical exam at a regional testing center) and hung a new shingle. HARTMANN SOFTWARE MECHANICS, it read, below the original sign that still said HARTMANN EQUIPMENT REPAIR, because he still fixed the physical stuff too, and because in a farming community nobody cared about the distinction between software and hardware.
This was, in miniature, the death of a distinction that had organized the entire technology industry for fifty years. “Hardware” and “software” had been separate disciplines, separate companies, separate career paths, separate worldviews. Hardware people understood atoms. Software people understood bits. The transition had collapsed the distinction, because when software was generated from plain-language specifications, the relevant expertise was no longer “software”, it was whatever domain the software was for. A Software Mechanic in a farming community needed to understand farming. A Software Mechanic in a medical practice needed to understand medicine. The tool had changed. The domain had not. People who understood the domain and could also diagnose specification problems were the most valuable people in any industry, and most of them, like Tom, had arrived at the job sideways from something else.
His shop was in a corrugated steel building on Highway 29, between a feed store and a Laundromat. It had a waiting area with four plastic chairs and a coffee machine that Tom had specified himself and which made coffee that was, by consensus of his clients, exactly adequate and no better. He’d tried to improve the spec three times. Each time, the regenerated firmware made the coffee subtly worse in a different way. He’d eventually concluded that coffee machine specs existed at the exact intersection of fluid dynamics, thermal management, and taste (three domains where natural language was particularly poor at capturing the relevant distinctions) and had stopped trying. He had, however, found a use for it: when new clients came in insisting that the software they’d generated was “basically fine” and “just needs a little tweak,” he would gesture at the coffee machine and say, “I’ve been trying to get that thing to make decent coffee for two years. You think your sixty-parameter irrigation optimizer is going to be simpler?” This was usually effective. People understood coffee.
It was a typical day in October, and the morning’s appointments were typical.
The first client was Margaret Brennan, who farmed 340 acres of cabbage and sweet corn in the county and who had, six months ago, generated a custom harvest-timing tool that integrated soil moisture data, weather forecasts, market prices, and satellite imagery to recommend optimal harvest windows.
The tool had worked beautifully through the summer. It had saved her, by her estimate, about $40,000 in better timing decisions. Then, last week, it had recommended harvesting a 60-acre cabbage field four days before the heads were ready, and the resulting early harvest had cost her roughly $25,000 in undersized product.
... continue reading