I somehow agree with this. As a web developer who started on a framework first approach (Vue + Django), I was having one hell of a time trying to figure things out because of my lack of fundamental knowledge. I think abstraction is okay but you have to understand that just because you can make abstractions doesnt mean you should.
We have used too many levels of abstractions
11–20 of 564 posts
Re: We have used too many levels of abstractions
#12I 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 the problems and logic behind all those new solutions. Understand how we come to have JavaScript and the browser mess we are in and so many other curious features of todays digital world.
I understand pretty much all of the layers of the computing from how CPUs achieve some of the things they are doing to bus protocols, to instructions, physical memory, low level OS internals, high level OS internals, virtual memory, userspace platform communication with OS, programming language runtimes and linking, shared libraries, IPC, networking, virtualization, etc.
The issue, as with any automation, is that new players on the scene (younger devs, devops, etc.) simply have no chance to learn the same things and go trough the same path.
For them, spending a decade working with a low level programming language before you jump into high level programming language is simply not an option.
We, people who really understand the technology that the world runs on, are a slowly dying breed. We are still here as tech leads, managers, directors, business owners. But there will be a point in time when we will go on retirement and there will be only precious few people who had perseverance to really understand all those things by diving into obscure, historical manuals.
Re: We have used too many levels of abstractions
#13I support the notion of this post. In the last 6 years I’ve mostly been busy removing layers of abstraction in order to uncover the set of tools which is a good balance for me. In example, replaced clojurescript with Javascript and then eventually Typescript. Replaced Clojure with Java. Replaced docker with VMs. Avoided ansible in favor of simple bash scripts. Avoid all kinds of firewalls in favor of understanding an…
Whilst I agree with most of this:
> Replaced docker with VMs
This doesn't make sense to me, as Docker and VMs are not the same thing. Replace LXC with VMs, sure.
Re: We have used too many levels of abstractions
#14I think there is a fundamental issue with the article and that's the author stating devops or devsecops is someone taking care of both development and operations. That's just not true.
Re: We have used too many levels of abstractions
#15I 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…
My dad was absolutely saying the same things 25 years ago about integrated circuits in e.g. car engines.
Re: We have used too many levels of abstractions
#16Increases in the levels of abstractions are necessary. The human brain doesn’t become much more capable over the years, but the number of available tools does so you need abstractions to allow for focus. I don’t see why this makes the future bleak per se. A programmer working on a business problem can be extremely productive in a high-level language even without understanding EUV, compilers, assembly, instruction sets, kernels, USB protocol, HTTP, dies, substrates, and much more. The same holds for pilots. They don’t need to know everything about aerodynamics, tensile strengths, aluminium, rubber, GPS, and much more.
However, a discussion over the misalignment of incentives in modern society can definitely be had. I would trust the pilot generally much more than a business software developer, researcher, or banker because the pilot will be the first to arrive in a crash.
Re: We have used too many levels of abstractions
#17This is an insightful article, although I don't necessarily agree with the view that "everyone" needs to know everything from first principles to be good at their job.
Talking about abstractions, during my past month, I was reading nand2tetris, and it's a compelling experience if you understand the exercise you are doing, which is not about building a computer from first principles; it's much more than that.
It makes you really understand what's going on behind the layers of abstracting that have been raised. Sometimes, understanding every layer of complexity is impossible, but depending on the area you are in, we need at least to try to understand the roots of it.
However, this is not for everyone; ask a musician if they are really in the weeds of why the instrument is producing music (the physics behind it!). They are probably aware that it's vibrating air, but, in general, they won't know the theory behind it.
Everything is built on abstractions, and that's OK, with time we will add even more on top of what we have; now, the issue is when those abstractions lock you in with a mindset that prevents you from creating something new without relying on those same abstractions that help you build stuff.
Many discoveries and inventions were made because they knew the layer of abstractions on top of it, and they just started again from scratch. Even Figma, the software, is built on a new core of concepts based on how the web was working back in the time [1]
[1] https://madebyevan.com/figma/introducing-vector-networks/
Re: We have used too many levels of abstractions
#18While I agree with the sentiment, I also struggle to find the right approach of peeling back abstractions and understanding the lower levels. Learning how something works under the hood takes time and can be a big commitment. How to do decide when to look below the abstraction? I’m most often interested in how things work under the hood, but I can’t always dig deep, which does bother me.
Re: We have used too many levels of abstractions
#19> It was clear, just by looking at how bad everything was performing, that something was wrong.
Meh, zoomers didn’t invent incompetence and slow, ugly software. Not everyone is cut out to write aerospace grade software and, thankfully for those people, not everyone needs it.
Re: We have used too many levels of abstractions
#20Sometime i just want to use old school copy code build binary to server and run it :).