I’ve been working back through the fundamentals lately, and the first thing it taught me was about me rather than about Python.
Here’s the thing that stopped me. If you’d asked me to name one fact about Python, I’d have said the GIL. Only one thread executes bytecode at a time, which is why CPU-bound work goes to multiprocessing and why “just use threads” is the wrong answer. I’ve said that in interviews. I’ve said it to engineers I manage. It’s been true for about thirty years.
It isn’t unconditionally true anymore, and it stopped being true last October.
What actually changed#
PEP 703, Making the Global Interpreter Lock Optional in CPython, landed as an experimental build in Python 3.13 in October 2024. You could compile with --disable-gil, get a separate python3.13t binary, and check at runtime with sys._is_gil_enabled(). Interesting, clearly a science project.
Then Python 3.14 shipped in October 2025 and made the free-threaded build officially supported. Not experimental. A real, supported configuration of the language, with the C API work done to go with it.
The honest caveats matter here, because the headline oversells it. It is not the default build; you opt in. There’s a single-threaded performance cost, roughly five to ten percent at 3.14. Most of the ecosystem still assumes the GIL exists, and plenty of C extensions will need work. Nobody should rewrite anything on Tuesday.
But the sentence I’ve been repeating for years now needs an asterisk, and I didn’t know that. I found out from a course aimed at people learning the language for the first time.
Why I missed it#
Here’s the mechanism, and I think it generalizes past me.
The further you get into leading, the more your ratio flips from writing code to reading it. That happens gradually and it isn’t a failure; it’s the job. But this kind of knowledge doesn’t get refreshed by reading code. It gets refreshed by the person who hit the problem, went looking, and found that the answer had changed. That stopped being me somewhere around the time my calendar filled up.
It’s worse for the facts you’re most certain about. I wasn’t going to go read the 3.14 release notes on threading, because I already knew how threading in Python worked. Certainty is what keeps you from checking. The things most likely to be quietly out of date are exactly the ones you’d never think to verify, because you learned them so thoroughly that they stopped feeling like information and started feeling like background.
So the language didn’t sneak past me. I left the room where it changes, for good reasons, and nobody sends a notice.
A different erosion than the one I’ve been writing about#
I’ve spent a run of posts on what AI does to skill formation, and I’d put this alongside them rather than inside them, because it’s a separate mechanism that got here first.
When I looked at what improved and what didn’t on my team after we started building with AI, production debugging was the capability that stayed flat. Same through-line: the things that erode quietly are the ones that only ever came from doing the work yourself, and nothing is watching them. Moving into management removes reps the same way, and it’s been doing it far longer than any model has.
The difference is that the management version is fully expected and nobody treats it as a problem. Of course the manager writes less code. That’s the arrangement. What’s easy to miss is that the arrangement has a maintenance cost, and nobody invoices you for it.
Why a curriculum and not a side project#
My instinct for years was that side projects were the answer to this. I no longer think they are, at least not for this particular failure.
A side project lets you route around your weak spots without noticing. You choose the stack, the scope, the parts that sound fun. Shaky on SQL? Reach for the ORM. Shaky on the shell? Stay in the editor. The whole appeal is that nothing forces you into the boring part, and the boring part is where the decay is.
A curriculum doesn’t negotiate. I’ve been going through Python, Linux, git, and SQL on boot.dev — deliberately the four things I touch constantly and therefore assume I’m fine at. Assuming you’re fine at something is the precondition for this whole problem.
I’d be overselling it to call this deep practice. Exercises aren’t production systems, and I’ve argued that the reps that build judgment are the ones done under real conditions. It won’t build judgment. What it does is hand you a diff against what you think you know, which is precisely the failure mode here: not knowing that you don’t know, in a domain you’d swear you were current in.
The disclosure, since that’s a tagged link: it carries a recruit code. No money changes hands and I’m not an affiliate. If you sign up through it and reach the Pupil rank, we each get a mythic chest, which is an in-game cosmetic. That’s the entire arrangement. Strip the query string if you’d rather not; the site is identical either way.
What I’d actually suggest#
Pick the thing you’re most confident about. Not the gap you already know about, you’d have filled that. The one you’d list on a resume without hesitating, the one you’d be mildly insulted to be quizzed on. Go check whether it’s still what you think it is.
For me that was Python, and specifically the one fact about it I was surest of. I’d been repeating a true-for-thirty-years statement about the GIL for a year after it picked up an asterisk, with total confidence, to people who believed me.
The fundamentals don’t hold still because you learned them once. And the better you get at the job that pulls you away from them, the longer it takes to notice they moved.
