Bringing Programming Out of Its Temples

If everyone should learn to code, code needs to change

2013 may have seen a tipping point for the popularity of programming. Even people who aren’t programmers are suddenly arguing that it’s a good idea for everyone to learn programming. Computers are now everywhere, traveling with us, common in places where they would once have seemed an extravagance, and it seems obvious that we need to be able to do more with them.

Anil Dash looked beyond the basic vision of teaching everyone to code this week. Dash leads with President Obama’s encouragement of computer science as part of this week’s Hour of Code project, and his suggestions to young Americans:

“Don’t just play the latest video game. Make one.

Don’t just download the latest app. Help design it.

Don’t just play on your phone. Program it.

(It’s not just the President—it’s House Majority Leader Eric Cantor too.)

It is, of course, harder than that. I love Dash’s piece, which reflects on the value of code, the challenges of crossing tech culture boundaries, and the need for tech culture itself to support and make more valuable such efforts at democratizing coding. I shared it on Facebook, happily citing the part about:

we have to embrace the idea of blue collar coders. If we succeed in bringing all of these new young people to the tech industry, we’re going to necessarily undo the image of programming as the exclusive domain of a rarified coterie of high priests. Instead, we have to see it as a useful trade that is a meaningful path toward the middle class for those who are struggling to get there, akin to the blue collar trades that honorably served that purpose in the last century.

Then, I returned to my usual technology programming, and crashed into a story about the perils of “not an A-grade software developer… haven’t completed a formal Software Engineering or Computer Science degree. You have meddled with computers enough to be dangerous…” (It’s far from unique—just a good example I happen to have close at hand.)

Okay, then. I get that people on an XML list can be unhappy when people don’t follow all the rules XML claims to have established. I’m reminded of the years where people looked at me, puzzled that I thought JavaScript had a future as a programming language and not just a tinkering tool. I get that programmers have their hierarchies, and that some tasks demand formal engineering approaches and years of experience just as some tasks in the physical world demand that.

Over the last two decades, though, computers have shifted from being computational devices to being devices for communications. There are still complex situations in those communications, particularly computationally intensive issues like media compression and massive scale. Fewer and fewer communications issues, though, need the kind of skill set that used to be expected for programming. More and more projects need a deep understanding of tasks rather than a deep understanding of code.

However, many programmers seem stuck in a past landscape where the demands for code expertise were considerably higher. Programming languages were tightly bound to the internal structure of the computers, requiring humans to change the way they approached solving many kinds of problems. Resources were limited, and logical optimization the supreme directive. Programmers had to keep vast amounts of information about their program in their heads, because there was no easy place to keep track of it. Testing and debugging could make the invisible visible, but were themselves difficult skills to master.

Despite that resistance, I think Dash’s vision still points the way forward. As business becomes more and more dependent on moving bits from place to place and analyzing them, the cost of separating code creation from the people who use the code is going to become more and more visible. It is possible that programming processes will become more adept at collecting requirements for users and responding to them, or that programmers will find better ways to let their users customize processes, but it seems more likely to me that more people are going to end up coding.

We already have a model for that, though I’ve long enjoyed the gasps from programmers who don’t consider it real programming. Electronic spreadsheets started out with extremely simple logic but have grown more and more capable over the decades, connecting with more advanced code when needed. Spreadsheets provide all kinds of opportunities not just to process data, but to make the calculations and intermediate values observable. Chris Granger of Light Table has a brilliant talk about the challenges of programming not being very observable, but it strikes me that spreadsheets offer at least the possibility of opening the door. They’re also quite capable, if not necessarily efficient. As my friend Ben Rothfeld says, “Give me a spreadsheet wide enough and a monitor to put it on and I could tabulate the world.”

My father was not primarily a programmer. He modeled large business processes for generating investment returns into the future over ten year periods with custom programs. Then, he marveled that they ran so well on luggable Compaqs. Today, those calculations and iterations can run within a supporting spreadsheet including necessary formulas. It took long experience with the business processes to construct the earlier model and generate the calculation, and it takes continuing experience with the process to put in the right production adjustments and data to make sure the results continue to reflect reality. While it’s critically important to get the core logic right, the long-term maintenance and growth of such tools requires regular user feedback. Processes and productivity are altered periodically causing changes in the inputs and outputs of the spreadsheet as well as its results

The need for user connections to software goes beyond modeling, though. Part of what attracts me to flow-based programming is its division of labor between those creating components—largely calculations and transformations—and those assembling them. The first group of people still needs to know all the details of making code efficient, while the second group needs far less of that. Both groups still need to understand the underlying logic of the work, though.

Looking forward, I’m not sure that the spreadsheet grid is flexible enough to deal with data that isn’t tabular, and though spreadsheets are used constantly for communications, that isn’t quite what spreadsheets do. I can’t help thinking, though, that the long-term answer to democratizing code looks more like a spreadsheet than it does traditional text-based code.

Can we split the work this way? Can large numbers of programmers get used to the idea of creating specialty modules, the “hard part”, in ways that are meant for people who code but aren’t necessarily programmers? How much complaining will there be about shifts toward interfaces that make “everyone should code” a reality, and will that complaining make it impossible? Whole categories of programming may have to shift (or disappear) for democratization to work.