If English is your second language and you write code for a living, the advice to "just listen to your docs on the commute" is backwards for you specifically. The exact thing that makes you understand dense English text — stopping, backing up, rereading the sentence, hovering over the word you half-know — is what audio takes away. For a native speaker, going audio-only mostly costs some convenience. If you're reading in a second language, it can cost you the meaning itself.
To be clear, this isn't the claim that non-native speakers can't learn from audio. The point is narrower. For a native speaker, the line between "read this" and "listen to this" tracks concept difficulty. For a second-language reader it tracks language difficulty instead, and the two lines fall in different places. A blog post on a topic you already know can be easy to follow by ear even when it's conceptually meaty, while a single dense RFC sentence can be impossible to follow purely because of three words you haven't automatized yet. The line that matters for you is the language one, and it's worth finding where yours actually sits.
What rereading is actually doing for you
When a native speaker reads a tightly-worded section of an RFC or a database manual, they hit one bottleneck: the concept. When you read the same passage as a second-language reader, you hit two. There is the concept, and there is the language carrying it — an idiom you haven't seen, a phrasal verb ("the lock is handed off to"), a noun-stacked compound like "write-ahead log replay throttling" that you have to parse before you can even start thinking about what it means.
Reading lets you pay both bottlenecks separately and at your own pace. Second-language reading research has a name for the move you make constantly without noticing it: regression — the backward eye movements where you re-fixate on earlier words. Studies tracking eye movements find that second-language readers regress substantially more often than native readers on the same text, and that those regressions are doing real work, not wasted motion. You reread the clause, you resolve the ambiguous word, then the meaning lands. Lookups are the same mechanism, just slower: you pause, check what `idempotent` or "starve" means here, and continue with the sentence intact.
Audio removes both. There is no regression in a stream of speech — the next sentence is already arriving. There is no pause to look up the word you didn't catch, and you often can't even tell which word you missed, because you never saw it spelled out. It's the audiobook experience of a thriller, where missing a word costs nothing, applied to a paragraph where one missed word ("unreachable" vs "reachable") inverts the meaning.
A concrete one-minute example
Take a real sentence from the kind of doc you read: "A goroutine that blocks on an unbuffered channel will not be descheduled until the receiver is ready, so fanning out without a bounded worker pool can starve the runtime."
Reading it, a second-language engineer can do this in stages — parse "descheduled," confirm "starve" means resource starvation not hunger, notice "unbuffered" is the load-bearing word, reread once, done in maybe twenty seconds. Heard once at normal speed, that sentence is gone in four seconds, and three of its most important words ("unbuffered," "descheduled," "starve") are precisely the ones a non-native listener is least likely to have automatized. You will retain "something about goroutines and channels" and lose the actual rule.
The deceptive part is that it feels fine in the moment — you followed every word as it went by — and the gap only shows up later, when you try to apply the rule and can't reconstruct it.
Where audio actually helps
None of this means audio is useless to you. It's one of the better tools you have for listening fluency, which is a real and separate weakness for most ESL engineers. You can read well above the level you can comfortably listen at. Standups, conference talks, a colleague explaining an outage on a call — that is all listening, and the only way to train it is by listening. So audio is still worth using. It just belongs on different material.
- Read with your eyes for anything where the wording is load-bearing and unfamiliar: API references, RFCs, the spec, the database manual, the security advisory, the part of the design doc where a wrong reading ships a bug. This is where both bottlenecks fire at once — new concept and new language — and where regression and lookups earn their keep. Listening to it feels like multitasking but mostly degrades how much you take in.
- Listen to material whose vocabulary you already own: an engineering blog post on a topic you understand, a "lessons learned" writeup, a vendor's explainer, a newsletter in your domain. These aren't shallow; the difference is that the words are ones your ear can already catch at speed, so missing a sentence costs you little and the time doubles as listening practice for the standups and talks that demand it.
How do you decide which pile something goes in? Importance alone won't tell you — plenty of important things are written in language you've already mastered. Ask two questions: would reading one sentence wrong change what I build, and are there words in here I'd have to look up? If both are yes, read it. Otherwise listen, and let it double as ear training.
How we'd actually use it
This is the case we'd point an ESL engineer toward. Sending an easier field-adjacent article to @OutloudAIBot and listening on a walk is good practice: natural-sounding narration at a reasonable speed, on material loose enough that your listening can carry it. We wouldn't tell you to pipe your `man` pages or a dense RFC through it and call it studying. The voice is good, but no voice gives you back the reread.
There's a useful second-order effect, too. Once you've listened to enough easier articles that your ear stops dropping common words, the rereading you do on the hard docs gets cheaper, because you're spending your regressions on concepts instead of on decoding basic vocabulary. The two habits reinforce each other, as long as you keep them on the right material: listen to the easy stuff, and read the docs that can't be wrong.
So when someone tells you to "just listen to your docs," follow it halfway. Listen to the article you'd have skimmed anyway, and read the one you can't afford to misread. The skill worth building is judging, for whatever's in front of you, which one your understanding actually depends on.