Live data from Hacker News

We have used too many levels of abstractions

unixsheikh.com

71–80 of 564 posts

Re: We have used too many levels of abstractions

#71

I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…

One mitigation of the “mastering computers takes 30 years” thesis is that many of the abstractions and technologies that we spent those decades learning are now obsolete, and newly minted grads are blessed with learning materials and environments that make catching up easier than ever.

Re: We have used too many levels of abstractions

#72

Earlier quoted context omitted.

That's what I mean by "precious few". I am continuously hiring new people, mostly senior devs and tech leads. Maybe one in a hundred has any understanding of what virtual memory is. Or why one process can't access memory of another process and, if you really want it, how to set it up. Two decades ago that was common knowledge. It went away just as the knowledge of how networking works. Currently, if they try to open…

Im from the new breed. I'd like to know all that but, where do I get the money? It's not like I can spend so much time tinkering without producing. If at least was able to purchease a home I wouldnt have this pressure. I guess in the US is different because people have higher salaries. You have to have the time/resources to dive that deep. Or maybe it's your job, line some of the folks in a local company that work in…

This is literally free knowledge spread across many MOOCS, YouTube videos and Unix man pages. You can tinker with it with a Raspberry Pi.

Finding time to learn if this is not your day job is another problem, but a solvable one if you're willing to learn.

Re: We have used too many levels of abstractions

#73
Great article. Reminds me of a boss I had early in my career, who would get a bit nervous if you asked any questions about the details of what we were actually doing. I later found out it was because he just copied the procedures used at his previous employer. “We do it this way because we have always done it this way” kind of deal. I wondered why any suggestions of doing things differently fell of deaf ears. Thankfully my next boss was excellent technically and was happy to change our procedures if it would make life easier.

Re: We have used too many levels of abstractions

#74
>Today programmers and system administrators no longer exist, instead we have DevOps and even DevSecOps, in which the industry is trying very hard to stuff every single task into the job description of a single individual.

Nice to know I'm not imagining this. Platform Engineers seem to be going extinct, with the Software Engineer taking over the role, and doing it badly.

Re: We have used too many levels of abstractions

#75
post #39

> Question everything. Especially things that don't make any sense to you. Don't just assume that someone else knows better - that's how you quickly turn into a blind follower. That’s what I do by default since I was a kid, and I can tell you the social pressure not to is significant. I recall an interview I did once, and one reason I failed it was "questioning everything". It didn’t even felt like it, I was just ask…

Questioning everything also gets you stuck in bed asking why the sky is a different shade of blue. Others might have accepted the unknown and ate breakfast.

Personally, I find pithy comebacks like this to sound convincing to but to actually be mostly devoid of utility. They tend operate as a sort of social persuasion tool, but I'd like to Get Things Done, which requires deep domain knowledge.

One thing I've been noticing with my current clients is the vast amount of churn generated by them only having a patchwork understanding of their overall architecture. Some grok the low-level infra, some the deployment levels, others the backend pieces, and others the frontend stuff. However, since there is no story collecting the pieces into a cohesive whole, we see them treadmilling through different tech stacks in an attempt to gain "velocity". They're definitely running fast; it's just they're not getting anywhere very quickly.

It's a pattern I see a lot. On the flipside, when clients have devs who mostly grok the entirety of their system, then we can focus on the questions that really matter: purpose, market fit, empirical evidence from users, _etc._

Questioning things costs time right now, not questioning costs 10 times that in the future.

Re: We have used too many levels of abstractions

#76

Earlier quoted context omitted.

There will always be hyper-nerds and just super smart people who will study all of the low level stuff. Granted, they will be vastly outnumbered by high level programmers.

That's what I mean by "precious few". I am continuously hiring new people, mostly senior devs and tech leads. Maybe one in a hundred has any understanding of what virtual memory is. Or why one process can't access memory of another process and, if you really want it, how to set it up. Two decades ago that was common knowledge. It went away just as the knowledge of how networking works. Currently, if they try to open…

How often does a front-end developer need to know about /proc/pid/mem?

I think it's important to keep things in perspective here - when I took my first programming job the first week was setup. On my team, our onboarding has you branch, review and merge on your first day. Those abstractions allow for people to focus on the areas they're working on, and iterate there. A game developer doesn't need to understand the complexities around js type conversions, any more than a js developer needs to understands rendering thread latency in a browser.

On every team I've ever worked on, that headspace from the team would have been much better served by understanding the product and project, IMO.

Re: We have used too many levels of abstractions

#77

I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…

> spending a decade working with a low level programming language before you jump into high level programming language is simply not an option. Nobody said that. But spending a week is definitely an option to all programmers, and many would benefit from it.

You can get ahead very far with a 16h free course on kernel development

https://training.linuxfoundation.org/training/a-beginners-gu...

A motivated person can run through it in a couple weeks while working a day job.

Re: We have used too many levels of abstractions

#78

One thing to keep in mind is that software for a dialysis machine requires a different approach from some overly generic CRUD app exposing how many mansions you have or something. There is a lot of asinine software in the world and that’s fine. Lots of “real problems” are pretty asinine and don’t require heroic engineering feats. Just slapping some bullshit together is good enough in a frightening number of cases. Ha…

> Software for dialysis machines A sizeable percentage of which is made without source control, unittests, and just slapped together like the rest you described Hospitals don't check software quality when making purchasing decisions (much beyond "this button doesn't work")

> Hospitals don't check software quality when making purchasing decisions (much beyond "this button doesn't work")

This! The worst piece of low quality garbage I've seen from the inside is hospital software. Nobody really cares or understands software on the hospital side, so anything goes. The product is inherently complex, so there are only a small number of large companies who don't care either since they can rely on customer lock-in, no matter how crappy their service is.

Re: We have used too many levels of abstractions

#79

Earlier quoted context omitted.

That's what I mean by "precious few". I am continuously hiring new people, mostly senior devs and tech leads. Maybe one in a hundred has any understanding of what virtual memory is. Or why one process can't access memory of another process and, if you really want it, how to set it up. Two decades ago that was common knowledge. It went away just as the knowledge of how networking works. Currently, if they try to open…

Im from the new breed. I'd like to know all that but, where do I get the money? It's not like I can spend so much time tinkering without producing. If at least was able to purchease a home I wouldnt have this pressure. I guess in the US is different because people have higher salaries. You have to have the time/resources to dive that deep. Or maybe it's your job, line some of the folks in a local company that work in…

One little-appreciated fact is that many of the most accomplished and knowledgable engineers were tinkerers from an early age. If you start your computing journey at the age of 18 with a compsci degree, you might already be a decade behind some of your peers.

It’s not too different from pro tennis players, who typically start playing before the age of 8.

For those at the top of the game, computing is a calling as much as a job. They will do substantial learning on their own initiative.

Re: We have used too many levels of abstractions

#80

I feel like if I was alive and working 60 years ago I would have been saying the same thing about mechanics, construction, and analog electronics. But really it doesn't matter for most jobs. Knowing how things work underneath is needed if you are forming your own business and products from the ground up, it is only slightly useful if you are working for somebody else, and as time goes on what monetary value there is…

There are some things you need to know though. For example most devs today "know" Docker, but very few realize that it opens the exposed ports on the host firewall. Exposing a port for another service to access internally is intuitively safe, until you look at the box and realize that same port was opened to the internet. Convenient thought the docker devs, but touching something so important without feedback is reckless. That's an abstraction that absolutely shouldn't be there, too many devs don't RTFM.
Post reply on HN