Interesting, my path is a bit like the opposite. I tend to avoid categories of tools that abstract too much the problem in a "magic" way for the same reason: you can't easily understand what's going on behind the scene, and you have to dive in each time you enter a corner case. If you can't control what it is doing on each step, then you can't be sure it will be doing what you expect and this can become a mental effort that outweight the tool benefits.
True; in the same vain, tools that have more implicit and declarative philosophy - React, Kubernetes, most ORMs, Spring Boot - are also harder to understand and reason about for the same cause - you have to know exactly how the given tool works (new abstraction, magic) to understand what might happen at runtime.
We replace verbosity - since these tools are usually way more expressive than the thing they abstract away - with a new abstraction layer that allows us to type much less stuff but at the same time introduces a completely new cognitive complexity layer.
As always; sometimes they give more than they take, sometimes not ;)
C# is my Blub. I use Visual Studio (and not Visual Studio Code). I also use some T-SQL and JavaScript, and sometimes C++ on the weekends. In all of these, my understanding is still rather shallow. And for my day job, and most of my hobbies, it works.
But there is a definite next level I haven’t pierced, the level of “real programmers”. I want to understand the code I see on GitHub, even contribute. I want to be capable of more. But it is hard when I can’t even tell what I’m seeing, when I’m just trying to Make It.
Keep the curiousity up and learn your Fundamentals - things that do not change that often and on which most of our tools and frameworks are built. Dive deep into OSes, networks - build your own TCP and/or HTTP server, assembly and the machine code - how the CPU and memory works? As well as some algos and data structures for sure. These few things cover most of it ;)
I think this correlates more to individual culture and interest in general computing than anything else. As you said yourself, the 'lost programmer' isn't curious, isn't interested in the details. They are interested in getting their specific tasks done and collecting a paycheck. Many may have ended up in a field they are not excited about. That's not something you can fix.
As an aside, it will only get worse as the technical implementations get easier. Probably a lot of AI generated SQL queries being put into prod nowadays.
True; but I would argue that even if you don't care that much, when things don't work as expected - you pretty much always need to understand your tools and/or the layers of abstractions that are below. If you don't, not only you're going to feel lost, but you will not be able to solve certain set of problems
This is a case of the “everyone except me is an idiot” fallacy.
What actually happens with these people is they are pragmatically cargo-culting - because it helps them achieve some other aim, like delivering business value - until their abstractions leak and they have to go uncover the truth.
It depends; sometimes yes, sometimes not. In my experience, described phenomena certainly exists.
Nothing wrong with delivering business value - that's what mostly software is about after all; here, I am talking about pure incompetence and a certain approach that only reinforces it
You are assuming people are a still photograph of what you see in the fraction of a moment that it takes you to judge them, and they never ever change, not even after you’ve left and stopped paying attention.
That’s not how you work and it’s not how people work. It’s not how anyone works. Give others some credit.
Exactly; but, if you started from higher levels, it's never too late to go lower, step by step. I did exactly that and I highly, highly recommend doing it
On the other hand, if you have a 10-year-old who expresses interest in "computers", you probably don't want to teach him conditionals by showing him conditional jump instructions in x86 assembler. Maybe teach him BASIC instead of the latest trend in Javascript, but I think he would not be too comfortable or happy with assembler.
Interesting, my path is a bit like the opposite. I tend to avoid categories of tools that abstract too much the problem in a "magic" way for the same reason: you can't easily understand what's going on behind the scene, and you have to dive in each time you enter a corner case. If you can't control what it is doing on each step, then you can't be sure it will be doing what you expect and this can become a mental effort that outweight the tool benefits.
True; in the same vain, tools that have more implicit and declarative philosophy - React, Kubernetes, most ORMs, Spring Boot - are also harder to understand and reason about for the same cause - you have to know exactly how the given tool works (new abstraction, magic) to understand what might happen at runtime.
We replace verbosity - since these tools are usually way more expressive than the thing they abstract away - with a new abstraction layer that allows us to type much less stuff but at the same time introduces a completely new cognitive complexity layer.
As always; sometimes they give more than they take, sometimes not ;)
I do often feel like a Lost Programmer.
C# is my Blub. I use Visual Studio (and not Visual Studio Code). I also use some T-SQL and JavaScript, and sometimes C++ on the weekends. In all of these, my understanding is still rather shallow. And for my day job, and most of my hobbies, it works.
But there is a definite next level I haven’t pierced, the level of “real programmers”. I want to understand the code I see on GitHub, even contribute. I want to be capable of more. But it is hard when I can’t even tell what I’m seeing, when I’m just trying to Make It.
Keep the curiousity up and learn your Fundamentals - things that do not change that often and on which most of our tools and frameworks are built. Dive deep into OSes, networks - build your own TCP and/or HTTP server, assembly and the machine code - how the CPU and memory works? As well as some algos and data structures for sure. These few things cover most of it ;)
I think this correlates more to individual culture and interest in general computing than anything else. As you said yourself, the 'lost programmer' isn't curious, isn't interested in the details. They are interested in getting their specific tasks done and collecting a paycheck. Many may have ended up in a field they are not excited about. That's not something you can fix.
As an aside, it will only get worse as the technical implementations get easier. Probably a lot of AI generated SQL queries being put into prod nowadays.
True; but I would argue that even if you don't care that much, when things don't work as expected - you pretty much always need to understand your tools and/or the layers of abstractions that are below. If you don't, not only you're going to feel lost, but you will not be able to solve certain set of problems
This is a case of the “everyone except me is an idiot” fallacy.
What actually happens with these people is they are pragmatically cargo-culting - because it helps them achieve some other aim, like delivering business value - until their abstractions leak and they have to go uncover the truth.
People grow and learn when they need to :)
It depends; sometimes yes, sometimes not. In my experience, described phenomena certainly exists.
Nothing wrong with delivering business value - that's what mostly software is about after all; here, I am talking about pure incompetence and a certain approach that only reinforces it
You are assuming people are a still photograph of what you see in the fraction of a moment that it takes you to judge them, and they never ever change, not even after you’ve left and stopped paying attention.
That’s not how you work and it’s not how people work. It’s not how anyone works. Give others some credit.
Similar to Chesterton's Fence.
We should probably learn CS from the least abstraction to the highest.
So that when the abstraction breaks, we know where to look to understand why.
Exactly; but, if you started from higher levels, it's never too late to go lower, step by step. I did exactly that and I highly, highly recommend doing it
On the other hand, if you have a 10-year-old who expresses interest in "computers", you probably don't want to teach him conditionals by showing him conditional jump instructions in x86 assembler. Maybe teach him BASIC instead of the latest trend in Javascript, but I think he would not be too comfortable or happy with assembler.
Why not? You can also teach electronics first, that's way more hands-on than writing code on the computer.