I took drafting in high school. Three years of it. The first semester was entirely by hand, before they moved us to CAD. At the time I didn’t think much of it, but looking back, that sequence mattered. The point of the class was never to learn AutoCAD. The point was to learn drafting. Creating plans, schematics, blueprints precise enough that someone else could build from them. Hand-drafting first meant that by the time I got to the software, I already understood what I was trying to produce. The tool just made it faster.
I think about that class a lot lately.
I got going in tech around 2010. Self-taught Linux, picked up capabilities without much context for what to do with them. It wasn’t until I landed my first real job, as a student tech, that I started to apply any of it. From there I moved into automating as much as I could. Scripts, Chef, custom code, whatever made the repetitive parts go away.
The thing that made all of that work, in retrospect, wasn’t the automation tooling. It was that I’d spent time in the weeds first. I knew how Unix signals worked. I’d worked on hypervisors, storage systems, networking gear. I have a much greater depth of understanding about how the internet actually works than people who showed up post-cloud, and that’s not a brag, it’s just a function of when I came up. I had to learn that stuff because the abstractions hadn’t been built yet.
A concrete example
Here’s a concrete example of what I mean. Years ago at Rackspace, we were helping a client roll out a new microservices-based application. We got it loaded onto the server and nothing worked. The app was just silently failing. No logs, no errors, nothing useful to go on. The client’s team couldn’t figure out what was happening, and from the outside there was nothing to figure out. The application wasn’t telling anyone anything.
A couple of years before that, I’d spent time on Open Solaris storage systems and gotten fascinated with DTrace, which got me reading about syscalls in general. So I knew there was a layer underneath the application I could look at directly. I straced the process, watched what it was actually doing at the syscall boundary, and found the failure. If I remember right, it couldn’t write its logs, which was why we weren’t seeing anything from the application itself. The client fixed it and we shipped.
The thing I want to point out about that story is that strace wasn’t some exotic tool I had to go discover in the moment. I knew to reach for it because I’d been curious about something completely unrelated years earlier. The knowledge was already there waiting, and the only reason it was there was because I’d done a lot of slow, undirected learning about how the layers underneath actually worked. None of that learning was efficient. None of it was assigned. It just turned out to be the thing that solved the problem when the abstractions failed.
That context turns out to matter more than I realized at the time. A lot of engineers who came up entirely post-cloud are sharp and they ship fast. But there’s a category of problem where the wheels come off, and it’s always the same category. Something is wrong below the abstraction layer they were trained on, and they don’t have a model for what’s underneath. They may know how DNS works as it relates to whatever cloud tooling they use, but they may not understand how DNS actually works, including on their own machine. When the tooling can’t explain the failure, they’re stuck.
I do my best to close out gaps in my own knowledge about systems that showed up before my time, for the same reason. I want to understand the context of how we got here. Having that depth means I’m not beholden to any single tool that just manages things on my behalf. At the end of the day I know it’s not magic, and I can work around things when I need to.
This is the part I’ve been turning over.
Where judgment came from
The slow work wasn’t valuable on its own. It was the substrate that the judgment grew out of.
The traditional way you became an expert in this field was that you spent years doing tedious work, and somewhere in the middle of all that tedium, judgment kicked in. You’d seen enough broken systems to recognize a broken system. You’d written enough bad code to know what bad code felt like before you finished writing it. The slow work wasn’t valuable on its own. It was the substrate that the judgment grew out of.
AI is very good at removing that slow work. That’s most of what people are celebrating about it right now, and reasonably so. But I keep coming back to the drafting class, because the drafting class is the one place I can think of where someone made a deliberate decision to preserve the slow version even after the fast version existed. And they were right to. I don’t know if anyone is making that decision now, in any field, on purpose.
If judgment came from the slow work, and the slow work is going away, where does the judgment come from instead?
So here’s what I’m actually wondering about. If judgment came from the slow work, and the slow work is going away, where does the judgment come from instead? Is there a different substrate that grows the same instinct? Do people develop it faster because they’re freed up to work on harder problems earlier? Or do we end up with practitioners who can produce competent output across a wide range of tasks but have judgment-shaped holes in places they don’t know to look, and won’t know until something breaks in a way the tool can’t explain to them?
I don’t have a clean answer. My whole career is an argument that the slow stuff matters and that the people who skipped it are missing something. But “the way I learned was the right way” is the laziest possible position for someone in my position to hold, and every generation says some version of it about the one that came after. Maybe the kids are fine. Maybe they’re developing a different kind of judgment that I’m not equipped to recognize because it doesn’t look like mine.
What I’d want, if I were designing how someone learned this stuff today, is something like the drafting class. Not because I want to make people suffer through the slow version for nostalgia’s sake, but because I want them to encounter the thing the tool is a tool for before they encounter the tool. I want them to know what they’re trying to produce. I want them to have at least one experience of doing it without the magic, so that when the magic fails, and it will fail, they have somewhere to stand.
Whether that’s actually how expertise gets made now, or whether it’s just how it got made for me, I don’t know yet.