I see "programming" as a skill like "writing" or "basic math" that everyone should know something about. We all know how to write and do some math but we don't call ourselves "writers" or "mathematicians".
But you'd never claim it's worthless to learn how to write or do arithmetic. Why not programming?
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.
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.
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.
It's just... why? These people aren't going to be doing any programming daily. Why don't you take all that money, and all that time and let each non-programmer go to a deep dive conference of their choice for whatever their discipline is. Seems like a much better use of resources.
These people may not be doing much programming daily, granted. But programming is just the means, not the end: the end is to work with information. And everyone in an office setting works with information. Becoming even a little more efficient with large amounts of information is a great benefit, and only requires a tiny bit of programming aptitude.
You can think of it like learning to touch-type: invaluable even if you only do typing tangentially to your real job.
I don't think those things are useful unless you're actually writing code.
What is useful is understanding how software (and, for a lot of people, web software in particular) fits together. That means understanding what might make something computationally expensive, or understanding the advantages/disadvantages of loosely coupled components (etc etc).
This isn't to say that people 'learning to code' isn't a step in the right direction, but I don't think it's an end in itself, and for most people, writing code is only a doorway to that understanding if they have the time to take on projects that involve those problems.
What we need isn't lots of people who can do 'hello world'. It is people who are technologically literate. That needs to be the focus and goal.
I suspect this company is just trying to spread awareness throughout the company of what the coders do. But there must be countless efficiencies available in business, especially non-tech businesses, if people were able to automate.
If it were up to me, the aim would be to have secretaries and receptionists, sales staff and (non-software) engineers all able to write scripts to aid their work, in whatever language or environment was most relevant. Even if you start them off with Python tutorials so everyone can learn the basics together.
Making all programmers experts on accounting is a hopeless task. But what if we taught everyone (including the programmers) enough about accounting to understand why we would care that some of their time qualifies as "capitalizable" and some doesn't and what difference it makes? I think that basic level of understanding would be beneficial to everyone.
1) This can help people understand the tools that could assist them with their normal day jobs as hey gain the confidence to look into writing scripts and macros. IT staff in particular frequently lack any coding (scripting) skills unless they themselves are developers or Unix sysadmins.
2) They will have a better understanding of the web technologies they run across in their daily lives. This applies especially well to Codecademy users who learn JavaScript. 3) Learning to code teaches you to break a problem into parts and think analytically. Our society could use more people with good critical thinking skills, we can probably all agree.
4) Everyone in an enterprise should have a core understanding of the elements of major functions. Yes, this means programmers should understand the very basics of finance and human resources and probably other areas that don't occur to me at the moment.
There are two kinds of elitism: believing that decisions should be made by the most informed and qualified individuals versus believing that those who do not belong to the "elite" have no business even dabbling in affairs beyond their supposed comprehension. The latter isn't healthy to any organization, much less broader society.
