I'm not sure I agree with that but that's because I'm not sure I believe in the original premise.
I've long thought (and advocated) for the fact that what we call 'coding' is actually, and importantly, two separate disciplines. In some venues and arenas these overlap but the overlap isn't perfect or 100%.
I will try to outline my take on it - the two disciplines I really see out in the world, and this for me holds true no matter what language, what environment or what I'm doing.
1. Programming
2. Coding
The former is the art of thinking through a problem, outlining the steps required to solve that problem. It is an act of logic, one of abstractions and formalisable proofs. The latter is the art of expressing it in code.
I've seen people who are absolutely astounding at the former, who can think through all the permutations and possible edge cases that could occur, but that when it came time to actually write it as code, it was messy, it was inconsistent, it was borderline sloppy in some ways. Meanwhile I've seen people that can write the most elegant, the most beautiful code but it never survives contact with users or reality because they've not thought through all the consequences and the edge cases, and it ends being a nightmare patchwork of code and duct tape to make it work.
This is why I see them as separate disciplines, that have some intersection but the nuance behind the difference is important.
And this is why I disagree with the osmosis. It certainly teaches you coding style, it teaches you what other people do and how they have implemented a specific solution to a specific problem, but it rarely ever talks about either 1) *why* they solve it a certain way and 2) what problems they had to think through to arrive at that solution, assuming it wasn't just handed to them.
In the worst case (and tragically most common), this produces a strange dogmatic logic that we refer to as cargo cult behaviour. Things are done a certain way without any understanding of why, merely 'because it is so'. Because it's always been done this way. The problem with *that* is that if you're always doing it that way because you always did it that way, you'll always do it that way ever more, *regardless if it is the correct course of action for the situation*. Worse still, over time if this is persisted, it reaches a point where anything that cannot be done the way you've always done it... it's impossible.
I have heard the 'it's impossible' so many times over my professional career. I don't think a single time has ever been because it was actually impossible. I think my favourite was about 8 years ago, I'd joined a small company working on their SaaS product. For the largest customer, you'd log in and it'd take a full minute to load the dashboard. Now, I had other things to do when I first joined so it was a few weeks in when I finally heard about this and I had a quick chat with the devs. "It's impossible to fix, we've all had a go." was the refrain. I asked for a couple of hours, to see what I could make of it. In that two hours I had gotten it down from 60 seconds to 5. Not ideal but well within everyone's level of acceptable... and it's not because I'm magic or because I have some special knowledge or anything like that - but because I'm not entrenched in 'this is how it must be done' to the point where I can see alternatives to all the things.