You seem to be hung up on the part about "learning". Do you know how x86 registers work? Or atomic instructions available on ARM, SPARC, or POWER architectures?
No, of course not. Because all of that got abstracted to higher-level instructions decades ago.
> Do you know how x86 registers work? Or atomic instructions available on ARM, SPARC, or POWER architectures?
Yeah, I have a pretty good idea of how we go from code -> IR registers -> x86 registers and how the underlying hardware has more registers than that, etc.
As for SPARC and POWER, I have not yet gotten my hands on one! But as someone who writes compilers for fun I did learn about most of that, yes.
I write C# in my dayjob, and having written high-ish performance C++ and Rust for a couple years before that, and because of all the curiosity-driven projects I've done (like writing useless compilers), I did learn a lot.
This has helped me massively in my job, especially when optimizing our C# sensor data ingestion backend to process hundreds of thousands of measurements per seconds with explicit backpressure etc. it was great fun because I know what I'm doing.
I'm not trying to "uhm actually" you, but when you call yourself a software engineer, I do expect that you know some of these things after some years in the industry. The only way you wouldn't is a lack of curiosity, or because you genuinely had no idea that you CAN learn these things.
Yes, I do. And it wouldn't take you that long to learn, either.
Well that's great for you. That's some knowledge that you will possess for the rest of your life.
I want a green lawn and big bushy shrubs in front of my house. Do I need to know the intricate biology of my soil and habitat? No, of course not. I just do the surface-level things that make the lawn and shrubs thrive.
>No, of course not. I just do the surface-level things that make the lawn and shrubs thrive.
And others want the green lawn and big bushy shrubs, but don't want to learn all of the surface level things to make their lawn thrive so they hire a service to do it for them. And there's nothing wrong with that - not everyone enjoys the yard work, but they still want the thriving lawn and shrubs... and they are happy to write a check to OpenAI... err...Lawn Doctor every month to get that result since the time they save by not dealing with their lawn, they can pursue things they do want to do.
Not everyone wants to (or needs to) learn every detail along the way of getting the results they want.
I understand your point, but also imagine applying that across the whole spectrum of computing.
It's very useful that there's an intermediary that knows how that stuff works so I can build things without thinking about it in excruciating detail the whole time, I can dip down lower and learn stuff when it's relevant (like cache access and nested arrays) but I can also not do that in many situations.
There's also the argument that you can do engineering without understanding the underlying science as seen in th pyramids, the beautiful old european churches, etc
Who is more productive? A python dev who learns about x86 registers in his free time or one that uses AI at work?
The one who uses AI at work will eventually be replaced by someone cheaper who uses AI at work.
The one who learns about x86 registers is much more likely to continue to evolve
More productive? If the result can be trash, of course the AI work wins. In industries where quality and performance BOTH need to be upheld, knowing these details lets you guide the LLMs in a way that they will simply never do by themselves, and lets you meaningfully review performance critical code.
This reduces the cycle time on issues and reduces bugs and performance regressions. If I pitched that last sentence to your boss, chances are he'd take it.
But maybe there's a limit to the usefulness of this abstraction. Perhaps forgetting too many basic skills lower down isn't always as useful as going from Assembly to C. I'd argue that there's a law of diminishing returns there, and it's not an endless series of benefits.
[dead]