45 ms·

We have used too many levels of abstractions

• yieldcrv 3y ago
  this is the kind of thing you say during an interview, get rejected and then wonder if you just experienced ageism instead of any introspection about your own rant
  • noobermin 3y ago
    A charitable interpretation of the article is of course a balance is what actually matters. It is good, on some level, that abstractions free up developers or whoever to focus on the business instead of just tiny little details. Their example, however, proves you need escape hatches sometimes, and you need to have a mind for the details at times, and right now the balance is far in the "abstract everything" direction which has its own issues.
    • BigJono 3y ago
      I think you might've missed the point a little bit. It doesn't read to me like "abstractions bad", it's saying if you're going to use an abstraction you should learn how it works (and that we've built so many that nobody bothers to learn them, which is true). I know Javascript, React and Express like the back of my hand. I can solve absolutely any problem I've run into with that stack, I can't even remember the last time I was stuck on something. But I've ended up on like 5 projects in a row with stuff like Typescript, NextJS and NestJS because they are red hot on the fad scale right now. Despite that, I still don't feel like I know much about them because I set that bar reasonably high, and out of all the people forcing me to use tech I don't want to use, none of them even come close to reaching that bar. I'm sick of asking fairly basic questions about frameworks and libraries I'm not as familiar with, and getting back "oh, I dunno, have you tried...?" 15 times in a row before solving the problem. That's not an efficient way to work, no matter what 90% of the industry seems to think.
  • embik 3y ago
    Can you elaborate on that? What kind of introspection do you think the author is missing?
    • yieldcrv 3y ago
      yes too much abstraction is bad In the example at the end, people don’t necessarily need to know what files and folders are so its not bad that they dont know, it’s better for a new developer that they have a blank slate to learn about trees of storage paths, as the skeumorph is outdated. just like the save icon being a floppy disk was so outdated that instead of replacing it, people realized we dont actually need save icons anymore and everything should just always save
  • userbinator 3y ago
    No, this is the kind of thing you say during an interview, get rejected, and then realise you were probably not going to like the work environment anyway.
    • yieldcrv 3y ago
      That’s cope, none of the flags in an interview have anything to do with anything, especially after taking enough jobs to you realize that you’ll probably get called in last minute to interview additional people with no preparation whatsoever on the interview process so you just google a couple things to ask and wing it yourself
• auxfil 3y ago
  [dead]
• AngryData 3y ago
  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 left in that knowledge will evaporate to nothing for 98% of workers.
  • ben_w 3y ago
    My dad was absolutely saying the same things 25 years ago about integrated circuits in e.g. car engines.
  • zelphirkalt 3y ago
    Yet, someone has to know this stuff, or be capable of learning how it works and as a consequence be able to work on those arcane layers. Otherwise we stand no chance of finding new, more general abstractions to construct a stack of fewer abstractions in total. We probably won't get to fewer abstractions, but to avoid making the problem get worse even faster, we need some counterweight.
  • mfuzzey 3y ago
    Sure most people don't need to understand this stuff. But the problem today is that very few people, in tech not just the general public, understand the low level stuff, especially among new people entering the field. Furthermore software abstractions tend to be far more leaky than abstractions in the physical world you mention. And when they leak you need someone who understands what's going on under the hood. Actually I don't think this knowledge is most important for people forming their own businesses at all - they have many other problems to sort out. But I think it absolutely is valuable working for someone else. These people are the "goto guys" and, ultimately, a "technical insurance policy" for the companies they work for. A company producing tech products without at least a few people on staff who can dig into and fix almost anything is in a difficult position ultimately.
  • worksonmine 3y ago
    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.
• ben_w 3y ago
  I guess it's somewhat apt for a rant against abstraction to hyperlink… > 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.
• kosolam 3y ago
  I 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 and using iptables directly. Etc.. When it makes sense, additional layers of abstraction can always be added on top, if the foundation is solid.
  • happymellon 3y ago
    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.
    • vbezhenar 3y ago
      You can build infra with cloud-init to achieve something similar. You start with base image (e.g. debian cloud-init image), you craft cloud-init script (like Dockerfile) and you end up with VM disk file which you can run. It won't be better than docker, for sure, but if you're going to use VMs and stay sane, you'll need to reinvent it.
    • kosolam 3y ago
      Please check my reply to one of the comments above
  • omneity 3y ago
    I don't know how others feel, but to me docker is definitely less complex internally than a VM. For one, I'm running a single kernel/set of drivers rather than two. But operationally yeah I agree, the stricter separation could make it easier to use a VM to get stuff done.
    • kosolam 3y ago
      Just to clarify a bit. A VM is already a container. When you run docker inside a VM it’s another level of abstraction. Yes, one can run docker containers on bare metal, however the isolation is poor and so is the security guarantees. In terms of excess abstraction, with VMs or bare metal you just need to learn the essentials that you need to know anyways like for example linux networking and security. With docker there is additionally container networking.
• sitkack 3y ago
  Abstractions are like tech debt. When you consume an abstraction, you also get all the klocs (thousands of lines of code) that it represents, they have a price. When you have multiple sources (as in suppliers) of that abstraction this greatly lessons the risk. As does have an abstraction which is total. The post and the url reminds me of the Unix Hater's Handbook. https://web.mit.edu/~simsong/www/ugh.pdf 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.
  • itomato 3y ago
    Way too much mush. And when questioning the mush, some people get bent out of shape because being critical of the temporary constructs that have collapsed “brings people down”. It’s enough to make a technologist erect a silo.
  • deleted 3y ago
    [deleted]
• kyahwill 3y ago
  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.
  • mordae 3y ago
    A young colleague of mine who has also started "framework first" with Vue + Django was recently confused about what a "serializer" was. They have "written some" within Django REST framework, but he was confused about their purpose. I had to explain the problem with a single wire signalling bits in a series, recipient having to de-serialize them into some data structure. Then I had to explain that TCP emulates such a single wire using small packets. I think that they have understood, but it was a funny feeling explaining this to someone who routinely deserializes form and JSON data, then serializes them into SQL queries, then deserializes query results in order to serialize them into templates or JSON.
  • mrkeen 3y ago
    I had a similar starting point (spring web apps), but reached a different conclusion. The layers and layers of indirection obscured what HTTP is for me, and it took me too long to understand it. Have a look at https://learnbchs.org/easy.html https://learnbchs.org/easy.html for a real "oh that's what HTTP is?" moment.
    • mordae 3y ago
      I usually teach HTTP with `nc example.com 80` and then `nc -lp 8080` plus a browser.
• onetimeuse92304 3y ago
  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 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.
  • 3seashells 3y ago
    Software archeology
  • beretguy 3y ago
    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.
    • onetimeuse92304 3y ago
      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 a connection and it does not work they are pretty much at a complete loss to what happened, where and how to fix it. Aside maybe from a simple problem like DNS resolution error (and not even that -- most devs don't understand how DNS propagation works, for example). So if those problems happen, they are mostly deferring to me as a guy who can solve every problem. I see no clear path to achieving a goal of having someone else to learn to do the same.
• ricardobayes 3y ago
  I 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.
• huijzer 3y ago
  Increases 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.
• warkanlock 3y ago
  This 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/ https://madebyevan.com/figma/introducing-vector-networks/
  • EvanAnderson 3y ago
    > ...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. A big difference is that, unlike computing, their instrument probably won't stop working because of some subtle change to physics introduced by a seemingly-unrelated change made to the universe by some other party in the musical instrument / air / molecules / atoms / quarks "stack". Theirs is a world with some assurance of stability. Ours is a field built upon shifting sands. Knowing what the foundations are that the edifice you've constructed sits upon allows you to affect repairs when it crumbles unexpectedly.
    • pydry 3y ago
• jannesan 3y ago
  While 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.
• LudwigNagasena 3y ago
  > 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.
• acd 3y ago
  Sometime i just want to use old school copy code build binary to server and run it :).
• molly0 3y ago
  Asking yourself: “Is the abstraction I’m using optimal for what I’m currently doing or could another type of abstraction be even better?” Forces you to at least admit to yourself that you probably lack a lot of knowledge. Makes you humble and hopefully qurious.
• mrkeen 3y ago
  I think a good first step towards improvement in this space is by separating the terms 'abstraction' and 'indirection'. 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. In contrast, if you have a collection type (Set, History, Permissions) and want to treat it as a monoid, that's a huge leap in abstraction, with only one level of indirection.
  • mordae 3y ago
    Because almost all programmers tend to add not only abstractions, but also shortcuts. And as everybody knows, shortcut is a longer but more challenging route.
  • BigJono 3y ago
    I think the reason people do that stuff is because they do provide abstraction, but they only do it in UML diagrams, not in the code. I've found the shittest programmers to work with are the ones that think visually, because in their head they just deleted two boxes and four lines, but in reality all they did was add 40 lines of code that do nothing.
    • alpaca128 3y ago
      I think visually, but in terms of memory and datastructures, not in UML diagrams. I don't think the "visual" part is the problem.
    • dgfitz 3y ago
      I’ve found the shittiest devs still use UML. https://news.ycombinator.com/item?id=26956298 https://news.ycombinator.com/item?id=26956298
  • hliyan 3y ago
• Unfrozen0688 3y ago
  Nobody studying will read this advice.
• loup-vaillant 3y ago
  > 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 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.
  • Danieru 3y ago
    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.
    • loup-vaillant 3y ago
      See, that’s the kind of social pressure I was talking about.
      • egwor 3y ago
        And that's probably healthy for society to have a check. If the questions about the sky keep the questioner in bed they might not do the things they need to ensure their continued existence. In one respect that might be food but in a business that would be delivering change or supporting the business. Another example: as a child you understand what + means and take it for granted. As part of Maths undegrad you start understanding the type of operators and the axioms of maths. The child was perfectly find completing maths problems without that depth.
        • Danieru 3y ago
          Ah you went there eh. Yeah an alternative form on my reply would have been to point out that kids are the ones who question everything. Adults learn to identify the questions which will expand knowledge, and ask those.
• SanderNL 3y ago
  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. 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.
  • tsegratis 3y ago
    > 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")
    • Zanfa 3y ago
      > 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.
      • tsegratis 3y ago
        A good book on the subject "Fix IT: See and solve the problems of digital healthcare" https://www.waterstones.com/book/fix-it/harold-thimbleby/9780198861270 https://www.waterstones.com/book/fix-it/harold-thimbleby/978...
    • SanderNL 3y ago
      Wow, sickening. I guess something like certified engineering may alleviate some of these issues. If we build bridges like this.. oh.
• userbinator 3y ago
  Somewhat related article "The resource leak bug of our civilization": https://news.ycombinator.com/item?id=8679471 https://news.ycombinator.com/item?id=8679471
• joeman1000 3y ago
  What else can you do but look at files and code to figure out problems? And why use a monospace font for prose? I agree otherwise though, it can bite you in the arse if you don’t understand the layers of abstraction you’re dealing with. It’s the reason I sort of don’t like browser-based stuff. We already have a full OS stack for doing stuff, why add another on top of it?
  • KronisLV 3y ago
    > And why use a monospace font for prose? Honestly, I liked it. The font defaulted to Consolas on my Windows machine and it was both readable and not too distracting, oddly enjoyable.
• mgaunard 3y ago
  I couldn't agree more. 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.
• Zetobal 3y ago
  It's not only developers we had a regress in skill in the art/vfx world as well. If there are no tutorials with step by step instructions on youtube most people can't resolve visual/art/vfx problems anymore. It's about the most basic things if you get people with "art" degrees today maybe 3 out of 10 can draw or sketch. If they are not in front of a computer they can't communicate visually. They are also not able to adept or solve problems on the fly which is really important if you supervise on set.
  • deleted 3y ago
    [deleted]
• spacebanana7 3y ago
  At a certain point software engineering may come to resemble medicine more than mathematics, where the lower layers of operation are known to be poorly understood and innovations emerge from tinkering rather than derivations from first principle.
  • trealira 3y ago
    It seems like many important innovations we use today were derived from first principle. Rust uses algebraic datatypes with ML-style type condtructors and Hindley-Milner type inference to achieve, for example, types like Option<Box<T>> or Option<&T> or Option<&mut T>, so that you're forced to check for the case of a null pointer (None), and if it's not in an Option, then it's guaranteed not to be null. This was originally conceived of mathematically in the 1980s and then implemented in ML. The Hindley Milner type system was devised in 1969 from the typed lambda calculus. Golang was influenced a lot by Communicating Sequential Processes, a formal system for describing concurrent behavior in systems, first described in 1978 by Tony Hoare. Graph theory is a field of math that comes up a lot in computer science, in marketing, networking, compilers (register allocation and functional programming language interpretation). The only innovation I can think of that came purely from tinkering is Rust's borrow checking system, and they're still trying to formalize that while improving it. Derivations from first principle are always important.
• gatinsama 3y ago
  Anyone reading this should read Steve Yegge's "Practical Magic" post for a deeper dive. https://sites.google.com/site/steveyegge2/practical-magic https://sites.google.com/site/steveyegge2/practical-magic
• lifeisstillgood 3y ago
  And it's very very hard to fight because "Bob set up a foobar in a day and look it works!" is not the same as "we understand all the pieces and components and what they do behind foobar"
• hliyan 3y ago
  In other words, cargo cult programming. I wrote about this two years ago [1] and received only polarised responses that either agreed with the point wholeheartedly, or attacked me viciously for gatekeeping. I wish there was a better way to cure this disease without triggering the professional immune systems of engineers who are highly vested in their favourite technologies. [1] https://medium.com/the-engineering-manager-guide/cargo-cult-programming-is-killing-the-sri-lankan-software-industry-e5e9fc9a3ff9?sk=02370473978b3641b887ff74006c529c https://medium.com/the-engineering-manager-guide/cargo-cult-...
  • johnklos 3y ago
    You asked good questions in that article. It's unfortunate, and I can't help but wonder if we've lost something essential because of how uncommon it is for people to be proud of their abilities, proud of their work, proud of their accomplishments. In a nutshell, I think people who truly enjoy the satisfaction of doing a thing well are spending more time, generally, trying to truly understand things than those who just want to do their job and be done with it. But what does that curiosity get us? I can't help but think of this fortune(6), and wonder how many non-curious people would even get it: A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing spoke sternly: "You can not fix a machine by just power-cycling it with no understanding of what is going wrong." Knight turned the machine off and on. The machine worked.
    • meiraleal 3y ago
      > It's unfortunate, and I can't help but wonder if we've lost something essential because of how uncommon it is for people to be proud of their abilities, proud of their work, proud of their accomplishments. Is it? this forum is full of it in the form of blog posts and replies. And it is one of the things that makes it great. By the other hand, social media is also full of people boasting about their accomplishments but more often than not is just marketing.
  • bluecheese452 3y ago
    I read your blog post in order to understand why you might be getting negative reactions. You are coming across off as combative and arrogant. It feels like you are quizzing people on details in order to show you know more than them.
• irjustin 3y ago
  Hard disagree. 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.
• aymar_99 3y ago
  Yes and no, abstractions dumbed down things for common users. But there are and will always be a set of power users who get into the details. Power users are the ones who abstract in the first place and abstraction is not a one time process. Abstraction keeps evolving too, hence there are going to be power users who know the capabilities and support in the evolution. This is any how stream works let alone software. There is no need for everyone to be a power user.
• p-e-w 3y ago
  Meh. Unless something very unexpected happens, human programmers aren't going to be a thing anymore, starting in a not-too-far future. And programming AIs will neither have trouble understanding all those layers of abstraction, nor will they add additional ones, since their main purpose is to help limited human minds cope with the inherent complexity of problem domains. 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.
  • jodrellblank 3y ago
    AIs of today don’t seem to understand anything, they will often output code which uses methods that don’t exist or use libraries that don’t exist, and this is just dealing with the top layers.
• walleeee 3y ago
  Good article. This same critique applies equally well to technology in macrocosm. We need to ask: - 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.
• subomi 3y ago
  Reading this, I had an epiphany about why open-source software is essential. How do you peak under opaque abstractions? It's just not possible. 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.
  • diarrhea 3y ago
    To add: the two most popular languages by most popular metrics, JavaScript and Python, are interpreted. There, you don’t have a choice. Go is different of course. Your insight is very good. Not being able to dig into source code when needed is unimaginable.
    • MaxBarraclough 3y ago
      > you don’t have a choice That's not really true, obfuscating JavaScript can be quite effective at making it difficult to study the program's workings. It can't be perfect at this, of course, but neither is conventional ahead-of-time compilation to machine code.
  • MaxBarraclough 3y ago
    Right. The Free Software Foundation have written about this, they consider the right to study software to be part of 'Freedom 1'. * https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html * https://www.gnu.org/philosophy/shouldbefree.en.html https://www.gnu.org/philosophy/shouldbefree.en.html
• signaru 3y ago
  Software's re-usability is both a blessing and a curse. Hardware also has modularity, but it is still common to build hardware from scratch. On the other hand, once a library or framework exists, many people no longer feel the need to understand the underlying algorithms. One side effect is that many of the frameworks or libraries still in use and that are important for the dependent software to work are written with languages that less and less people want to program in such as C/C++ or even Fortran.
  • brutusborn 3y ago
    I’ve seen decades old Fortran codebases that everyone is too scared to touch. So instead all the new ‘features’ marketed to clients are just window dressing around the existing Fortran core.
    • trealira 3y ago
      Side question: what kinds of codebases were those? What products were built on top of decades-old Fortran code? I'm curious.
      • brutusborn 3y ago
        Engineering simulation software. So being hesitant to change code is probably fair, in case you introduce new bugs. However that view ties your hands when improving the software and at some point becomes counter-productive.
• Leires 3y ago
  If ignorance is rewarded, then people will willingly choose to be ignorant. The advice in this article sounds nice, but the reality is the rats only want the reward. If learning Kubernetes gets a six figure job tomorrow, people will chase it while ignoring networking and OS fundamentals.
• diegocg 3y ago
  This post misses a crucial step in its argumentation: trying to understand why these abstractions happen. Blaming it on some kind of "techno-moral" decay is not an explanation, it only turns the argument into some kind of arrogant self-reward post. It's like when Plan9 fanboys argue about the lost "purity" of Unix. 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...
• brutusborn 3y ago
  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.
• rgblambda 3y ago
  >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.
• anovikov 3y ago
  Downside here, is that following this advice will usually mean they make less money.
• michellebarbarq 3y ago
  [dead]
• phendrenad2 3y ago
  > A big percentage of so-called experts today only know how to configure some kind of hype-tool, but they understand nothing about how things work at the deeper level. 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.)
• neilv 3y ago
  The author's "Advice to people studying technology" goes against the dominant practices for individuals making money in software right now. 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).
• largbae 3y ago
  This could be applied to society as a whole. Currencies are an abstraction on bartering which is an abstraction on doing every task required to support your life and family yourself. Each layer of abstraction creates a specialization and efficiency. Those who consume the abstractions may lack the details, but they have levers long enough to move mountains! Those who provide them have a valuable role. Don't be afraid, we must keep making more.
• zubairq 3y ago
  Having worked for many years in IT in Denmark I would say that the author is right, but many of these are luxury beliefs, since in Denmark people are given alot more time to do their job right than in many places. In many parts of the world developers are not given the time to understand anything, and end up working 8 hours after the job to understand the tools in their own time
  • dudul 3y ago
    How is Denmark so special in that regards? What are examples of these places where people are not given the time to do their job right?
    • zubairq 3y ago
      Why Denmark is so special in that regard I do not know, but for Europe in general if you are directly employed by a company you get good training, and the ability to get a lot of help and support from colleagues (based on European consultancies that I have worked for). I've also worked for Asian consultancies and there is more of a sweatshop mentality in those companies where "everything" is about the billable hours and there doesn't seem to be the same sort of work/life balance (I'm half Indian just for context so try to see the European and the Asian angles)
• sunshine-o 3y ago
  It is all about how much risk do we tolerate in the western world. 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.
  • deleted 3y ago
    [deleted]
• jongjong 3y ago
  The other thing is that we've adopted the wrong abstractions on many occasions. Today, in the software industry, we have an arrogant mono-culture which believes that we're at the end of history and have figured it all out... But in fact, I believe we've gone down the wrong path with many more recent tech. I feel like everything was moving on the right direction until around 2014... Then it's like progress started going backwards and we started using all the same hyped up frameworks. Companies started forcing everyone to use these frameworks and now software development has become both inefficient and demoralizing. 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.
  • halfmatthalfcat 3y ago
    > Companies started forcing everyone to use these frameworks Companies are made of people who, hopefully, have people in decision making roles who have context and the knowledge to make the right decisions. There are reasons why we use "these frameworks" (be it frontend or backend). You may not like the reasons but corporate programming isn't just about language purity but what makes the company money, of which there are a lot of factors like hire-ability, maintainability, continuity, etc. What happens when your company uses your bespoke SDK and you leave? You may think its easy to teach someone else how to use it but there's a lot more that goes into how companies make technology decisions.
  • tommybu 3y ago
    I am curious about your SDK now. Do you host it publicly? If no, could you at least explain what is the difference between your method and mainstream frameworks?
    • jongjong 3y ago
• RetroTechie 3y ago
  "Don't just learn tools, try to understand how the underlying technology works." 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.
• pmlnr 3y ago
  > So what is going to happen when the level of understanding in the tech industry reaches such a low point in which the majority of people don't even know how to fix the tools they are using? Priesthood. See: Foundation by Asimov.
  • anthk 3y ago
    AKA an Space Age retelling of the ending of the Roman Empire and the beginning of the Middle Age.
• okaleniuk 3y ago
  "Abstraction" is a misnomer. This word has its useful meaning in math and art, but in software engineering, all what we call "abstraction" is automation in disguise. When you write a piece of "abstract" code, you only delegate writing the piece of concrete code to your compiler or run-time type deduction. 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.
  • otteromkram 3y ago
    I disagree and believe "abstraction" is the correct term for wgat the author intended. > Computer science commonly presents levels (or, less commonly, layers) of abstraction, wherein each level represents a different model of the same information and processes, but with varying amounts of detail. See: https://en.m.wikipedia.org/wiki/Abstraction_(computer_science)#Levels_of_abstraction https://en.m.wikipedia.org/wiki/Abstraction_(computer_scienc...
    • ahoka 3y ago
      I think it’s very common for developers to mistake indirection for abstraction.
    • okaleniuk 3y ago
      I don't challenge the author's use of the word "abstraction", I challenge the validity of the very word "abstraction" in the context of computer science. What we're dealing here is not abstraction, it is something else. But thinking of is as of abstraction brings us to the state of affairs the author criticises. If you remember that there is very specific very concrete automation behind every abstraction, you don't stack them up until the pile becomes impossible to either control or understand.
  • jsenn 3y ago
    This is a useful insight, but I think that many automations really are based on solid, honest-to-goodness abstractions of the same type you would find in math. Furthermore, that's good and important! It's true that a compiler is merely translating a high-level language into the actual machine code, but it's simultaneously true that you can (generally) talk sensibly about the high-level language, and maybe even prove theorems about it, without making any reference to how it will be realized on the machine. That's a good abstraction. The better your abstractions, the more your automations make sense, and the more you can reason about them. Automation without abstraction gives you biology, which is a gnarly mess of accidental complexity that's very difficult to reason about and control. That said, I'm going to start thinking of my code more in terms of creating efficient and low-risk automation, and less about creating nice abstractions.
• preommr 3y ago
  These abstractions also exist to fill the void of an ever creasong job-sector. 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.
• gemstones 3y ago
  In my (admittedly anecdotal) experience, security people are the worst at this. I’m not sure if the problem is that they have so many certs that you can just memorize canned answers and get a job rather than go through an SWE coding test at most places, or something else.
• jtode 3y ago
  Ludicrous abstraction story. 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.
• donatj 3y ago
  > Power steering is yet another level of abstraction that further improves the driving experience. 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.
  • sega_sai 3y ago
    Do you know that antilock brakes slow down you faster comparing to car with locked wheels?
    • johnklos 3y ago
      I think the point was that anti-lock brakes remove options and make things less safe in certain (not very uncommon) instances. With anti-lock brakes, you're protected if you've never learned anything and you just try to put the brake pedal to the floor. If you know how brakes work, you're worse off than if you don't have anti-lock brakes, since you can no longer properly control your brakes. In other words, we're punishing people who learn and know how to do things in order to ostensibly protect people who can't be bothered to learn. Consider how many people drive with their headlights on, but no other lights. It's because automakers are selling "features", so it feels like we're actively encouraging people to think and pay attention less. Unfortunately, these "automatic" lights aren't truly automatic, and the value of having simple off and on states is lost because of these "features". It's actively unsafe.
• heywire 3y ago
  Related: Jonathan Blow’s talk Preventing the Collapse of Civilization https://youtu.be/ZSRHeXYDLko?si=zR7Lq2jSxexWUCra https://youtu.be/ZSRHeXYDLko?si=zR7Lq2jSxexWUCra
• steeleduncan 3y ago
  There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles? 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...
  • metalrain 3y ago
    Yes, I cannot imagine how anyone could know all the details that go into each step. It's good to have people that do know how computers operate and how we use them, but specialization is also good thing.
  • hliyan 3y ago
    It would be concerning if pilots, aircraft maintenance technicians and aeronautical engineers shared titles and job descriptions so similar that it was hard to tell them apart.
    • pcthrowaway 3y ago
      Heck, the titles in software are so broad you may as well have the pilot, the tech, and the aerospace engineer all sharing the same title along with the flight attendant.
  • stakhanov 3y ago
    The problem is that it takes a really long time until technology is so good and so reliable that you really don't need to understand it to be able to operate it. Take, for instance, the "Yes, let's all go back to coding in assembly!" line -- The thing is: For a really really long time after high-level languages had become mainstream, you really did still have to know assembly to be a programmer, even if you did most of your work in, say, C, or Pascal. That's because compilers for high-level languages and their debugging tools were initially a "leaky" abstraction. When your programme failed, you had to know assembly to figure out what went wrong and work your way back from that to what you could do in your high-level language to fix the problem. Nowadays, compilers and debugging tools have become so good, that those days are mostly gone, and you really don't need to know assembly any more (for most practical intents and purposes). But the problem we have today: We pile on layer upon layer upon layer of leaky abstraction without ever giving it the time it needs to mature. We're designing for shortening the amount of time a developer spends on getting something done, under the completely misguided assumption that the developer will never leave the "happy path" where everything works as designed. This is neglecting the fact that a developer spends most of their time debugging the situations that don't work as designed. Usually, if you make the "happy path" time more productive with a side-effect of making the "unhappy path" time less productive, that amounts to a net-negative, and that's the big problem.
• nickdothutton 3y ago
  I am grateful that I grew up in the 8-bit era of home computers where you had only the barest bones of an OS (until I discovered CP/M and shareware).
• Sprinterra 3y ago
  Yup its good to know
• Podgajski 3y ago
  Hmmm…is social media an abstraction of relationships? Or am I think about abstractions wrongly?
• collsni 3y ago
  Very good article, 100% whole heartedly agree on devsecops and most infosec team members only knowing specifics tools. We need users with ranges of background not isolated at layer 7. 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.
• biomattr 3y ago
  Ive been doing academic biomedical research for the last 15 years. Finding competent reviewers for computational papers is like NP complete. Yet there is a factorial increase of sophisticated code in the literature. So we got the inverse problem to tech. Not enough of the old school, goto reviewer scientists have learned the foundational stuff.
• rini17 3y ago
  Right. So now, where to look for an organization that rewards and supports people who like to know how things work? Even if they are troublesome and grumpy.
• figassis 3y ago
  One cause I've seen of this is the "college is not needed to be a coder" trend from the past few years (decade?). it is true that most of my skills were acquired after college, but there is some sort of global system understanding that you get from college (in my case computer+software+network engineering) where you can quickly narrow down potential sources of a problem, all the way down to say, the TCP/IP stack, CPU architecture, memory management, how some code might be optimized incorrectly by the compiler. It also helps a lot in asking the right questions. If all you know is [latest framework/language/tool], there is a whole world around this that can bite you when circumstances stop being perfect. One superpower is looking at a marketing page for a tool and knowing within seconds what it can't do and whether it would be a good fit for your use case, just by what is claimed on the page. 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.
  • rcbdev 3y ago
    "College" can be extended to include any technical secondary school in societies with dual system education. (i.e. Switzerland, Austria, etc.)
  • dclowd9901 3y ago
    Given the push toward FP principles in JS, it’s become much easier to mete through library code since now we don’t have to assume some reference is getting clobbered somewhere, and we’re not monkey patching some base library. Those were the bad ol days of browser disparity and (let’s face it) IE. Now, not all libraries are built with modern principles, but I’ve found digging through the source is not nearly as onerous as it used to be (as long as you avoid tooling like yarn PnP, which basically undermines your entire ability to inspect library code just so you can… avoid unzipping archives?)
• Joel_Mckay 3y ago
  There is no process that can prevent unknown failure modes. 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. =)
• gherkinnn 3y ago
  And nobody here knows how to raise a cow, milk it, and slaughter it. Neither can anyone make a fire in the rain, and god help us if the internet stops working. We’re so far from basic humaning that every generation needs to relearn how to change a baby. Bleak stuff indeed.
• wslh 3y ago
  The problem is not only the level of abstractions but the cross dependencies and assumptions across abstractions. For example, in higher level frameworks (e.g. React) you should firmly follow the rules in a way that makes assembler a toy language comparing to the stuff you need to know ahead. 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.
• eitally 3y ago
  Back when I was an IT leader running all our internal appdev, I had a "pet" business system that my team used exclusively to write, optimize and rewrite as a testbed and learning environment for new frameworks. It was probably not the most efficient way for me to run the org, but I honestly believe it saved lots of longer term headaches by containing a few potentially terrible decisions to the scope of a single, not-mission-critical app.
• victorNicollet 3y ago
  I think it's wonderful that we have created a tech ecosystem (a techosystem?) that allows people to contribute with only a very narrow knowledge of things—or, in less positive terms, that allows companies to hire cheaper labor because fewer skills are required. I believe there are many cases where a mediocre solution is better than no solution at all. 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.
• hef19898 3y ago
  >> A big percentage of so-called experts today only know how to configure some kind of hype-tool, but they understand nothing about how things work at the deeper level. This is a real challenge and a big problem for the future. 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.
• cl3misch 3y ago
  Abstraction is a feature of technological progress. 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 https://www.historyofinformation.com/detail.php?id=3439
• x86cherry 3y ago
  The article raises good points, but I feel it misses the bigger picture. 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.
• sandworm101 3y ago
  >> Some students today apparently don't even know what files and folders are? 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.
  • YoshiRulz 3y ago
    > I blame "cloud" apps like o365. I blame Android (and to a lesser extent, iOS). In early Android, you had a filesystem resembling desktop Linux. Nowadays, apps' files are secreted away in a dir who-knows-where and other apps can't even see them, let alone read them—for good reason—but the same lack of privilege extends to the user via their file manager (if the OEM was generous enough to leave them one). Compare this to a time when floppy disks (either kind) were ubiquitous, and while the average PC user then may have been less informed of how their machine worked than today, I assure you that they would have had a good grasp of moving files around. Routinely handling disks with your own two hands contributed to that, I feel.
  • deleted 3y ago
    [deleted]
• spacecadet 3y ago
  I think people generally think this stuff is "easy" and willingly ignore the layers of complexity. 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.
• skybrian 3y ago
  Yes, there are some people who don’t know how some things work. The conclusion that the “future seems bleak” doesn’t actually follow, though. Perhaps the author was already pessimistic?
• lebuffon 3y ago
  This situation was predicted in a sci-fi short-story that I read a very long time ago. Unfortunately I cannot remember the title nor the author. 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...
  • IgniteTheSun 3y ago
    Are you thinking of the short story "The Feeling of Power" by Isaac Asimov. (A technician discovers how to do simple arithmetical calculations in a world where no remembers arithmetic since its all automated away.) More information regarding the short story on its Wikipedia page: https://en.wikipedia.org/wiki/The_Feeling_of_Power https://en.wikipedia.org/wiki/The_Feeling_of_Power The short story itself can be found online.
    • lebuffon 3y ago
      No but I forgot about that one. It's a good one too. Thank you. The one I remember was about a "technician" in this world where nobody remembers the underpinnings of technology. There is a big competition to solve a known problem using the existing tech toys that are available. (something like a tech olympics) The technician wins the competition by using the equipment in non-standard ways and re-engineering their functions in ways nobody had ever done. The judges are at a loss as to how he could have done this since it is not in any instruction manual. :-)
• demondemidi 3y ago
  Old man yelling at cloud vibes. 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.
  • igortg 3y ago
    Same feeling. How this article came up to the top? The example he gives is terrible "someone used a modern framework was hacked, but the performance was not caused by the hacking, but the frameworks was terrible slow" - Ok, which was the framework? How did you find it was slow just by looking at a diffs? What someone not knowing how to trim a tool for performance has to do with abstractions?
    • dustingetz 3y ago
      articles don’t reach the front page, headlines do
    • dopidopHN 3y ago
      That exactly at that hacked framework example that I closed the tab.
  • mardifoufs 3y ago
    Yeah I was at least expecting some concrete example or something specific... but nothing. I don't even mind "old man yells at cloud" articles if they show an example or provide actual substance since you at least come out of it learning something... but in this case the entire article just sounds like a bad HN comment.
  • floren 3y ago
    That's how it is with all the articles on that site, which occasionally reach the front page. I'm sympathetic to a lot of the sentiments but the author pretty consistently fails to actually make any argument beyond "I am the smartest, and I don't think this is good."
• MyFirstSass 3y ago
  As a 15+ years webdev my recent projects in the front-end are almost pure "vanilla JS" (Just JS) + Html, and CSS with only Petite Vue / Alpine on top. 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.
  • nologic01 3y ago
    you would need to add alpine.js or something equivalent though. there is nothing wrong with a few core libraries that are long-lived, thoroughly debugged and understood etc.
    • MyFirstSass 3y ago
      You are totally right, i actually forgot that Petite-Vue is the only core library i'm using atm, also tried Alpine and they are great. And their tiny scopes are actually nice dogmas to play around, i haven't yet experienced them not being enough, and when they aren't you hack together some stuff to extend them, and that actually makes coding fun again. It's like the demoscene, it's way more fun to code with some restrictions and limitations you have to be creative to solve, instead of setting up some dependency/folder hell. Optimize, minimise, make more elegant, make more readable, that is where the fun is!
• revskill 3y ago
  Without abstraction, you have to re-invent the boilerplates everytime, everywhere.
• nologic01 3y ago
  Software simply mirrors the development of modern society. Highly complex and relying on countless abstractions to tame that complexity and be able to operate. 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 :-)
  • deleted 3y ago
    [deleted]
• stainablesteel 3y ago
  agreed, dealing with things of this nature from within a scientific field where no one understands the complexities of the data analysis and simply trusts every oversimplified metric explained to them is quite concerning the individuals deemed to be "experts" rely on closed source software to the point that the software is the real expert
• graypegg 3y ago
  Kids today don't get enough credit. A friend's son was so excited to show off the Roblox game him and his friends were making a couple of weeks ago. Was there for (Canadian) thanksgiving so there was some family friends and tons of people from his family there. He had already picked out something he thought each of us would be interested about it, and I was the "show him the Lua!" guy! 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.
  • dihrbtk 3y ago
    I think game-making is an underrated point of entry into programming and software development in general. It worked for me!
    • arp242 3y ago
      Ken just wanted to play his space game. He ended up writing Unix to do so.
    • grishka 3y ago
      Flash got a lot of people into programming because of how one could go from cartoons to copy-pasting snippets of ActionScript for some basic interactivity to full-blown games and apps.
  • Kinrany 3y ago
    Roblox is a company town, but a bad example nevertheless because it's open enough to be programmable and do HTTP requests.
• dreamglider 3y ago
  Do you write code? Yes. What code, examples? I code HELM charts! :) Awesome particle.
• __MatrixMan__ 3y ago
  It's not so bad once you just face it head on: we have toolchain cancer. Yeah, cancer sucks, but are we really so happy with our current set of companies that having them die of cancer is such a bad thing? They're not people. It's ok to want them dead so we can do things differently in the future. 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.
• Towaway69 3y ago
  Abstractions are also related to complexity. As the interdependence between various systems increases, so does abstractions. 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.
• 0x445442 3y ago
  But was the author’s work groomed? Was time scheduled for it in the backlog? What feature specifically was his Columboesque investigation supporting? 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.
• ReptileMan 3y ago
  Children of the magenta all over again.
• m3kw9 3y ago
  AI language programming is the ultimate abstraction
• johnklos 3y ago
  As a systems administrator who has been doing this for a while, I can attest to this becoming more and more of a problem. 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.
  • daniel-cussen 3y ago
    [dead]
  • Kamq 3y ago
    > 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 I always assumed this came down to the analog part (usually some sort of speaker) being better, and all the extras on the cords were really just there because a cheap looking cord would ruin the aesthetic they're going for.
    • johnklos 3y ago
• SunghoYahng 3y ago
  Don't worry, old guys. The reason coders don't know all the low-level skills you've devoted your life to now is because they don't need them. If the future really becomes bleak, they'll start learning the skills they need.
  • theduder99 3y ago
    that future is already here. I'm imagining being beholden to a low/no code platform (lockin and infinite price increases) because that's all you know.
• clord 3y ago
  I’ve seen what happens many times when the abstraction fails, and people don’t understand the guts. The people who know the abstraction replace it with something based in the concrete, but without the middle layer, and which resembles the abstraction. The abstraction becomes real.
• spandextwins 3y ago
  Networking is a huge abomination and needs to be built afresh from the ground up.
• awill88 3y ago
  As someone who learned computer science from tinkering with abstractions until I needed to go a level deeper with a subsequent education in it—-I think this article is inflammatory at best because they are attempting to assert themselves as a voice of a wise person, or, as an expert of how the future “is bleak”
• lucidguppy 3y ago
  I would need to talk to the writer to make sure we're talking about the same thing. 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.
• miggu 3y ago
  There will always be two types of people, people whose interest is in getting things done regardless of the underlying means to solve an issue, and people who get stuck in why it worked , and go down the rabbit hole for hours , to see why something worked (society sometimes call these people nerds).Sometimes I wish I could be the former and not the latter. The most important thing is to be aware that there is a black-box/abstraction in front of you. Confucius once said: "To know what you know and what you do not know, that is true knowledge."
• danielovichdk 3y ago
  These posts are naive and reminds me more of an angry teenager being told the world is a tough place to be in. 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
• MagicMoonlight 3y ago
  We’re going to be so fucked when the people who develop things like the linux kernel die. There are no upcoming people with that level of knowledge.
  • kobalsky 3y ago
    this kind of alarmism is ridiculous. the new layers of abstraction have not made programmers dumber, they have added more programmers to the stack. we still have and will have people designing kernels and CPUs for fun.
    • trealira 3y ago
      Do we? It seems like there are some people developing Unix clones for fun, and building their own RISC-V or 6502 CPUs. We don't have much innovation in OSes from amateurs, though. At least there's sel4, which is formally proven to follow a certain spec that makes some security guarantees.
  • syndicatedjelly 3y ago
    https://en.wikipedia.org/wiki/Hobbyist_operating_system https://en.wikipedia.org/wiki/Hobbyist_operating_system I am not personally familiar with any of those OSes (other than reading about the...bizarre TempleOS), but many of them have last release dates within the last 5 years.
• charles_f 3y ago
  > The developers knew how to put together a website and an API using a "modern framework", but did not understand much of the coding of the framework itself 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
• deleted 3y ago
  [deleted]
• rr808 3y ago
  I'm working on a team with very naive, young, non-technically trained programmers. I love it so much. Start a program, open a file, process the file one step at a time. No DI, not much unit testing, no fancy frameworks or language features. Its so refreshing to just work on adding business functionality and just testing it with users.
• mikewarot 3y ago
  I think there needs to be a clearly defined difference here between professionals and experts. 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 https://en.wikipedia.org/wiki/Unidirectional_network [2] https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security [3] https://www.wadeodesign.com/flatness-3-plate-method.html https://www.wadeodesign.com/flatness-3-plate-method.html
  • phkahler 3y ago
    >> You can be a professional in the field, but until you understand all the layers of abstraction, you aren't an expert. Let's not inflate titles here. I've noticed what the author is writing about and will offer another example. Remember when the bad-guy hackers used to make hacking tools and exploits available for free? Before that was big business? Then a bunch of kids would leverage their hard work to cause trouble. Do you recall what those guys were called? Script kiddies. A lot of so-called professionals these day are little more than script kiddies. That's not to say they aren't effective or useful (the old hackers caused plenty of trouble) but they really don't know the internals of the tools they use. They can keep things going until something weird happens. I'm not sure what I think of this state of affairs. Not everyone can go deep, but I do feel the bar has been lowered too far in many cases. It's like millions of small components... NPM: because nobody can be bothered to figure out some problem and write 50 lines of code themself.
  • 3y ago
• xkcd1963 3y ago
  I see two reasons for these possible pitfalls: - 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.
• bogota 3y ago
  This is a constant source of pain for me since I started working 12 years ago after finishing college. I noticed when most people came to me with issues it was because they were afraid or just too lazy or didn’t know they could just read the source code or docs and go one level under the abstraction to figure something out. 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.
  • CapstanRoller 3y ago
    What sort of jobs do you look for in order to be able to do this work?
• deadletters 3y ago
  Wow what a cool article I feel compelled to share my thoughts. > 338 comments. Nvm all good.
  • deleted 3y ago
    [deleted]
• gsaintj 3y ago
  I got fired for following this exact advice and could never get back into software development since. Explain that shit.
• EPWN3D 3y ago
  Here's the tl;dr: "Kids these days."
• iambateman 3y ago
  Suppose someone is a relatively well versed professional but they have a hole in their understanding…They don’t know X - where X is HTTP verbs or linear algebra or Assembly or the difference between Java and JavaScript or how to write vanilla JavaScript in general… 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.
  • frank_nitti 3y ago
    I think the more accurate analogy would be about the people who build and sell vacuums, not people who “plug them in” i.e. the end users. The technology that underlies vacuums is a lot more mature and stable than those that in modern software development. So even if modern-day vacuum engineer doesn’t understand AC at the same depth as their predecessors, it’s less likely to be the Achilles heel that the author is referring to for modern devs having little understanding of computer technology.
• anonzzzies 3y ago
  The future looks especially bleak because LLMs, for many who I work with, are doing with logic what Google did with memory. 'Just ask chatgpt' will be a thing ; maybe not chatgpt, probably indeed just google but with a their chatbot which can do 'logic' and abstractions built in. 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.
  • YoshiRulz 3y ago
    While I agree with you that programmers increasingly relying on LLMs would be (is?) a problem, there is an element of neo-Luddism to this, as was excellently framed by xkcd[1] some years ago. Could we not choose to fill all that time we used to spend writing code on testing/verification instead? Or on performance, or documentation, or security? Or, to go back to the premise of the blog, on re-educating ourselves in the tools we use every day but don't actually understand? I don't know how the industry will adapt and I won't bother making predictions, but the future doesn't necessarily involve everyone becoming mindless code monkeys. [1]: https://xkcd.com/1227 https://xkcd.com/1227
    • anonzzzies 3y ago
      But I think it will eventually end up in having less understanding of what people are doing, which won’t help us. And I don’t think we will become mindless code monkeys: I think we will end up telling the computer what we need in english but us having 0 clue or memory on how it achieves that. That’s the ultimate ‘too abstract’ issue.
  • Heyso 3y ago
    > ' Just ask ChatGPT ' Yeah I heard that from coworkers. Lazy mind, yes. Read the doc, look one example, check one stackoverflow link and you will know how you make a caroussel UI component... And please do not use it to try understanding some logic in your codebase. Try even less giving him a small snippet of the codebase, thinking it will magically understand what it does and correctly imagine what all the missing related code of snippet is and does. ( ! ) Most of the time I just wanna scream "use you brain". By the time he wrote his first sentence to the IA, I've resolved the issue, or at least have a clue. It is really infuriating because what more is that ChatGPT need a -minimum- precise request to be expected to give a useful response. When the request from the user is blatantly inprecise kinda like "help, thing doesn't work", I just feel bad for the IA having to deal with terrible communication, and for myself for having to deal with that coworker. Thanksfully when I am the one being asked help, I know the project, can look into the code, and coworkers can show me the issue instead of failing to explain it. Yeah that is why I like programming, computers only accept precise communication, it is not "move that div on the left" but "move div by id X to the left of itself" 120px over 200ms with a linear speed". Only once ChatGPT did better than my mind or google : someone was searching the name of a bank starting wirh the letter "o". Your statement is correct, google replace a lot of my memory, maybe someone could call me lazy too. Maybe ChatGPT will have his use for me one day.
• granshaw 3y ago
  “Everything in the tech industry is driven with a very hardcore eye for profit and very little interest in anything else” 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
  • notpachet 3y ago
    Not all profit is created equal. Sometimes in order to chase greater short-term rewards, you sacrifice your access to long-term rewards. Pushing your dev team into unsustainable practices may increase next quarter's profits, but might also mean that your company is bankrupt 2 years from now. I would amend what the author wrote to say that a lot of stuff is being driven with an eye for short-term profit, at the expense of long-term value.
  • deleted 3y ago
    [deleted]
• cratermoon 3y ago
  Speaking of failures traceable to levels of abstraction. "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. https://arnold.hosted.uark.edu/Other/ZarOde.pdf https://arnold.hosted.uark.edu/Other/ZarOde.pdf
• sholladay 3y ago
  So is the argument that everyone should be a mechanic? Including the long haul truckers, the race car drivers, stunt people, taxi drivers, etc? Such people use their vehicles professionally, full time. Obviously technical knowledge is useful to them in case of a problem or to fine tune their vehicle. But in general, no, being able to steer without a steering wheel doesn’t really do much for them. It’s okay to specialize at the higher layers of the stack. 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.
  • deleted 3y ago
    [deleted]
  • frank_nitti 3y ago
    That is a good point. What I take from the article as valid is the value of an engineer’s general attitude toward these matters. Having worked with a fair amount of devs who are very clever, but instead of having a sense of wonder and curiosity about the tech their systems rely on, they show a disdain for it. The kinds of fixes I’ve seen almost go into prod are scary, e.g. “the packaging system will not pack this 3rd party exe in with our code, so I’ll rename it to txt” - anything to avoid understanding the lower level mechanism and devise a sane solution. And management is thrilled because they deliver on schedule; engineers who protest the “working” approach are, at best, placated with a tech debt story in the backlog. Your comment and many others here start their criticism by conflating builders with end users - does every taxi driver need to be a mechanic? This comes off as a bit of a strawman since the author is referring to building software, not simply consuming it. If the person who designed my car is just selecting prefab components on the strength of blog posts and industry hype, with weak knowledge of how they are built, I’d be worried.
• carapace 3y ago
  I want to point out that computers in particular are just not that hard to understand. E.g. "Getting started in electronics" by Forrest M. Mims III ( https://archive.org/details/gettingstartedin00mims https://archive.org/details/gettingstartedin00mims ) covers gates and silicon down to the sub-atomic level, and it's suitable for a bright child. 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.
• arendtio 3y ago
  I don't think there is a maximum number of abstractions that is suitable. I think the value of an abstraction is defined by its quality. 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.
• nunez 3y ago
  see also: most Kubernetes tooling. 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)
• nunez 3y ago
  Have we? 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 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!
• invig 3y ago
  This is not just a problem in engineering. Read a news article. Talk to anyone about anything. The lifting that poorly defined abstractions are doing is toxic.
• xnx 3y ago
  I would love there to be a hands-on "History of Computing" class that runs through the history of computing (maybe starting in the 1970s?) through hands-on activities (through emulators probably) to give some perspective about how awesomely fast and powerful computers have become. This could also serve to expose where things have regressed (e.g. text editor and other UI responsiveness, complexity of the web stack). A version of this lesson could also be taught with video games to show though older games were visually simple, and just a tiny fraction of the file size, they were frequently just as fun. 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.
• xnx 3y ago
  We're in the tail end of a Cambrian explosion of new languages and frameworks. That explosion is understandable giving the huge shifts from mainframes to desktops to web/mobile/cloud. The TIOBE Programming Community index shows today's programming language use much less concentrated than it was 20 years ago. I expect a few dominant languages to re-emerge as the overall computing landscape stabilizes and LLMs make it low effort to translate entire systems between languages.
• harryquach 3y ago
  At the end of the day I need to pay my bills and if being an "API Monkey" is the way to do it so he it. There is more to life than knowing everything about writing software.
• Niksko 3y ago
  The author claiming that no single person can master development and ops and security is missing the point. By abstracting over some of the details of all of those fields, someone can be proficient in all of them, and therefore gain the perspective that comes from bridging those three separate but aligned skillsets. 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.
• timka 3y ago
  Lawrence Dickson. Anyone?
• rapjr9 3y ago
  I've been writing software since the early 1980's and I remember being pushed to get it working and thinking "they'll rewrite this and fix it in the future, this is just to get it working now". It's been terrifying to realize over the years since then that no one ever revisited the code and it still has not been fixed in many cases. Some of that code was used to control trains, nuclear power plants, chemical factories, medical systems, and satellites. I suspect some of it has been replaced, and ultimately it was the responsibility of the people building those systems to make sure they worked correctly, but poorer countries often stole software and a lot of it was still seeing use long after the product was no longer even sold. The world is in some cases hanging on a thread of old software that no one understands any more and no one is supporting. Source code may not even exist. 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.
• throw156754228 3y ago
  Some detail in the article would be nice.
• rldjbpin 3y ago
  i see many comments disregarding the take. while the arguments put forth may not be the strongest, but there is a point to this. 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.
• epalm 3y ago
  It’s not possible for everyone to know everything. Almost no one knows how to fix their <insert technology here, cars for example>, but at some point in history the opposite was true. Abstractions make technology available to the masses. 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”.
• throwaway689236 3y ago
  They serve a purpose.
• sharts 3y ago
  OP doesn't seem to realize that time is not infinite. Business demands require abstractions upon abstractions. If we're going to go down that path we should also understand the biological aspect of how atoms beget cells beget organs and organism to brains and then thought when then translates into creating the logic gates and machine abstractions on which we utilize code to translate thoughts into programs.