I keep encountering this attitude among programmers, that the idea of "learning" is something that is the completion of a journey of worthiness. It's extremely disappointing.
Instead of them respecting my job more, they come to respect it less because they think they can do it just as well as I can. They think they're perfectly capable of forming time estimates because they insist "they" could do x task quickly, despite the fact that they're clueless about architecture, refactoring, documentation, testing, etc. They have no conception of why spaghetti code is bad, or what it even is.
Of course, this is all probably due more to management problems than anything else, but it is a very good example of "a little knowledge is a dangerous thing."
And as for the French analogy: I've known people who claim to speak French and then get themselves into hairy situations due to misunderstandings because they greatly over-estimate their skills and are overconfident in what they "think" they understood. It's equally infuriating.
There is a big difference between being "decent" at something and truly knowing it as "an extension of self". Expertise is a real thing.
It does, however, take grit, because there's a ton of documentation to read, particularly concerning rendering settings.
I think the implication is that it's obnoxious when people equate "learning a little French grammar and vocabulary" with "learning to speak French". Similarly, many of these pop-tech articles don't appear able to differentiate between "learning a little JavaScript grammar and vocabulary" and "learning to program". (I'd bet that the principals at the companies mentioned do know the difference, but they have an obvious incentive not to emphasize it to the press or to their potential customers.)
For example, these people are learning to code, but they're beginners so they won't be very capable. They'll struggle with most concepts, have to be reminded about syntax, and kind of think the computer is "magic". If they get through a few basic books then, yes, they "learned to code". If that's all they wanted to do, then they've done it and now they have a better understanding of computation and the things they work with all day.
After that, maybe some of them move on to build things, figure out the computer is not magic, learn a few more languages, pick up techniques, and generally continue the path of "learning to code". At that point you have a wider range of phases they'd go through on the way, but they are still doing what the phrase says. Maybe none of them will ever reach a professional level, some may master it and never do it as a day job.
After a year or two of learning to code, you can build things of minimal value. If they're of any reasonable complexity, though, they'll probably be terribly structured and difficult to maintain. To truly become effective, it really does take many years, with lots of things that can really only be learned by experience.
As for math even something as simple as being able to make change quickly is both useful and in demand.
1) Before I knew how to program computers and programming seemed very mysterious and magical to me. Giving everyone a basic understanding of what your company actually does is a good thing. At the very least it will improve communication. It might help non-developers set more realistic expectations, etc.
2) Even "business types" can benefit from knowing how to program, even if they won't be writing user-facing code. Many business applications have scripting engines built in. Being able to take some data and transform it or calculate some statistics will help them do their jobs better.
3) Designers/UI/UX people who can program are incredibly valuable. They know what the technology is capable of, and will design with that in mind. Often they can produce working prototypes, or even production code.
Some employees will probably just learn the basics and decide they don't really care for programming, but others might embrace it and become much more efficient at what they do.
I'm a non-technical co-founder, but I'm learning to code. Along with all the other obvious advantages already shared in this thread, there is an intangible benefit that my technical co-founder appreciates.
It's hard to measure, but my interest in coding communicates a deep level of respect for him and his contributions. Contrast this with the classic "Whartonite Seeks Code Monkey" type. Which type do you want to work with?
Learning to code should be celebrated and encouraged. Nobody loses.
In my opinion that type of person is not going to be a good boss no matter how much or little they know.
I think for a more humble person though, the ability to create small programs is empowering and makes them far more effective in any job involving computers. And going through the debugging process, and dealing with the growth in complexity in their programs, helps them understand the problem software engineering seeks to solve.
The ideal organization purges itself of the former type of person and teaches the latter how to code.