Yeah, that's a fair distinction. Another subtle thing with it is that, while I'm writing code in whatever scripting language I do think about what's going to b

Yeah, that's a fair distinction. Another subtle thing with it is that, while I'm writing code in whatever scripting language I do think about what's going to be happening under the hood non-stop. For example, every time I write a line of activerecord, I'm thinking of what kind of SQL is likely to be emitted, and whether or not it'd even be possible for the database to have an index for the query. Sometimes a table scan is the best you can do without denormalizing and its awesome to notice that right away instead of down the road when it's slow. But this all is both a blessing and a curse. Often it ends up meaning that I spend more time thinking about a problem than I need to. Another fun example from some recent work: a client calls me up and has a machine that they can't access. More probing reveals that the machine is buried under a frozen highway! (I'd love to go into way more detail but... NDA) Anyway, we do still have an RS485 link to it, with getty running. The goal was to determine whether it was a software problem (fixable without needing a backhoe in 4 months when the earth thaws), a hardware problem, or a cabling problem. How do you know for sure? Jump into the bootloader and configure the ethernet phy to tell you what it sees by directly writing registers over MDIO! Turns out the PHY is alive and well, but can't seem to see the 100MBit sync pulses. Plus it is still successfully doing PoE negotiation. The cable is still connected but either the switch, the cable or the magnetics are bad. Field guy is going to try a new switch before we abandon all hope, but at least we know that no amount of software fixes will solve the problem