sshine
Joined 12 years ago
Joined 12 years ago
Skill atrophy is when you're good at something, and because you don't practice it regularly, it gradually wanes over years, like when my former CEO said "I used to be good at programming" because he made a tiny chess computer and sold millions of copies, and now he... just doesn't code, and hasn't for decades.
Skill atrophy would be if I opened my text editor and I wasn't able to code after two years. Being a polyglot, there's always some language that feels rusty. And now they all do. But it hasn't been long enough to feel the atrophy.
What I'm describing is laziness to understand a problem domain.
> I couldn't imagine submitting a PR for code that I didn't understand and couldn't explain.
I could. I do it constantly for projects where that premise is acceptable. And I've worked on projects where many people merge to main once an established set of steps has completed. "How does it work?" and "Show me the thing working." are good gates. Understanding (or even reading) the code is not a mandated prerequisite.
As an Open Source contributor? No way. Exactly because I'm contributing to projects where people don't share basic premises. Some people code by hand, others use coding agents. If I were compiling stuff and everyone else was hand-writing their assembly, I'd read and tidy up my generated assembly, too.
> AI provides a great opportunity to learn at an even faster rate by using AI to help explain complex topics.
Totally. Better solutions come through those explainer sessions.
It is also both a choice and avoidable.
Atrophy happens when you trade understanding for productivity. Productivity benefits your employer and your KPIs, but not your understanding and your opportunities going forward.
Understanding used to be an unavoidable of the exploration process, and writing documentation used to be the thing that never got done. Now, writing documentation is automatic, but reading it still isn't.
I've been managing a team of interns at my last job, and as they were all equipped with coding agents, they'd deliver complete solutions to problems once or several times per day that would normally take days, or weeks if you factor in necessary learning.
As review of their understanding, and for the sake of my own cognitive debt, I would first ask them the question "How does it work?" and they usually couldn't answer. After a handful of tasks, they started preparing answers. This forth-and-back is still more shallow than getting the deep knowledge chiseled through hours of trial and error, debugging and wrong directions. Spending two hours to find a problem to realize you forgot to save or upload a file, or had an x instead of a y. I look back with nostalgia, and I wonder if there weren't always better ways, and we just get to pick them now. I can literally convert any task, solved or not, into a quiz that brings me towards understanding, in rainbow-colored pig latin.
> False Equivalence, Red Herring, Chronological Snobbery, Fallacy of Relative Deprivation, Contextomy.
There's a lot of reasonable arguments to unpack here.
But no, it's not that Louis XIV didn't have an iPhone, it's that the vast middle class in developed countries has central heating and access to penicillin and don't die from giving birth as much.
Also, America's poor are definitely worse off than medieval kings. They don't have access to those basic things that keep most modern people wealthier than medieval kings, like food, shelter and health care.
Some of the older (pre-medieval) king's ruins in Denmark are (by our standards) small stone houses with a moat, and what makes them remarkable is that they're made of stone, and the moat is rather big, so it keeps people out. Like metal doors in apartment buildings, sort of. (Correction for the historians: The oldest king's ruins are of course just holes in the ground where wooden beams used to stand.)
s/America's poor/Europe's lower middle class/ and you're there.
I don’t know if there’s any openly available statistics on how API costs divide between Claude Code, Claude SDK, raw API, and via OpenRouter.
And I agree, watching kids swipe feels, to me, like passive consumer induced computer illiteracy.
As long as you can’t fundamentally reprogram the device with your input method, you are at the mercy of other people. (And yeah, sometimes a keyboard is not enough, either.)
I have a somewhat expansive style guide, and it still reeks of Claude.
My cleanup is much closer to 40%, which still makes it worth the effort, but sometimes when speed matters, I'll apologize for the slop.
Paper is one such.
I'm less sure keyboards will stay to the same degree. My thinking was always the bottleneck while programming, so even though I can talk faster than I type, I couldn't solve problems faster than I type. But I can now.
So I'm opting for speech-to-text when the office space allows it, and looking into steno (stenography) keyboards, or perhaps building a steno overlay on my custom split keyboard to go from 80-100WPM to 200+WPM.
Prompt engineering!
Sadly, you learn that honesty is not the best choice always. And an honest answer is best given without too many priors.
I can't imagine how important it is to practice this when you deal with a terminal illness that grows over time. And how easy it might be to forget this, because you're exhausted.
I know, I know: It's complicated. But have you heard of AI agents?
But I just onboarded 4 interns on a project where all they had to do was
1. Install the Nix package manager
2. Install direnv, enter the project repo, and `direnv allow`
3. Toolchain, git hooks, MCP servers, in-repo issue tracker, everything is available
Our project manager requested information that was available in the issue tracker. I told her, she could get all her answers by asking our agent, and it'd automatically reference the issue tracker. I figured I'd just need to show her how to install the Nix package manager. But no, she already had it because another project by another team depended on it.Putting wrong information is README is so outdated when you have programmatic setup of your entire toolchain.
So picking languages for their compilation and especially runtime properties is key.
What I've learned, though, is that languages with reckless error handling produce more errors at runtime. My Rust programs just don't crash because I don't need it to be explicit about reaching a "total" approach.
If you're in a C# environment, I see a case for F#. And if you want fast but more solid than Python, why not Mojo? Although who reads code.
This article convinces me. But I suspect like my lack of domain knowledge of Lisp makes me spend time learning the runtime: how and when can I switch to JIT, what's the async story, how does the harness become part of the Lisp program, etc.
You did... what? You mean you asked AI?