sshine
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
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?
It would, of course, be easy to say "But that's not the fault of monorepos! Clearly, 50GB is a nonsensical amount of source code, and clearly someone committed something they shouldn't have in the past."
But also, with monorepos, the probability of that happening to the repo you use the most is the cumulative sum of all of its projects, since more people's potential git mistakes now happen in the same place.
For the sake of comparison, nixpkgs is 4.5GB right now. It hosts ~140.000 packages, ~12.000 open PRs, one million commits, yadda. So when you reach ten times that size with, presumably, less traffic, I would consider cleaning up the history.
Polyrepos can definitely work; I use them extensively in open-source. I also wouldn't be doing that without Nix flakes all over to chain them together. And even then, I have constant drift because one repo is pinning an old version of another repo, and once I bump the pin, things break lazily.
The biggest benefit, by far, you get from monorepos, is eager evaluation of your dependencies.
I get that there’s cognitive debt. Some just seem to never even pay interest or get a basic understanding of the domain model.
My suspicion is that these people were always lazy programmers, but now they can take the laziness to a point where, after weeks of working on a project, they don’t get the basic vocabulary right.
I just want to say: #notallvibecoders
By the time you’re “at scale” (who knows), and all these monorepo at scale problems start to overwhelm, you can switch strategy, because the economy of polyrepos is so obvious by then.
So far, I’ve started a new job a handful of times by collapsing a premature polyrepo strategy: people were not experienced enough to merge two git repos without a common root.
I’ve only once went the other way, and it incurred so much overhead, it decreased developer productivity by some small but not insignificant percentage.
To be clear: I’m not a maximalist. All of my open-source work is exceedingly compartmentalised. My DNS library is separate from my external-dns webhook is separate from my fork of external-dns. They could all live in one repo. But FOSS encourages reusability, commercial software encourages clumping and vendoring.
Sounds like unbounded, dynamic allocation to me!
Here's an AI-generated pull request I made, but you wouldn't know because there's no slop:
https://github.com/numtide/devshell/commit/a67c0f87b63bcbdbd...
It got merged by someone who is too busy to respond to personal emails.
"Don't waste my precious attention" is only getting more real.
Points of no return.
I run NixOS, work with Kubernetes, code Rust, use a 40% split, layered keyboard with Dvorak layout and open source firmware, kaj mi parolas Esperanton.
They're just hobbies that, once you've sunk the hours in, they're awesome.
I don't actually type faster. Or maybe I do type a little faster because it made me use all 12 fingers instead of the ad-hoc 7-finger system you taught yourself in primary school, but typing was never a bottleneck, and split keyboards actually hurt my wrists more.
Jujutsu is marginally better than git, but costs time. If you like to spend the time, it will probably make you a little better. If you care deeply about your time, and it's already being allocated for anything but arbitrary intellectual pursuit, it's not worth it. Some people grow businesses, plants, or sedentary habits.
"for all" / "there exists" instead of "every" / "there's at least one"
"let" as an imperative for establishing facts
"fix" for choosing a value
"given" instead of "if"
"modulo" instead of "except for"
"if, and only if," when the occasion warrants it
"implies" instead of "means"
"trivial" without intending to be mean
"yes" when asked an "or" question
"transitively"
"by symmetry"
"it follows"
"canonical"
You can say a lot with few words when you have rich definitions.
I don't cringe when I know it went through their head, because they didn't literally copy-paste it.
It's just a side-effect of immersion. It's exactly a tic, and I don't frown when people tic.
Economists say "all things equal" (which they're never outside of economic models).
My vanity compels me to not use Claude's linguistic identity. It gets sooo boring.
And in spite of reading hours of Claude every day, I don't sound anything like Claude.
Maybe I'm not as impressionable as Nolan. Maybe I'm less aware of my own words.
I was cultivating a "make an effort when you write" mental space, and this area only got stronger in my brain with Claude.
I suppose it's a fight to preserve my own linguistic identity. Or maybe I have enough monologue to keep the pressure out always.
Also, unrelated, I already had one of Nolan's blog posts open in my most recent tab. It should prove a thing or two about authentic human voice.