Hacker News new | past | comments | ask | show | jobs | submit login

But when the black box stops working, how do you find out where to look to fix it? I get that the start of the art is advancing ever onward...but there's still a MAC address involved...waaaaay down the stack.



I am in the same kind of ball park as OP. Been doing sysadmin for a long time, and I teach at the university too... see a lot of students graduating and their network skills are weak. Bad troubleshooting skills at linux/unix fundamentals.

When I talk to friends doing sysadmin work about this, they kind of gravitate towards: "I throw this in AWS, need k8s, terraform, cloud-whatever-hot-tech, etc, and if it breaks, my json/ansible/CI/CD will just restart it" as the prevalent attitude now.

I feel OP, but I do wonder if we are just moving to a space where people do not optimize/troubleshoot at that level? I do a LOT of hands on grunt work, performance optimizing servers / kernels / networks, but I am at a university. I think my skills are probably worthless in todays "real IT" world. (which is sad, I would love to get a new job :)


The optimizing end is still valid right?

Unless you're doing serverless (which, of course, more and more of us are).


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?)


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.


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.


I get so excited thinking about the opportunities that will arise over the next 10-20 years for people who understand the lower-level (or are willing to figure it out) well-enough to clean up the AWS mess.


Yeah sorry I regret posting the comment, was a bit snarky. I've been working 25 years now. Everything is different now. I dont understand a lot of where infrastructure is going, it seems every year more complicated and expensive with little upside. I do think people are interested in your deeper knowledge, but it isn't the green people. Its the guys doing 2-3rd line support for more advanced problems. They're likely overwhelmed already though, everyone is drowning.


While there is a movement to serverless codeless whizbang cloudhosting....I think it's over represented on HN. There's still a ton of Enterprise IT that's hasn't made the transition, and it's often being managed by green staff.


I really wish there was a "no bullshit guide to cloud" that describes how it works behind the scenes - stuff like what a "serverless VPC connector" really is behind the scenes.

Sadly the only people who could write such a book are likely under NDA from the cloud provider.


Just deploy a second black box and load balance them. (I wish this was sarcastic.)


But that's the point isn't it. Stuff has become more commoditised so people don't need to care unless it keeps breaking. Then they call in the handful of contractors with the 10+ years experience to fix it


That's why you have junior and senior devops staff.

Juniors do the stuff as it should work, seniors troubleshoot it when stuff doesn't work as advertised.

Interested juniors learn from seniors and become seniors themselves, uninterested/unmotivated stay juniors


Turn it on and off again.


That will leave the system turned off?! I mean no code, no bugs, but still...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: