I don’t think the causality is as clear or direct as you frame it, and I don’t think Dijkstra would agree with your framing either. I strongly expect it’s not about losing skills, but about never having the opportunity/requirement to gain the skills and knowledge (and never having to really internalize the lessons of the less-abstracted view).
I’ve been a professional programmer for a long time—starting well before there was the Internet. It was noticeably true in the late 80s that people who were incapable of writing and debugging assembly were not top-tier coders. It was true in the mid-90s that assembly was not the requirement, but C/C++ intricacy was a very good proxy for the mindset and attention to detail that made for good software. It wasn’t true by the mid-aughts—there were very good programmers in Java (but that sometimes included JVM bytecode debugging), and front-ends were getting complicated enough that it took real skill to be good at UI and apps. Throughout this “top tier coder” is doing a lot of work—there’s a HUGE amount of value from middle-tier coders, and that has increased over time as the abstractions have gotten better. This has led to a branching and specialization of what it means to be a “programmer”.
That branching matters a lot to this discussion. Once systems became fast enough and software infrastructure common/resilient enough, it made sense to have systems programmers be distinct from application developers, and then systems split into OS, compiler, platform, database, and application, and then further into middle-tier (“backend”) and user-flow (“frontend”), and has since specialized further.
It’s just impossible to say that one size fits all, even in terms of “how good a programmer” someone is. There are a bunch of different skillsets that matter at different layers, and it’s probably not possible for any one human to be good at all things. However, it does remain true that abstractions leak—to be great at any one thing requires a pretty deep knowledge and honed-through-experience instincts about the adjacent layers, and a shallower-but-still-real understanding more deeply.
Vibe Coding compresses this quite a bit—there’s a lot of layers that the controlling developer just doesn’t see, and that’s great until it breaks. It’s still the case that being able to actually line-level step through and debug things is necessary sometimes, and people who have ONLY vibe coded can’t do this (at least not efficiently/well—you need to do it hundreds of times before it’s natural). People who have done years of hand-coding CAN do this, even though it’s no longer very much of their energy (because vibe coding is so much more effective for 80% of things).
I’m not sure I have a point, other than there’s multiple dimensions here, and “able to do” is distinct from “does always”.
I don’t think the causality is as clear or direct as you frame it, and I don’t think Dijkstra would agree with your framing either. I strongly expect it’s not about losing skills, but about never having the opportunity/requirement to gain the skills and knowledge (and never having to really internalize the lessons of the less-abstracted view).
I’ve been a professional programmer for a long time—starting well before there was the Internet. It was noticeably true in the late 80s that people who were incapable of writing and debugging assembly were not top-tier coders. It was true in the mid-90s that assembly was not the requirement, but C/C++ intricacy was a very good proxy for the mindset and attention to detail that made for good software. It wasn’t true by the mid-aughts—there were very good programmers in Java (but that sometimes included JVM bytecode debugging), and front-ends were getting complicated enough that it took real skill to be good at UI and apps. Throughout this “top tier coder” is doing a lot of work—there’s a HUGE amount of value from middle-tier coders, and that has increased over time as the abstractions have gotten better. This has led to a branching and specialization of what it means to be a “programmer”.
That branching matters a lot to this discussion. Once systems became fast enough and software infrastructure common/resilient enough, it made sense to have systems programmers be distinct from application developers, and then systems split into OS, compiler, platform, database, and application, and then further into middle-tier (“backend”) and user-flow (“frontend”), and has since specialized further.
It’s just impossible to say that one size fits all, even in terms of “how good a programmer” someone is. There are a bunch of different skillsets that matter at different layers, and it’s probably not possible for any one human to be good at all things. However, it does remain true that abstractions leak—to be great at any one thing requires a pretty deep knowledge and honed-through-experience instincts about the adjacent layers, and a shallower-but-still-real understanding more deeply.
Vibe Coding compresses this quite a bit—there’s a lot of layers that the controlling developer just doesn’t see, and that’s great until it breaks. It’s still the case that being able to actually line-level step through and debug things is necessary sometimes, and people who have ONLY vibe coded can’t do this (at least not efficiently/well—you need to do it hundreds of times before it’s natural). People who have done years of hand-coding CAN do this, even though it’s no longer very much of their energy (because vibe coding is so much more effective for 80% of things).
I’m not sure I have a point, other than there’s multiple dimensions here, and “able to do” is distinct from “does always”.