Practical Magic

Steve opens with a Jack Vance fantasy scene — castle defenders slaughtered because the old butler who's spent his life polishing the cannon with fine wine and the softest cloths can't make it fire when the castle is under siege — and uses it to set up the question every working engineer is implicitly answering: how far down the stack do you need to understand the machinery before it's honest to call the rest magic? He draws his own line publicly. Below the doping barrier in a semiconductor — a class he nearly failed under a famously senile professor who weekly raved about the Amazing Human Eye — it's magic, and he's fine with that. The compromise is the durable bit. You can use any abstraction, Steve argues, as long as you can: describe roughly how it was built; install it yourself or have a backup; reason about how its performance and reliability degrade under pressure; and know where to look or who to ask when it stops working. Applied to his own stack: OS axiomatic, JVM tolerable, J2EE too much magic — it lets you snap together an enterprise architecture after one introductory course, and that's the wrong amount of power to hand out.

The closing observation is the gentle one: the Line of Acceptable Magic is slowly moving up year by year, the way it has already moved up past the toilet. Old hands kick and scream as new abstractions become reliable enough to take for granted; they're usually right that something is lost, usually wrong about whether the gain is worth it.