[capkutay]

I'm having trouble understanding what "learn to code" means for most people. It's almost obnoxious when business types propose "learning to code" in a nonchalant manner as though people don't spend decades developing their programming skills. Yes, you may take codecademy tutorials and have a slight understanding of js syntax...but I wouldn't expect you to build anything of value.

[nudge]

Do you feel the same way about learning to speak foreign languages and play musical instruments? Is it obnoxious for a person to teach introductory French night classes, when fluency will take years and may never be possible for the students given their other commitments? What if it is not even likely that they will ever have French-language conversations "of value"? Does the very act of proposing learning this new skill insult French speakers everywhere?

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.

[crazygringo]

I don't know... but I've had coworkers who are not professional programmers, but who wind up "helping out" with programming on the job, and I desperately wished that instead, they didn't know a thing.

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.

[BryanB55]

Exactly. I don't know why I've been hearing this so much lately. I've been researching about learning to use 3D software (3dsmax) and I get the same responses that I hear about learning to code: "oh it is very difficult and it will takes at least 5-10 years to be able to build anything of quality" Personally, I think if it takes you 10 years to become decent at anything, then you are doing it wrong.

[sopooneo]

I don't know. I think some things can legitimately take some people ten years to learn, even if they are doing it right. However, my disagreement is that sometimes learning something at a cursory level, even if it doesn't allow you to do quality work, can be worthwhile. It can give you insight and appreciation of the discipline and help you work more effectively with the people that really do it. It can also be fun and make people feel proud to just be able to do it a little.

[joelhooks]

2-5 years with 3ds should definitely put you in the "decent" category.

There is a big difference between being "decent" at something and truly knowing it as "an extension of self". Expertise is a real thing.

[arijo]

If you find the 10 year rule absurd, take a look at this paper: http://graphics8.nytimes.com/images/blogs/freakonomics/pdf/D...

[MaysonL]

Then again, there's no speed limit: http://sivers.org/kimo

[jarrett]

Just a quick datapoint. I've used 3dsmax casually (free, academic version), and I managed to produce some images of which I was quite proud. They weren't magnificently detailed scenes, but they were photorealistic representations of the objects I was modeling. So no, it definitely doesn't take 10 years to get to the point where you can make something meaningful in 3dsmax.

It does, however, take grit, because there's a ton of documentation to read, particularly concerning rendering settings.

[mhartl]

Is it obnoxious for a person to teach introductory French night classes, when fluency will take years and may never be possible for the students given their other commitments?

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.)

[zedshaw]

Part of the problem is you're trying to understand a classification that's fairly broad (learn to code) in terms of your narrow definition vs. their narrow definition. It's too broad of a term, so it's better to just say "learn to code" means the whole spectrum, then get specific about what they actually can do.

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.

[BryanB55]

I've been hearing this argument a lot lately. Are you suggesting that if I wanted to learn to code it would take me decades to be able to build anything of value? To me learning to code is just like learning any other skill. Sure you wont be good at it the first few months you start but that is what practice is for. I don't see why in a year or two you wouldn't be able to build something of value. If it really took 10 years to be able to build anything useful I doubt there would be that many coders. I can't really think of any skill that takes 10 years to become good at.

[crazygringo]

Umm... piano? violin? lawyer? doctor? mathematician? I could go on...

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.

[Retric]

You can become a medic in a few months which is not a doctor but still able to save peoples lives in a wide range of circumstances. As to musical instruments learning to play the bugle call takes a while but not decades. You can learn some basic piano songs to play at parity's fairly rapidly assuming a reasonable level of dedication.

As for math even something as simple as being able to make change quickly is both useful and in demand.

[Mgccl]

I guess it depend on how one sees something to have value. There are mathematicians only consider research level mathematics have value. There are some subfield of mathematics like algebraic geometry that take years for a math grad student to even understand the language, and takes even longer to produce research paper with value.

[tlrobinson]

Certainly I wouldn't expect most of them to be writing production code, but there are other benefits.

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.

[AVTizzle]

Conversely, what better way for a non-coder to show genuine appreciation for a technical individuals talents, than by showing that he/she is an engaged student of their craft?

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.

[justjohn]

It seems unlikely to me that the business types will do much serious programming; after all that's not what job is. I suspect the real value of this will be improved communication on technical subjects. It's much easier to work with someone (like an engineer) when you have a common baseline and can appreciate the work they're doing. It's also a fantastic learning opportunity for the engineers, since teaching/mentoring people on a topic is one of the best ways to improve your knowledge of it.

[jordanb]

I think it depends on the person. There's the "a little knowledge is a dangerous thing" type person, where the acquisition of some terminology and the creation of some toy programs leads the person to believe that they've mastered the domain and can start telling people what to do.

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.