End-user computing
Bonnie Nardi is an anthropologist who studies interactions between humans and computers. In 1993, she published her first book, A Small Matter of Programming. The book's thesis is bold and simple: every human being can, and should, learn to program computers
The book didn’t get much attention outside of academia and is now long out of print. I picked up a secondhand copy in the summer of 2007, just as I was working on the initial prototype of Heroku. The ideas from this book have inspired and haunted me ever since.
Universal literacy
It’s commonly assumed that there is a divide between "geeks," who can program, and "normals," whose use of computers is limited to using software created by the geeks. But is this the case? Let's consider a parallel situation from history: the written word.
A thousand years ago, writing was a technology enjoyed by an elite few: rulers, clerics, scribes. This technology offered the power to store information with more permanence than human memory, to pass such information between people, and to archive it for future generations.
The invention of the printing press in the 1400s made books widely available, and literacy spread. Today, literacy rates exceed 90% in most of the world. Not everyone is a novelist or English professor, but almost everyone can read street signs, write down a grocery list, or send a text message.
Programming as literacy
We increasingly live in a computer-embroidered reality, and the ability to manipulate that reality is empowering. If we can find a way to bring that ability to a wide audience, it could have an impact comparable to the invention of the printing press.
This is end-user computing. “End user” means everyone: people like you, me, your friends and family. We all use computers in our daily lives to accomplish both work and personal goals. When those end users can write and run their own programs, they will have fully harnessed the power of computing.
I'm far from the first to address the topic of programming as literacy; see Programming is the New Literacy and Computer Programming for All: A New Standard of Literacy for two recent examples. But while the renewed interest in this topic is exciting, the methods proposed are often nothing but wishful thinking, and the true challenges of programming literacy are rarely addressed.
A Small Matter of Programming, though two decades old, contains hard research on the real benefits and obstacles to end-user computing. Surprisingly, these findings are just as relevant today as when they were written. Programming-as-literacy enthusiasts should take a close look.
Two gaps
The research presented in the book demonstrates two major gaps that block programming accessibility. These gaps are in the tools, not the teaching process. What we’re missing is 1) no-fuss setup, and 2) task-oriented tools.
Gap 1 – No-fuss setup
Professional software developers favor composable tools that can be combined in a customized stack according to the developer’s taste. Consider the number of tools in a web development environment: language runtime, code editor, revision control system, webserver, database, web framework, dependency management tool, templating language, test harness, and more. The bewildering array of choices often proves defeating to beginners.
The lengthy setup instructions for Ruby on OS X or PHP on Ubuntu illustrate this, each with many pages of error-prone manual steps and incomprehensible jargon. A newbie programmer cannot run even the simplest program without having invested many hours struggling through this setup process.
Even worse, the budding programmer is often pressed to make many choices: what IDE? what language? what database? Experts want choice; newbies want to be handed an integrated product where good choices have been made for them and they can dive straight into their task.
Beginners would be better off with a single integrated tool that they can install (or access on the web) and use to begin programming immediately.
Gap 2 – Task-oriented tools
I recently demonstrated the simplicity of programming to a friend of mine by showing her how to write a short Ruby script. "That's cool," she said. "But what would I use this for?"
Her response demonstrates the second gap in programming accessibility: too much focus on the technology (e.g., programming language) and too little focus on the user’s task.
The first few chapters of nearly any introductory book on programming illustrate this mentality. The focus is on topics like syntax and data types, rather than what meaningful tasks the reader can accomplish with programming.
Most laypeople don't care about computers; they care about what they can use a computer for. They learn how to use a given computing tool so that they can share vacation photos with their family online, write a term paper, or check the value of their stock portfolio.
It follows that most people will only care about computer programming when it offers them a clear way to accomplish specific goals that are relevant to their lives.
The spreadsheet
To date, there has been one pervasive success for end-user computing: the spreadsheet. Spreadsheets fill both of the end-user computing gaps:
No-fuss setup: Install Excel or sign up for Google Docs and you can start your first spreadsheet with a single click. There are no lengthy setup instructions and no decisions to make.
Task-oriented tool: The spreadsheet’s appearance instantly identifies it as a ledger for entering and doing calculations on columns of numbers. A user firing up a spreadsheet for the first time can immediately imagine the tasks they might use this for: totaling line items on a receipt, calculating interest payments on a home mortgage, or tallying up hours worked during a week.
Spreadsheets are specialized on basic accounting. This specialization is reflected deeply in the domain-specific language used to program them. SUM() is usually the first function a spreadsheet user learns. That function performs one of the most common tasks in basic accounting: totaling a column of numbers.
Compare the ease of SUM() to the amount of code needed to total an array of values in a programming language like Java or PHP. In those general-purpose languages, the programmer will need to understand concepts such as loops, arrays, and variables in order to perform this task.
Visual interfaces
Another appeal of spreadsheets is that they are visual: users see their data laid out on a grid. Variables are named for the value's spacial position on the sheet (for example, A1 is the upper-left cell). Code is entered into cells, where it executes as soon as the user leaves the cell. The results of the recalculated spreadsheet are plainly apparent.
Visual interfaces are more discoverable and less intimidating. Bret Victor's fantastic Learnable Programming illustrates how visual elements can improve discoverability and usability while still putting code front and center.
Note that neither spreadsheets, nor Victor’s examples, attempt to hide logic creation behind a point-and-click interface. Purely visual programming is a red herring, and history is littered with the corpses of products that have attempted to offer programming without code.
Other end-user computing successes
While the spreadsheet is the only end-user computing tool to reach the mass market, there have been many successful products in more specialized domains: Industrial designers use scripting to automate AutoCAD; statisticians visualize data with tools like Matlab; and businesspeople build database apps using tools like Filemaker Pro and Microsoft Access.
These tools all share the same two golden traits: no-fuss setup, and a programming language and development tools focused on the specific tasks their users want to achieve.
Codecademy doesn’t focus on the task
Software developers are passionate about their craft and many, like me, would love to see more people gain basic competency with programming. To that end, a number of online learning resources have appeared in the last few years: learn-by-doing apps like Codecademy and Code School, courses from Khan Academy, and tutorials for kids like Hackety Hack.
But while these efforts are well-executed and well-meaning, I question whether they put us on a path toward broad programming literacy. Learning to program for its own sake, rather than focused on a task the student wants to achieve, suffers from the problem of attracting only people who are already interested in programming.
Codecademy courses are named for technologies like Javascript and Python, instead of tasks students might be interested in, like creating a website or a game. Khan Academy's courses are named for a task – digital drawing and animation – but it may be unclear to the average person why one would learn to program for this, when a non-programming tool like Photoshop does the job just as well.
A different way to learn
An alternative to the Codecademy-style approach is tools focused on programming with a particular task in mind. For example:
Many teenagers spend a huge amount of time on Facebook. How about a way for teens to build their own Facebook apps, where the program lets you traverse your social graph with just a few lines of code? Just as spreadsheets offer SUM(), a social programming tool could give you functions like my_friends() and my_photos().
Home automation is easier than ever with devices like the WeMo. How about a product that allows homeowners to attach scripts to household devices? Parents could write scripts to control their kids' access to the TV, adjust the thermostat, or the feed the pets via an automated food dispenser.
I learned to program because I loved video games as a kid and wanted to make my own. How about a toolkit for kids to make games for their iPad or Xbox that allows them to easily share the games they’ve created with their friends?
In each of these examples, the tools must be incredibly simple to set up. If at any point the user needs to download and install Python, choose a text editor, or configure a database, then the jig is up before it has even begun.
Conclusion
Broad programming literacy is crucial in a world increasingly made of computers. If we can make programming a part of the end user’s computing experience, it has the potential for impact on par with the invention of the printing press.
Despite common stereotypes, programming is not out of reach for the average person. If the tools are easy to set up and specialized on the programmer’s task, programming can be a small matter after all.
Thanks to Sarah Day, Wade Roush, and Mark McGranaghan for help with this post.
