I would bet hard money that even an experienced developer wouldn't learn C in a year (e.g. avoid or recognize most UB and security issues) without prior exposure. I'll grant that C is pathological in that respect though.
Learning a language and mastery are separate things. An actual experienced dev should be able to hit "competent" in any new language within weeks so long as it's within the same family of languages they've used in the past. Procedural languages, like C, are pretty much squarely in the middle of what everyone has learned unless by some fluke they started and continued with Haskell and similar languages and never touched any of: Go, Rust, C#, Java, Javascript, Lua, Python, Perl, Ada, Pascal, Fortran, Matlab, BASIC (various forms), and a hundred other languages.
You would probably not want someone with little experience in given language, to touch production codebase without review, because there are always traps that you might've not encountered in other languages.
I typically don't touch low-level programming languages, but once I had to use C to write some small adapter to communicate with some Oracle product. I did it, it worked as expected, but I would not be able to use it efficiently for complex solutions without more experience with creating and managing solutions in C.
I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.
I never said otherwise. This is part of the distinction between competence and mastery. I would not expect most people to master a new language in just weeks, but a senior developer should be able to be competent within weeks. Now, would they have a product or substantive (non-trivial) change to show after those weeks? Maybe not, that might take a few more weeks, or longer if it's larger in scope.
> I can also write in Go with some basic proficiency, I felt confident at one point in my abilities, but when my code got reviewed by someone specialized in Go, he would propose several improvements that did not cross my mind, because I had less experience in Go.
That's part of learning, but it probably didn't take you a year to learn enough Go to get something in a reviewable (if not passing review) state.
I wouldn't want anyone, in any language, with any level experience to touch production codebase without review.
Not even K&R themselves.
So that's a ridiculous straw man.
Everyone makes mistakes. And code review is also about knowledge sharing and avoiding single points of failure in staffing.
This feels like a town cop enforcing strict speed limits in the couple of miles that fall in their jurisdiction. If K&R show up at your door and want to touch your production code, you just let them, bring them coffees, and ask for autographs. Even if it breaks, it would be an amazing story.
As we all know, the subject of UB and the practical ramifications of particular instances is a topic few people could reasonably learn in weeks or even months.