We have used too many levels of abstractions

Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane and building it are separate skillsets and jobs. After all, we are comfortable with aviation engineers designing the aircraft without knowing how to mine the bauxite, smelt it to aluminium, and machine it into aircraft parts.

As comforting as it is to have an overview of how to trace a complete path from logic gate to web request, it isn't necessary. The decrease in the number of engineers with that overview isn't a cause for alarm, or a problem to be solved. It is just a sign that "tech" has matured, and it is stratifying into a set of interlocking disciplines. The same happened with every other subject in human history, and we've been just fine...

People assume that because their phone/laptop is locked down and unable to spark curiosity that it must be the same for kids today, but I think they just become a little more un-curious themselves.

Yeah it's built on some abstractions, but I do think there's some valleys among the tall abstraction mountains that the curious few venture into, just as it's always been.

Yes, c64 BASIC lets you POKE at any memory address you want, but I was getting a pitch about a complex 3D collect-a-thon with FPS elements, from a 10 year old. That's also kind of cool.

Yes some people are experts and some are just adequate. Nothing new here. Not everyone can be a messiah like the author, who spends half of this short essay telling us how great he is.

This article has almost nothing to do with abstraction. The author loses interest in his own thesis after the first two paragraphs.

I know the current mainstream state of the art is inefficient for sure because I've built an SDK which I use for my own projects and I'm at least 10x more productive with it than with mainstream frameworks I used during my day job and the code is way easier to read and maintain. I could show the code to a junior dev who doesn't know any frameworks and they will be productive with it. I wrote a no-code BaaS (Back end as a Service) platform in 2 months part time using my SDK. I highly doubt I or anyone else could have done this in 12 months full time using mainstream tools and frameworks.

This resonates with me strongly. Everyone seems to know how to do things by rote memorization ("to do X, add this line to your config file") but nobody knows how to go off-script if you need to do something slightly different (not-quite-X or a variation on X). Worse, people will waste your time trying to steer the conversation away from not-quite-X back to X. (Insert the parable of the man searching for his lost wallet under a streetlight because that's where the lighting is best.)

The internet of 1995-2005 was built on mediocre solutions. It was a blast.

Deep-dive experts are not a dying breed, they're not a limited resource with secret knowledge from a time before abstractions. We have more of them now than ever before. They're not defined by having worked all the way up and down the stack, but by having the curiosity to look into layers that are not their own, because not only are we adding more abstraction layers on top, we're also changing some of the layers down the stack: NVMe, WebGPU, WebAssembly, QUIC, AVX512 !

But deep-dive experts are a luxury that most teams don't need, and one of the most important skills of a technical manager is, I would argue, to know when they absolutely must hire one.

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.

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.

Hate it too myself, but I have come to accept I can either prove them wrong by building my own business and outcompeting them through my supposed superior engineering or just swallow that I’m yelling at the clouds.

> Some students today apparently don't even know what files and folders are

…to a slashdot thread that links to a PC Gamer article that rephrases and links to a Verge article that links to Stack Exchange questions.

[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...

Imagine if Kubernetes was closed source & binary distribution only. Understanding abstractions is, I think, why being open source has become table stakes for infrastructure software.

Google -> you don't need a longterm memory, just Google it.

So with good LLMs (and the latest iteration of chatgpt is really good at a lot of things you don't want bore yourself with), you don't need to process logic and abstraction as it will do it for you.

This is not yet there for everyone but I think it will work the same. Lazy the mind and have less and less rigor where the abstractions get more abstract and also more shallow.

My entire career so far i spent trying to get onto teams where others were doing the same as me but had more experience. In the years i spent on those teams i learned a lot. But as time has gone on a lot if those people have left into management which just isn’t the same as directly working with them on problems. I actually have also done the same recently.

When i look at almost anyone today they have no desire to understand what is going on with the tools they are using. Further more most of upper management pushes me to enable this by building more abstraction on top of abstraction they do not understand so when it breaks I or my team can fix the actual issue. Ensuring the developers have an easy out for anything that is outside knowing their framework and some basic syntax.

I always wonder if people felt the same way about me if they came from a background where they had to know assembly or other lower layers of the stack. At any rate even in the current environment I haven’t been worried about finding new work if needed. Their seems to be a very short supply of people anymore who know how things work under the hood or even have a desire to figure it out when it breaks.

I am a pretty firm believer that antilock brakes are a bad abstraction that might cause fewer accidents, but often more dangerous accidents than they prevent.

They avoid a class of accident caused by the brake’s locking limiting your ability to steer. They cause a whole class of accidents where you hit things at a higher speed than you otherwise would have because your ability to actually slow down is greatly diminished. It’s a trade of braking distance for control. Basically we’re prioritizing rapidly swerving around an obstacle over less controlled but far more rapid deceleration.

I really don’t think this trade off makes any sort of sense in anything but the most sparse rural environment. In urban and suburban areas, swerving blindly around an obstacle will just mean hitting something else. Yes, you missed the car that pulled out in front of you but now you’re either throwing your vehicle into pedestrians on the sidewalk or into oncoming traffic. Both cases likely a far worse outcome than the accident you are taking evasive actions to prevent. The sanest option becomes just to hit the obstacle you would have been able to stop for were it not for antilock brakes.

In my eyes, the most fundamentally frustrating part, and what makes them a bad abstraction, is that the problems antilock brakes solve are entirely preventable by human intervention. Namely, pumping the brakes. The class of accidents antilock brakes cause are largely unavoidable. You can stop lessen their affect by not fully depressing the brake but it is still a much longer deceleration than no antilock brakes at all.

Priesthood. See: Foundation by Asimov.

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/

Not all technology feeds into the cycle of tool bloat, we just need to get better at choosing our tools wisely instead of letting somebody's marketing department influence our decisions.

This is what happens when you turn Engineers into Devs. Software Engineering used to be viewed more as a profession but orgs have been chasing the holy grail of commoditizing software development. It’s not assembly line work and never will be.

I've worked in software QA also and abstraction is the bane of debugging, especially when you can't even see the code in the libraries you're using. Proprietary binary blobs in embedded systems are the worst.

Every generation has some people more interested in the depth of their field than others. So why do we see fewer of the actual experts?

Well, we don't, we just see more of the surface level developers being able to contribute real economic value to society. They were just kept out by the more demanding requirements before.

If anything, it's a good sign we've come to have this luxury problem.

- how does it really work?

- what are its dependencies?

- what are its failure modes?

- what are its side effects?

- why are we doing it this way?

- how long will it keep working?

- are there any alternatives?

- if so, why aren't they in use?

- and what can we do about it?

This is particularly crucial with regard to materials and energy, as well as social norms, societal institutions, and cultural expectations.

Not to say that OP is incorrect. But intelligent people were opposed to abstraction already in ancient times. Socrates said about the invention of writing [1]

> For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them.

From today's perspective it seems absurd to oppose written information. The net benefit on society is clearly positive.

I am not saying that every abstraction is a net positive. But the example demonstrates that it is easy to oppose abstractions, even if they turn out to be positive in hindsight.

[1] https://www.historyofinformation.com/detail.php?id=3439

Sound advice imho:

"If you understand the nature of the beast, you know what it's capable of."

Rarely -if ever- necessary to know all the gritty details. But it sure helps to understand the structure of what's underneath, or how it uses whatever is underneath that.

For example: I'm no mechanic who knows the outboard ICE on my boat like the inside of his pockets. But I do know it's a 2-cylinder, 4 stroke engine, how those cylinders sit in the engine block, how to unscrew the sparkplugs & check those, what the various other parts & hoses are for, and (roughly) how much fuel it should consume for trip x, y or z.

Imho that's about the level of understanding programmers should have about the tools of their trade.

I sometimes feel like there are multiple specialties (for which different roles, and often different people are required) where someone only has to work for way less than full-time (maybe even as low as 5% of the time). When we hire specialized people, they do the needed 5% and then have to find additional work to do to fill in the time. So we get more complex tools that incremental improvements, we get more abstractions, we get more overall complexity.

Then those external dependencies and services are updated independently and the corresponding abstractions need updating.

Then external services are replaced and new abstractions are introduced.

Most technologies are never "finished" and instead they are updated cause a domino effect of downstream updates.

Semi-related: I'd love to see a single video game that modernized the game experience as you played: Text mode only -> text mode + static VGA graphics -> 2D sidescroller -> Wolfenstein-quality -> DOOM-quality -> Quake-quality -> Half Life 2 quality -> modern-AAA.

This is sometimes a misalignment with organizations, though other times a company is playing games (e.g., priority is to appear externally as having growth or progress).

"The hacking was rather discrete and would most likely never had be discovered where it not ..." should be "The hacking was rather discreet and would most likely never been discovered were it not ...".

The abstraction at fault here? Spell checkers. It's not enough to know how to look for the squiggly red lines under words, it's necessary to know what words mean. As Jerrold H Zar put it:

    Eye halve a spelling check her,
    It came with my pea sea.
    It plane lee marks four my revue
    Miss steaks aye kin knot sea.

Kubernetes is great, but working with a tool that installs an in-cluster REST API that calls another in-cluster REST API that renders objects to be consumed by another in-cluster REST API that will also render objects to be consumed by multiple in-cluster REST APIs that will, eventually, produce containers that are externally accessible through a glorified NGINX config (with L4 filtering done by iptables, if you're lucky) can get extremely tiring.

(To be clear, this is still better than scripts that would call scripts that would write values to files/databases all over the place that are mutated by other scripts since Kubernetes does a really good job of enforcing interfaces between boundaries)

We haven't used _too many_ abstractions. We've merely leveraged abstractions in a way that makes a different tradeoff. A small number of abstractions trades off deep expertise for narrow perspective. A larger number of abstractions allows us to trade off a wider perspective for a shallower understanding.

Neither is wrong. Both are useful. Different situations will call for each.

Programming is more like building with legos than building or using a car. So much of programming is composing units of work, even if you are starting at a low level of abstraction. And those units are very generic, very reusable, with little need for each unit to know about the goals of the end result until you get very high in the stack. In other words, we specifically avoid using specialized parts unless it becomes necessary.

I would wager that >90% of the useful, beautiful, functional software that I enjoy using every day was written by people who don’t know how to write assembly. Whether you measure it by lines of code, work hours, whatever. And that’s okay. They had time to add features and work on their business model rather than having another go at correctly loading their data into the CPU registers.

it’s very likely that those skills are immaterial to their job. It’s also very likely that they will never need those skills.

All of computing is layering abstractions and no one - no one - understands all of them. The author cherry-picks their own favorite layers as being “what kids these days don’t understand” while ignoring their own ignorance of other layers.

One does not need to understand alternating current in order to plug in a vacuum.

Let's not try to excuse the mess in IT by appeals to the aircraft industry until we have a semblance of their professionalism, dedication to safety, and history of handling faults and errors and learning from the process.

Forces you to at least admit to yourself that you probably lack a lot of knowledge. Makes you humble and hopefully qurious.

However, too much abstraction, on a long enough timeline, where does it end? The blob-humans in Wall-E, where no one knows anything and everything is done for us?

I’ve definitely felt in the last ~10 years of my career that the tools and libraries I use in development contain “too much magic”.

You can be a professional in the field, but until you understand all the layers of abstraction, you aren't an expert. You can't diagnose those deep problems and fix them.

Professionals are paid to work in an area, and are thought to know enough not to be horribly dangerous.

Experts, on the other hand, are supposed to understand and have some competence in all the layers of complexity/abstraction present.

It can take decades to reach expert status in a given area.

A few weeks ago I had occasion to talk with a working computer security professional, and asked him about data diodes[1], and often they are used... he'd never heard of them. Often here on HN, I make comments about capability based security[2], and everyone mistakes it for the permissions flags on smartphones. This tells me there aren't many experts in the field of computer security.

The same is true in other fields, you can be a CNC machinist, but until you know about the Whitworth 3 plate method[3], you're not an expert.

[1] https://en.wikipedia.org/wiki/Unidirectional_network

[2] https://en.wikipedia.org/wiki/Capability-based_security

[3] https://www.wadeodesign.com/flatness-3-plate-method.html

Legacy software is almost always going to have issues, and some use complex frameworks knowing full well they have heavy maintenance burdens.

Saboteurs come from all skill levels and backgrounds. Integrating accountability in the development and deployment process is wise.

Most modern "Hackers" are just the sane old cons repurposing common auditing tools to check for known CVEs. Most others simply don't care about some obscure website.

When you catch unknown people poking hardware in COLO data centers... the real problems start to become apparent.

With enough coffee and doughnuts anything is possible. =)

And as soon as this is clear, the attitude follows. Should you know how every aspect of your code is compiled or interpreted? Not really. Should you realize that every automation takes resources, creates accidental knowledge, and introduces its own probability of failure? Yes.

Oh, I couldn't agree more! And it is not just tools ans systems, it is everything from power generation to infrastructure to society and economics.

When start to work like that, the DevSecOps example used in the article but the same happens basically everywhere else too, it spills over into everything else. And yes, this is dangerous in deed.

Power steering, for example, simplifies steering thanks to a small mountain of abstractions built up over the years. Doubly so if you have adjustable power steering (i.e. you can select "sport" steering vs "comfort" steering). https://en.wikipedia.org/wiki/Power_steering

Abstraction layering is annoying, but I think abstracting hard things infinitum ad nauseam is, overall, a good thing!

The security issues expand beyond what is described in the article: you assume the security is solved by a stack of layers where is not. A single issue impacts everything doesn't matter where in the stack it is.

- newcomers to programming reinvent wheels because it is a natural way to learn. That is why we often have alternative frameworks/CMS/languages and so on

- there are many crooks in the industry who thank their earnings mainly to marketing and contacts. They are also the most vocal to deceipt clients and developers alike

The amount of data has increased over the decades, but programming and software hasn't changed over 50 years. We face challenges to manage this workload.

People increasingly just know about using third-party technology instead of building their own.

One approach to fix this is to ban usage of third-party technology entirely.

Someone else pointed out surface level knowledge of power tool users... but thats always been the IT industry.

IMHO. You either have "this" ability or you don't. There will always be a few people who can think and design complex systems and then everyone else who thinks its easy but only understands it surface level.

Personally I think cloud is a pretty big abstraction layer, I prefer to work on non-cloud and hate proprietary terms and disconnected tooling for common problems.

To understand a solution admins need to understand how it works via code and config access.

most people only chase the next thing you can build on top of what we have today. they only look back inside the layers when the current tech is not enough to achieve your goals out of the box.

a recent example i see is with the quantization and tinyml developments in machine learning. while it is easier than ever to create a model and to run it, the underlying architecture, previously only up to the people designing the frameworks, is now finally being looked at. only because the LLMs cannot fit inside the memory of elusive enterprise GPUs as easily as you'd like.

in no other instance would most people care about how numbers are stored in memory in the past 15-20 years in writing software. i think necessity is mother of invention, and that would probably still apply to dealing with abstractions going forward.

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.

I was once managing a few large file servers, with bog standard users as well as devs using a pretty complex directory tree of "assets".

There was a pretty high-up, specific directory level, which was where the ZFS file servers were given their different loads to handle. This was a directory level where new directories were created rarely (99% at the start of the project).

For reasons of money as well as speed, I asked that the server admins (ie. me) be the ones to create any further directories needed at that particular level. The head dev refused to entertain the idea of not being able to create directories anywhere he wanted at any time, and therefore, a new system was brought in at five-figure costs in order to make the file servers into a large abstracted blob that users never had to think about the complexities of managing.

I was given an opportunity to exit the IT dept and become a Python dev and I took it, shortly before that system came in, because it caused many problems which were much worse than needing to have an admin create a directory for you maybe once or twice, and the evident ignorance of everyone I spoke to at the vendor made it very clear ahead of time that it would.

This was not the only such massive expenditure on a toxic boondoggle in the name of "simplicity" that I witnessed.

It makes me wonder if we are a hitting a pyramid depth in tech that exceeds a practical limit for the human mind and life-span.

One solution is to get a better mind. Interesting coincidence that there are few in the works...

Having many abstractions on top of each other leading to inefficiencies is a problem, but that is not a problem of the number of abstractions, but rather the poor composition.

https://sites.google.com/site/steveyegge2/practical-magic

DevOps isn't "that guy does everything". DevOps and Dev ARE different. Dev's product is what we sell to customers. DevOps product is the construction of a software development pipeline - from PR to production that ensures the policies and procedures of the company are enforced on the code base while setting up to code to function in the real world.

Dev designs the widgets.

DevOps designs the widget assembly line. DevOps job is to eliminate the Dev's pain points around deployment, resources, security, and compliance.

I know this sounds like gate keeping - but you should question the leadership of any company that merges dev AND devops. Any one coder is cannot a complete team - there's simply too much to know - unless you heavily rely on high level deployment products like AWS app server.

Now onto "abstractions"...

Your abstractions should focus on the domain language of your subject matter experts. The abstractions should, ideally, let a subject matter expert browse your code and shouldn't be too confused or overwhelmed.

Abstractions around technology like web or gui frameworks should be decoupled from your company's abstractions. Frameworks like that are just platforms that your product should plug into.

A gold standard for a company's code is that it could be easily cut out of a framework and plopped into another environment. A web app one day could be adapted to become a batch job that's run overnight somewhere else.

Every generation we have to relearn these principles because coders are pretty bad at teaching. There are few ways to write code well - compared to the myriad ways of writing code poorly.

The abstraction becomes real.

This example sounds like a bad choice of framework, or insufficiently skilled devs.

I don't think the problem is that we have too many abstractions. Abstractions are useful, they allow people to focus on where they are different, avoid wasteful duplication of effort (when done right), and compensate for the non omniscence of everyone. They come with a cost, you need to know it.

There's a clear tendency to just buy into new trends, anf that's always been the case. Maybe the smaller scale of the industry back then made trends smaller and the choice more limited.

I think there's clearly an issue with the lack of interest to understand what's under the abstractions. Is it training, habit, culture, a change of who is a developer today? Don't know.

It was also much harder to be a dev 15 or 20y ago without having to know at least some C and some system. Stuff seemed more brittle as well so you had to fiddle. Deployment was mostly manual and artisanal so you had to copy files over manually, run commands, shit like that. Honestly the piece of mind and safety that frequent deliveries and "devops" brought is so good that I'd find it comical if anyone would suggest to me to go back.

So I don't think there's really too many abstractions. I think that sometimes they're the wrong choices, and sometimes people don't care enough about what's under their immediate interface

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.

https://youtu.be/ZSRHeXYDLko?si=zR7Lq2jSxexWUCra

Awesome particle.

the individuals deemed to be "experts" rely on closed source software to the point that the software is the real expert

Bleak stuff indeed.

The anecdote about these kind of security person is interesting, and it's not hard to sympatize with him, but he is missing the point: The industry seems to need someone to run these kind of pre-made security tools. These jobs are not pointless (perhaps they would be if the people who actually "know" other abstraction layers didn't create software that suck), they are solving some problem, people are working full time and getting paid for them. And the fact that they exist does not mean these jobs make sense or that the tasks they focus on are the right or the wrong abstraction.

> What good does an abstraction do when it breaks and nobody any longer understands how the technology under the hood works?

Not many programmers know of a kernel works internally (processes are just another abstraction). Not many know how compilers work and translate high level code to machine instructions either (there is probably no person in the world who understand all the parts of LLVM/GCC). The amount of programmers who know how CPU instructions translate to transistors is very, very rare.

Yet all these abstractions sort of work. People argued back in the day against programming in high level languages, nobody cares about these people, because the kind of problems that can be solved with high-level programming languages can't really be solved with assembly. Abstractions don't appear because companies are stupid, people are trying to solve problems with software and they need to get some concrete task done. Doing the quick hack does not mean that they are doing something wrong, it means that they are focusing into doing something right at another level. And if you can't understand that, it's _your_ fault.

Of course, plenty of times companies are doing stupid things, but that's the nature of the problem, companies try to do different things, some of them succeed, some don't, some succeed despite being horrible and some fail despite being brilliant on paper. So abstractions are created all the time, and there is a continuous dialectic between that abstraction and its usefulness, which is not measured by the opinion of other programmers, but by the success of the companies adopting and following these trends. For some people who knows a lot about systems programming and administration, it may feel stupid that these days we have people with cloud certificates who are in charge of "orchestrating" scalable and fault-tolerant platforms in the cloud, but know very little about how Linux systems work underneath. But it turns out that these people can get things working, even if they don't do it as well as you would do, and that's something that matters - it means that the abstraction sort of works, even if it leaks some times.

I guess it's not easy to spend decades learning things only to wake up one day and realise that large parts of your knowledge has been abstracted out and automated (ie. made less relevant, and thus less valuable in the job markets). But that's how things are in this field...

There is more to life than knowing everything about writing software.

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.

Programmers too often add indirections which don't provide abstraction:

  * The programmer wants to POST an object to a web server.
  * The programmer also wants to think about it at the level of POSTing an object to a web server.
  * And yet the programmer creates an HttpClient.java and an AbstractClientManager.java an ClientManager.java.
  * These extra classes are just pointless indirection - not only do they not prevent the programmer from needing to reason about POSTs, but they actively make it harder to do so.

I find the modern Vue, React etc. stacks absolutely insufferably complex and prone to breaking in 1000 places each time you upgrade some package, or change som random thing in the already stupidly complex "Tooling/Build" chains people are setting up by default.

And it's because no one, not even experts in the field seem to understand 5% the stuff that is contained in these monster codebases.

I found myself using 90% of my time on this setup and tooling, and i'm pretty sure most devs do not need these.

I'm wondering if i can somehow pivot into making only these elegant products for customers. Have anyone done this as a solo dev, contracting or in an agency? Maybe make a "frameworkless" agency? Will hopefully save my sanity and my career.

I find the code much easier to read, the codebase is way smaller, and the app's can do the same thing. You can always pull a library here and there if needed.

Also coding and putting together a project is suddenly fun again, and it seems most languages; CSS, JS etc. are now so mature you can do almost anything with them without the bloat.

And as a bonus you actually have time to understand the different underlying concepts like back in the day instead of using weeks in the issue trackers and playing tetris with dependencies.

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 asking questions about their system, it’s supposed to be basic curiosity. At my current job there’s this architect that explicitly asked me for continuous feedback, but now shows subtle signs that maybe I went a little too far.

Questioning everything gets results, not friends.

Regarding abstractions: I've sort of always ran away from languages that encourage it a lot. Java was one of them, where the entire OOP trend just fell flat to me even in college (I understood the benefits, but meh). The concept of dependency injection is another one, I think it was introduced in Javascript? Idk, I use it if the framework forces me to, but IMHO, it only makes sense when I'm the one building it. Define constructors that take interfaces and instantiate them explicitly with whatever implementations you want (ie. mocks vs real, etc). So that you understand everything that is happening.

My Biggest fear with frameworks (especially JS) is they are abstracted to such a level that I can't hope to fix an issue in a reasonable amount of time without begging for help in forums or github bc I don't understand even the concepts. What are effects? How does react work? How does Angular work? etc.

People are getting nervous because if a war with China would happen with a rapid de-globalization something akin to the "1970s energy crisis" would happen in the semiconductor and digital world.

Well price of our beloved computers and devices would probably need to go more than 10x and around 100x for things to get really interesting.

If this would happen, your cloud native scalable & hyper convergent smart platform powered by AI would feel like a car that have been designed when oil was $15 a barrel. Not exactly what you need right now.

Company would seek the services and even surrender to the blog author like a life long addict seek help and realize he wants to live once he reached the bottom.

Until this happen, this is just an old man rant.

The post and the url reminds me of the Unix Hater's Handbook. https://web.mit.edu/~simsong/www/ugh.pdf

The problem with the abstraction tower is not that it is a tower, but that it is square, when you can't tell where you are relative to the abstractions above or the abstractions below, then your abstraction gradient is too small and you are just generating mush. We have too much mush.

This isnt just coders. I work with people every day who do not understand directory structures. I blame "cloud" apps like o365. They dont understand that the human can dictate where a file is saved and stored. They just expect that the machine will save it somewhere according to the type of file, or that all files for a project will be in one big space defined by the UI interface for that project. But then i ask for them to send me a copy of a file for whatever reason. All they can do is attempt to send the file to me from withing the UI, only to another user within whatever app they are logged in to. They dont know how to move discreet files between discs or directories on thier own, or even that such things are possible.

I've worked with CUDA programmers who weren't aware of what "architecture" means in the context of computing until I asked them to consider running binary code meant for NVIDIA on AMD GPUs.

I've worked with network administrators who couldn't conceive of the simple math behind something like single IP, 64k ports and approximate memory per entry in a NAT state table to figure out that it's actually not impossible to have NAT states that persist indefinitely.

I've worked with people to whom I've had to explain that bits are bits, and just as in the audiophile world where there's a huge amount of money and energy spent to try to convince people that pricey bits are somehow better than cheap bits, so unless you process them differently, they're bits and are exactly the same.

There's this tendency to believe and follow trends, even when there'e ample evidence of how these trends aren't much more than marketing fluff and more often than not lead to dead ends. It's fine if others want to believe the marketing fluff, but when they want me to change my workload to support something because it's "all the rage", I have to put it in terms they understand ("You love Go? Great. Now what if I told you to use Rust because it's all the rage, and I expect you to rewrite everything in Rust?")

It's unfortunate that students aren't taught more history of computing. If they were, they'd likely learn that computing is computing, and that things don't really change that much, and that if you make and use things that aren't different for gratuitous reasons, they'll still be around and relevant years from now.

This design is sort-of working under plain sailing conditions (lots of available resources, booming markets, peaceful cooperation). But it is very non-resilient under stress (subdued expectations, broken promises, resource scarcity, hostility and strife).

Remember the pandemic? It was painful lesson and we like to forget pain. But it was an instance of our abstractions failing at a global and systemic level. Broken supply chains, panic, implosion. Thankfully it wasn't the worst kind of negative development but it shows that in the way we design essential pieces of the economy we are basically simply ignoring entirely plausible scenarios.

Now, how are we to respond to this momentous challenge? We can't go back to some low-tech autarky. People cannot build and program their own silicon from ground up (though it would be really cool to be able to do it at least as a proof-of-concept).

The gist of the right approach seems to me is to make sure that abstractions are tethered. If you need dozens of pieces to be in place to deliver something, the combinatorial possibilities of some of them not being available grows exponentially. If you need the latest and most expensive gear to operate this means the long tail of humanity is left behind.

Another analogy might be the drastically different structures you can build out of carbon atoms. You can have graphite layers that peel off at the slightest pressure or you can have diamonds that are the hardest of them all. The difference is the more connected nature of the diamond lattice. The different abstractions should be really fitting together very tightly with strong bonds.

Don't be like graphite, be like diamond :-)

What is up with the discourse lately - of course it’s all about the profits - we’re talking about companies right not non-profits? How else are they going to pay you?

The whole “expecting companies to care about so many things” apart from profit seeking mindset is just bizarre to me

Nvm all good.

So the only way the mounting complexity of software could create a "bleak future" would be if it somehow prevents us from bootstrapping those programming AIs, and I doubt that will be the case.

Deal with it.

And if you really want to change shit around you, be damn sure to have lote of time and equal patience. And not least some understanding of how the human mind work in a professional capacity.

It's too fucking easy for any of us to simply throw our hands up and say "this is soo bad".

If you really want to understand something try to fucking change it and tell us how that went instead.

Everyone can tell stories about how bad shit is but very few can tell a story of the backbreaking commitment it takes to change shit.

Man up

If that's the case building a house, farming, and everything in life if an abstraction of blind leading the blind.

The reason we are so great is because we could stand on the shoulders of the giants who came before.

This is especially true if software. I don't need not understand assembly to get my business tested and in front of users.

To me this is the same argument that the genetic older generation uses to complain about a younger generation. They'll destroy themselves if they don't do it like I did.

Change is here. Adapt and learn like you used to. Do that and you'll be fine.