A developer who has just finished a video course on Go can usually pass a quiz about Go. They understand that errors are values, they can describe what a goroutine is, they know the difference between a struct and an interface. If you show them a piece of Go code and ask what it does, they can often tell you.
What they cannot reliably do is write idiomatic Go in a time-pressured context, without looking things up, while also thinking about the actual problem the code is solving. The quiz-passing knowledge and the code-writing knowledge are different things, and video courses mostly build the first kind.
Recognition versus production
There is a well-understood distinction in cognitive psychology between recognition and recall, but for developers the more relevant distinction is between recognition and production. Recognition is what happens when you see a concept and understand it. Production is what happens when you're in front of a blank file and have to write code that exhibits the concept correctly, without prompting.
Video courses are excellent at building recognition. You watch someone write Go error handling correctly, you understand what they're doing, you could identify correct error handling if shown two examples. You've seen it. It made sense. But you haven't written it under your own steam, with your own problem, where the decision about which pattern to use was entirely yours.
The first time you write Go error handling in a real PR, you will likely revert to the pattern that feels most natural, which is the pattern from your prior language. The Python exception model. The Java try-catch structure. You know the Go way is different, but under mild pressure, the reflex wins.
The fluency gap
Fluency in a programming language is the ability to write it without conscious effort. Not perfectly, not without looking things up, but without having to think through the basic decisions. When you're fluent in Python, you don't think about whether to use a list comprehension. You either reach for it or you don't, based on a pattern-matched sense of when it fits.
Fluency doesn't come from watching. It comes from writing, getting specific feedback on what you wrote, and writing again. The feedback loop has to be tight and specific: not just "this is wrong" but "this is wrong because of this specific concept gap, and here's the concept you need."
Video courses don't provide that feedback loop. The best ones have exercises, but the exercises are structured to be solvable with the material just covered, and they get checked against a correct answer, not against the specific concept gaps you're exhibiting. The course can't tell that your error handling in exercise 3 reflects a Python mental model rather than a Go one. It just tells you the output was correct, which it may well have been.
Why stack switching amplifies the problem
Video courses are weak for learning first programming languages too, but the weakness is somewhat mitigated by the lack of prior language interference. A beginner who has never written code doesn't have a Python reflex to override. They develop the language's natural patterns more readily because there's nothing competing with them.
Stack switching is harder, not because the new stack is harder, but because you're not learning from a blank state. You're an experienced developer with strong, reliable patterns from your prior language. Those patterns mostly work. They often produce code that runs correctly. The problem is that they produce code that doesn't look like it belongs in the new stack, accumulates friction over time, and signals to experienced developers on the team that the writer hasn't fully crossed over yet.
Overwriting those patterns requires producing them and getting specific feedback, repeatedly, until the new pattern becomes the reflex. Watching someone else produce the correct pattern does not overwrite your reflex. It gives you recognition. Recognition is not enough.
What actually works for stack switching
We're not saying video courses have no value. They are excellent for orientation: getting a broad map of a new language's major concepts before you start writing code in it. Watching a good video course on Go before your first Go PR is better than walking in cold.
The problem is that orientation gets mistaken for preparation. A developer who has finished a video course feels ready to write Go. They have recognition of all the major concepts. What they don't have is production fluency in any of them, and they don't find out which specific gaps exist until they start writing real code and getting real feedback.
The feedback needs to be on code the developer wrote themselves, solving their own problem, not a tutorial exercise. It needs to identify specific concept gaps, not just note that the code could be improved. And it needs to come close enough to the writing that the connection between the feedback and the code is still live.
A week-old code review comment about goroutine ownership lands differently than feedback attached to the line that caused the issue, delivered within hours of submitting the PR. The proximity matters. The specificity matters. The connection to your actual code, rather than a demonstration, matters.
None of this means the developer needs a dedicated mentor. It means the feedback mechanism needs to operate at the code-production level rather than the passive-consumption level. That's the gap video courses leave. It's also the gap we're trying to close.