Should We Really Try To Teach Everyone To Code?

theodp writes: Gottfried Sehringer asks Should We Really Try to Teach Everyone to Code? He writes, "While everyone today needs to be an app developer, is learning to code really the answer? Henry Ford said that, 'If I had asked people what they wanted, they would have said faster horses.' I view everyone learning to code as app development's version of a faster horse. What we all really want — and need — is a car. The industry is falling back on code because for most people, it's the only thing they know. If you want to build an application, you have to code it. And if you want to build more apps, then you have to teach more people how to code, right? Instead, shouldn't we be asking whether coding is really the best way to build apps in the first place? Sure, code will always have a place in the world, but is it the language for the masses? Is it what we should be teaching everyone, including our kids?" President Obama thinks so, telling Re/code at Friday's Cyber Security Summit that 'everybody's got to learn to code early' (video). But until domestic girls (including his daughters) and underrepresented groups get with the program(ming), the President explained he's pushing tech immigration reform hard and using executive action to help address tech's "urgent need" for global talent.

Comments

We need to teach people to think, and to use tools

[mtrachtenberg]

Ah, the computer, that magnificent "universal machine."

Have you ever watched as someone tries to take information from, say, Microsoft Word, and use it to do mailing labels? Especially if the information has been formatted to be "pretty." Let me tell you, it ain't pretty.

We don't need for people to learn to "code." We also don't need for people to learn how to use particular proprietary products. We need for people to learn things like basic math, basic logic, and understand how they can use computers, with a teensy bit of effort and understanding, to accomplish their unique and specific tasks. We also need to teach people that they should not feel helpless when confronted with a computer program that doesn't do precisely what they want.

I feel a bit Mao-ish on this subject, and truly think the best solution would be to issue a voltage surge to all existing infrastructure, and not allow anyone to buy any replacement computers until they demonstrate an understanding of their jobs (not the computers' jobs, the individual workers' jobs).

Re: skynet

[garyisabusyguy]

Yup, that is how it is supposed to work. In the best case you work through the roles, use cases, develop screen mockups and a data design (usually don't show that to customer, but it should support the screens and use cases)

However, on more than one occasion I have run into a scenario where the customer will have a single requirement (this would be for an insurance interface)
1. Create insurance interface that meets requirements set by insurco

Then they will include an attachment that demonstrates the line format for the output

The following conversation goes like...

Dev: Let's work on the process flow for adding insurance, dropping insurance, changing insurance tier (add/lose dependent etc)

HR Customer: It's in the attachment

Dev: Can I contact a rep at insurco to find out how they handle these cases?

HR Customer: No, I am the only contact to insurco, everything must go through me

Dev: Okay, but I need to be ready to handle the business cases, so will you please walk me through it?

HR Customer: QA already signed off on my requirement document, so you have to accept it

This continues ad absurdum through an entire dev-test cycle with full customer acceptance testing and the day that it goes into production...

HR Customer: It's broke, you failed because it does not do what we need it to

Eventually we find out that the HR data entry people use multiple different ways to drop coverage, many of which the HR rep was not aware of.

Long story short, I end up learning HR's job better than they do in order to deliver anything, with them complaining about my delivery and demanding that I be removed for insubordination...

This happened years ago in a waterfall based dev shop. I have worked earnestly since then to apply Agile, prototypes, fast turnaround for approval and (usually) taking the time to learn the customer's job because they do not know it themselves

Simply getting the customer to accept logic, admit they do not know everything and get out of my way would help