4 ms·

Sure. And if you happen to actually venture into that low end of the stack, you learn. But the idea that you should know everything, just in case (or just becau

Sure. And if you happen to actually venture into that low end of the stack, you learn. But the idea that you should know everything, just in case (or just because us olds had to learn it) is extremely wasteful. I use a black box (car) to get around, and I'm fine with that. I didn't need to learn more than "change oil", "inflate tyres", "how to (dis)connect a battery". I'm good. I use a black box (TV) to view my entertainment content. All I know is "cycle the power so it works again". I treat my computers the same. Yes, I've built multipliers from individual transistors, and I've seen and used the blinkenlights, and I've written entire kernels and networking stacks: I don't need it much these days. And if I need it, guess what, there are still people who make it their business to know all the things, and I'm happy to give them money so they can figure things out. (Because most of that knowledge has collected dust by now) We spend our mental capacity where it's needed. Not everything is equally important, and abstractions exist so not everybody has to learn everything. (I mean, you don't fab your own ICs either, do you?)

deathanatos 4y ago
Where the car analogy breaks down is the mechanic. If the mechanic can't reliably fix my issues, I'm taking my business elsewhere. If the cloud provider doesn't … well it takes a lot to move a stack to a different cloud provider. And what matters is results: sometimes with a car, I need to know a bit about how the car functions in order to help the mechanic. If I know more, I can sometimes point the mechanic in the right direction. And sometimes, you're broken down on the side of the road and you don't have a mechanic, and you need "how to change tires", "how much force is too much force on a lug?", "how to jump", "how to repair/replace battery enough to get to the mechanic". Sometimes, I get better answers from cloud provider if I can describe to them exactly where they've gone wrong. > and abstractions exist so not everybody has to learn everything. In an ideal world. Problem with cloud stuff is that support is usually dumb as bricks, and the only way to get anything done is to break the glass on the abstraction & get your hands dirty.
- nprateem 4y ago
  But junior devs aren't expert mechanics, they're more like delivery drivers. You're the mechanic and in a few years some of those drivers will graduate there, others won't. AWS support has always been excellent IMO and highly technical if required.

deathanatos 4y ago

Where the car analogy breaks down is the mechanic. If the mechanic can't reliably fix my issues, I'm taking my business elsewhere. If the cloud provider doesn't … well it takes a lot to move a stack to a different cloud provider. And what matters is results: sometimes with a car, I need to know a bit about how the car functions in order to help the mechanic. If I know more, I can sometimes point the mechanic in the right direction. And sometimes, you're broken down on the side of the road and you don't have a mechanic, and you need "how to change tires", "how much force is too much force on a lug?", "how to jump", "how to repair/replace battery enough to get to the mechanic". Sometimes, I get better answers from cloud provider if I can describe to them exactly where they've gone wrong. > and abstractions exist so not everybody has to learn everything. In an ideal world. Problem with cloud stuff is that support is usually dumb as bricks, and the only way to get anything done is to break the glass on the abstraction & get your hands dirty.

nprateem 4y ago
But junior devs aren't expert mechanics, they're more like delivery drivers. You're the mechanic and in a few years some of those drivers will graduate there, others won't. AWS support has always been excellent IMO and highly technical if required.