Better Tools For Programming Literacy 317
waderoush writes "Adam Wiggins, co-founder of Heroku, agrees with anthropologist Bonnie Nardi that programming isn't just for geeks. The problem, he says, is that today's tools for teaching programming are woefully inadequate. In a commentary, Wiggins argues that there are two major gaps preventing programming tools from being accessible to beginners: 1) they're too fussy, requiring extensive setup, and 2) they're focused on the technology rather than everyday tasks. A good tool for learning programming, Wiggins argues, would emulate an Excel or Google Docs spreadsheet – beginners would be able to fire it up instantly, and would be able to get useful things done right away. (He's dismissive, though, of visual programming tools that 'attempt to hide logic behind a point-and-click interface.') 'Broad programming literacy is crucial in a world increasingly made of computers,' Wiggins says. 'Despite common stereotypes, programming is not out of reach for the average person,' as long as the tools are easy to set up and specialized on the programmer's task."
Yes, it is out of reach (Score:5, Informative)
People can't program the VCR clock. (For the young ones: Back in the old days we called the Tivo "VCR". Just like everything must have a camera today, back then everything had to had a clock, and it had to be set manually.) You can barely teach (most) people algorithms that aren't completely linear. If you think you can teach them to develop algorithms, you need to get back in the trenches and deal with normal people. Developing programs means to understand problems in depth and to correctly answer a lot of "what-if" questions about complex systems. Normal people actively try to avoid doing that kind of thinking.
Pure Data (Score:5, Informative)
Re:So what they're really asking for... (Score:5, Informative)
Re:What is it with this idea nowadays (Score:4, Informative)
bullshit. some don't admit it but there's a hurdle to start programming, knowing where to start.
it can be as simple as sitting down with someone for 30 minutes, showing them how to write a bash script, save it, make it executable and run it. 10 more minutes for the idea of looping and a few more giving them a list of good sites to read when they're trying to figure something out.
6 months later I get an email from the guy asking esoteric questions about specific frameworks and has become his offices translator for when the needed to ask for software.
You are everything that's shitty about the industry. I'm glad I don't have to work with anyone as toxic as you.
Re:Pure Data (Score:4, Informative)
Although it can be very complex when you dig down into it.
This is the problem with trying to simplify ("abstract") anything; you make the simple things easier and the slightly-less-than-simple things nearly impossible.
Something Microsoft also excels at in their products. As soon as you leave the narrow area of what they expected you to do, configuring Windows gets more cryptic than Linux kernel programming. You should always make things as simple as possible, but not more than that. This is one example of where the limit was crossed. With that, people are tricked into thinking they understand the problem, when in reality they do not. This prevents learning, realistic self-assessment and will produce any amount of fundamentally broken software.
Re:I agree that programming is not for geeks (Score:4, Informative)
I'll give it a shot.
There are two primary contributing factors to problems with respect to badly written software. One is that it's generally difficult to look at the software externally and determine its quality. I'm not an automotive engineer, but I can look at a 1980 Chevette, take it for a test drive, and determine that it was built from duct tape, bubblegum, and staples, and was not a well made vehicle. The same is less possible with software, which often doesn't offer those externally visible clues; and it's even more of a problem for non-developers to see its quality (or the lack thereof.)
The other half of the problem is that providing solutions of any kind (not just software) enable further external dependencies upon those solutions. The fact that it's a software solution may make some people believe that it's reliable in ways that it is not.
For example, a beginner programmer might write up some home automation code that turns on a light when the garage door opens. They might then extend it to make it dial a phone and play a recording when a button is pushed. And that's absolutely a great thing, because the kid is starting to learn.
The problem starts when Uncle Joe, who is not a software engineer, says "that's really neat, now give that button to Grandma so that if she falls she can push it and we'll go help her out." But the beginner's software might have a hidden fault that causes it to only execute when the garage door is open, which it was throughout its limited testing. What has been created is a program that externally looks good, and so it gets reused, but has had insufficient testing and is in no way well-engineered or ready for production use. And nobody involved in the project understands that until it's too late.
Not recognizing that the software is bad, someone then created an external dependency on that bad software. Grandma might fall when the garage door is closed, she pushes the button instead of dialing the cell phone because she believes the button will work, and instead goes unrescued for too long.
This is of course a contrived example, but it's amazing how much bad code is woven into so many different places in the real world, with so many dependencies on it. And once you add those dependencies, it's often very hard to change them. Believe it or not, I've heard the management equivalent of "We can't take the button away from Grandma now, what if she falls again? It makes her feel better."
This is not saying its bad for people to create software. What is bad is that people don't understand that what they've created is of low quality.