Reminds me of when we were admonished to use a "real" compiled language rather than an interpreted, GC'd one, lest we lose our ability to reason about the system, cache, and memory.
Which reminds me of when we were admonished to continue using assembly, lest our "real" skills atrophy from too much cushy C development.
Which reminds me of when we were admonished to keep our scope and probe skills sharp, and read and understand the schematics of whatever computer we were on, lest we forget how to diagnose faults in its components.
Which reminds me of when we were admonished to practice calculating in our heads and keeping slide rule skills sharp, lest they atrophy to a calculator.
You don't need to "keep practicing" in order to maintain your understanding.
The best engineers know how our systems work down to more levels, but for average developers producing average software with average impact, average output is acceptable.
[−]burner54828182 · 2026-08-30 Sun 16:03 UTC ·
link
Reminds of the time when we had to plant our own apple trees instead of buying them from the market, and to get up early at 1 AM to milk the oranges instead of just buying juice
>Reminds me of when we were admonished to use a "real" compiled language rather than an interpreted, GC'd one, lest we lose our ability to reason about the system, cache, and memory.
And they were right. People used in interpreted and GC ones lost most if not all the ability to reason about the system, cache, and memory.
Today's bloated "1GB RAM for a small form app" apps are the results of this.
>You don't need to "keep practicing" in order to maintain your understanding.
> People used in interpreted and GC ones lost most if not all the ability to reason about the system, cache, and memory.
It's not that they lost it, but rather that they never learned it. I didn't lose my ability to reason about those things during the 4 years where I worked in Python and Java.
And once again, for average software devs that's fine. Most non-critical software that doesn't perform very complex tasks can be optimized for time-to-market, which of course loses in other areas the business doesn't care as much about (such as bloat).
Average output is acceptable at work, sure, and if all you want is a paycheck then yeah I agree, make Claude write all your code, who gives a damn. This advice is for people who want to learn
This is a paradigm shift. If you know basic arithmetic, a calculator doesn't stop you from knowing how to add or multiply. But AI definitely stops you from learning how to reason. So it's not the same at all.
Which reminds me of when we were admonished to continue using assembly, lest our "real" skills atrophy from too much cushy C development.
Which reminds me of when we were admonished to keep our scope and probe skills sharp, and read and understand the schematics of whatever computer we were on, lest we forget how to diagnose faults in its components.
Which reminds me of when we were admonished to practice calculating in our heads and keeping slide rule skills sharp, lest they atrophy to a calculator.
You don't need to "keep practicing" in order to maintain your understanding.
The best engineers know how our systems work down to more levels, but for average developers producing average software with average impact, average output is acceptable.
In the snow.
Uphill.
Both ways.
And they were right. People used in interpreted and GC ones lost most if not all the ability to reason about the system, cache, and memory.
Today's bloated "1GB RAM for a small form app" apps are the results of this.
>You don't need to "keep practicing" in order to maintain your understanding.
You 100% need to.
It's not that they lost it, but rather that they never learned it. I didn't lose my ability to reason about those things during the 4 years where I worked in Python and Java.
And once again, for average software devs that's fine. Most non-critical software that doesn't perform very complex tasks can be optimized for time-to-market, which of course loses in other areas the business doesn't care as much about (such as bloat).
When that's not the case, you hire a specialist.