Why one company is making all its employees learn how to code | Hacker News Reader

Why one company is making all its employees learn how to code

venturebeat.com

48 pointsjolie39 comments

A lot of people seem to be offended by this, or think it's a waste of time. I think you need to realize there's a difference between learning to code and being a professional programmer.

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?

A lot of people do claim it's worthless to learn math or, at an extreme, writing correctly. That's part of the problem.

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

All these comments about "no value" are hilarious. Honestly I dont think "serious programming" even matters. It's people learning, for example, that the 30 min daily process they do in excel can actually be a script that takes one second to run. The company is already seeing benefits to the culture and soon people will be thinking differently. That's a win.

I think that's equivalent to asking everyone to go to chef's school and describing the upside as 'People will realize that peeling potatoes can be done in a quarter the time they're doing it now!'

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.

MSM, I know it can be hard to see for many people but sometimes diving deeper into your box is the wrong approach. Your example is perfect. Someone went and took classes that were a "waste of time" and ended up 75% more efficient because they looked at something from a different view...even though they didn't become a chef. This is exactly how people need to be leading their companies.

If you do a lot of cooking, it would be a great deal!

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.

That's awesome. Imagine working in an all Spanish workplace and refusing to learn at least some Spanish. I think everyone benefits from learning a bit of the language. You don't have to be fluent but even knowing the slightest bit gets you a lot more respect. You can see this when visiting foreign countries. Understanding and writing code should be the basics.

Partaking in expensive management fads is, perhaps, God's way of telling you you've got more funding than you need.

I'm really uncomfortable with the term 'learning to code', because when I read it makes me think that the company wants its employees to know in what circumstances you should and shouldn't use semicolons in Javascript, or what methods are available to strings in Python.

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 hear you, but to take your apt analogy, I think the only way to understand software development is to go through the door of writing working code in some particular language. The goals may be bigger, but for people to get to them and understand them, they have to start by writing something, even if it's just "alert('hello world!')".

You would hope in the long term it would mean that everyone could write code that is relevant to their job, and automate tasks where possible.

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.

Maybe next year all the programmers can learn accounting.

Yeap. And marketing staff can learn HR rules.

Even better, they should also teach the HR team finance.

Wait until they teach everyone how to sell a product.

Actually...

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.

This makes sense to me for a number of reasons.

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.

Why not go the other way and make all employees learn about business and financial matters? Or would that be too dangerous, allowing for employees to become entrepreneurs and, possibly, lose them to their own startups?

Based on that picture, I pity the employees.

There's a big difference between learning syntax and learning to code.

Reply on news.ycombinator.com