Friendly. Collaborative. Inspiring.
When you think of programming, do any of those words come to mind? Probably not.
When we talk about the accessibility of computer science – and technology in general – we often frame the our concerns in one particular way: How do we get more women in the industry? That's a problematic approach. For one, it suggests that women are at fault for simply not realizing the virtues of programming. It's borne of a paternalistic instinct: that we know what's best for you, and that if you only learn Java you'll make tons of money and find a nice man. This is obviously a poor way to change an industry, let alone human behavior.
Framing the issue in terms of proportions (between men and women) is helpful, because it gives us an objective measuring stick. But it's also a cop out. We give too much weight to that lone metric. We think that that once we meet a certain quota, we're good. The tech industry is off the hook. That's too simplistic an approach. What happens when we stop paying attention and the demographics revert back?
Recruiting is about more than advertising perks. Does anyone really think the promise of maternity leave alone is enough to inspire someone to change careers? To choose what she's going to do for the rest of her life, a person needs deeper motivation. Our goal shouldn't be to appear inclusive by recruiting inclusively, but to be inclusive in everything we do. It's got to be systemic.
Similarly, I see well-intentioned efforts to make computer science education more inclusive and accessible. But if so many people are struggling so hard to effectively teach these topics, is that a problem with the educators or a problem with the field? There's only so many ways to put a positive spin on bad news. Many people avoid coding because they find the languages, and the field in general, obtuse. But instead of tackling the root of the problem, we force students to adapt to the arbitrary and confusing approaches that already exist.
What if education and recruiting are only part of the problem?
What if programming itself is broken?
Imagine programming as a person. Someone you have a relationship with. Maybe it's friendly or even loving. But there's a good chance it's strained, even hostile. Sometimes a little of both. Imagine someone who…
- forces you to talk to them in exactly the right way or they will literally shut down on you
- reminds you literally every time you mess up, but stays silent every time you succeed
- complains about you without giving any suggestions about what you should do differently. You're left to guess and try a bunch of different things in an attempt to make it right, but you're not sure if anything will stick until it does. You often don't know why doing what you did fixed the problem, but it works so you keep doing it anyway
- forces you to read a manual before you even get to talk with them
- only allows you to do one type of activity (say, bowling) with them. If you want to do any other activity you'll need to find someone else
- lacks a sense of humor or fun
- just isn't friendly
Would you want to be friends with them? Well, no. If we wouldn't let friends treat us this way, why do we let programming treat us this way? It makes sense that so many people, including many women, aren't interested in programming. Now imagine a friend who…
- speaks your language – even if you have a heavy accent
- acknowledges your successes
- helps you learn and grow from your mistakes by suggesting instead of just criticizing
- makes the first move by suggesting things you can do together, even if you're not sure yourself yet
- has a spontaneous attitude – down to do anything, anywhere
- lightens up the mood and encourages you even when things are going poorly
- treats you like a human
You'll notice a vivid contrast between the frenemy we have today and the friend we want soon. To improve the situation, we need to fix our whole approach.
It's time to reinvent programming.
how do we fix it?
A few principles need to guide our efforts. First, we need to think from the perspective of the 99% – those who've never programmed in a meaningful way. These are the people we're trying to reach; we're empowering them to create amazing things. We also need to frame this in the context of the twenty-first century. The technologies at our disposal, and the kinds of things people want from technology, are almost entirely different from when most programming languages were developed – in the 60s, 70s, 80s, and 90s. It's strange that we're still using these technologies, and the methodologies that accompany them, to solve modern problems.
Step 1: Reinvent the language
A language – whether a human language or a computer language – is just a tool. It shouldn't determine what we say or how we think. It should stay in the background and facilitate rather than dictate what we're doing. So why do we let computer languages be so difficult to learn and use? And why do we keep around so many of them? The reasons are largely historical: they each served a different purpose, and they grew up organically, so no one really crafted the overall structure. Because anyone can invent a language, this is an opportunity to start from scratch. We know the various use cases we're trying to solve for, and we have carte blanche authority to craft it just how we like from the start.
We could delegate creation of the language to an engineer, who knows what's most convenient and efficient. But that would result in a very plain and uninspired language – one that gets the job done in the driest way possible, like almost all the other languages we have. Instead, let's find someone with a broader vision, and an appreciation for usability (not just efficiency). Let's get a designer to design this language. What they create will not only be expressive and intuitive, but it will appeal to those who've never programmed before. Designers should be as able as anyone else to express themselves through code.
Implicit in this talk about language is an assumption that languages must be textual. But that's only part of the story; historically most people communicated verbally (and were illiterate) or visually (because their written language was pictographic). Alphabets (where a single symbol can represent anything) severed the tie between meaning and appearance, and people (like me) who think visually have been struggling ever since. I thrive on diagrams, charts, illustrations, and photos. I appreciate typography, not text. And there are many people like me, for whom a screen of code is no more intuitive than a book of Arabic. It begs an obvious question: Why is code always textual? Why aren't there options to program visually? The question becomes even more urgent when we consider that most programs (or apps) today are intended for consumer use, not for use in the background or on a text terminal.
Some languages have adopted visual elements. Scratch presents text with formatting like colors and nesting. I used jGrasp in college, which provided visualizations of variables and objects. Although the feature was difficult to use, the concept was brilliant. And Quartz Composer presents animations as a storyboard, a much better way to understand something that's inherently visual. But Quartz only does animations. What I'm proposing is a general purpose graphical programming language. Photoshop made image processing as simple as clicking and dragging. Programming can and should be the same way.
With this new language, what's important is the user's intent. What are they trying to accomplish or express? The user will define the data model (which describes things they want to store and manipulate), and the behaviors they want to engage in. It's fundamentally an object-oriented approach, which I support because it conforms to how we think about our world. We think of objects we can manipulate (using functions) and that have certain properties (or fields). Given that most of our goods come out of factories, the notion of a template (or class) and individual objects make sense. The prevalence of object-oriented programming is actually a strong reason to make programming visual, because the two dovetail so nicely.
By communicating visually, and by communicating about intent, this abstracts the design and functionality away from the underlying code. It separates software design (which we can all do) from software engineering (which computers should do automatically). After all, isn't that why we have computers? To automate things? We only have software engineers because we haven't developed tools or languages to accept input from non-engineers.
Obviously, many engineers fear this simplification, because it threatens their fiefdom (and high salaries). No one wants to be replaced. But it doesn't make sense for us to keep writing the same code snippets (in different languages) and keep teaching one another the same programming techniques when we could spend that time removing complexity. It's time for humans to take control of language and craft it to our needs, not the needs of computers.
Step 2: Reinvent the tools
We have the right to design whatever tools we want. So why do we accept crappy ones? (Again, I suspect it's largely a matter of historical convenience and "Good Enough" Syndrome).
There's a ton that tools (like integrated development environments, which engineers generally use) could have that would improve the experience of programming. The most important is that the tool be friendly and empathetic. Those probably aren't words you've heard used to describe software, but you might be surprised. Sketch makes design software feel personal. And Paper, more than any tool I've ever used, enables serendipitous expression. Apps like these rethink the relationship between tool and artist, by putting the artist firmly back in control. They empower rather than hinder.
We often spend weeks or months reading a book before we dive into the code. Why is this? Is it really because we're not skilled enough to make something yet? More likely, it's because the tool is difficult to set up, and the language isn't welcoming to beginners. Here's an easy win. Just as games like FarmVille walk you through a tutorial when you start, and present a giant question mark in the corner of the screen for later questions, the tools we use should make it dead simple to get started. They should make introductions fast and practical, so you can get running on something appropriate to your skill level. I often find tutorials daunting, because they present way too much information, in a dry format, with way more technical detail than I need as a beginner. I can only guess how many people abandon tools because they never get a proper introduction. The tutorial, especially for getting started, isn't an optional feature. It must be an integral part of the programming tool.
The first improvement that any first-year college student will suggest is to introduce friendly error messages. Beginners, in particular, will find themselves simultaneously confused and frustrated by error messages, most of which are cryptic. Confused, because the messages are often unhelpfully vague or use overly technical language, and frustrated, because the tool doesn't provide any advice on what to fix or how to fix it. Strange, because if the tool knows what's wrong it surely knows what's right instead. I'm confident the people building this tools know how to make them simpler; they're highly skilled. But they probably don't realize or appreciate the struggles that beginners face. New programmers want feedback that makes sense in common English, and helps them avoid making the same mistake in the future. Actually, all of us want that. Whether it's a missing semicolon or a much bigger problem, we appreciate it when the tool helps us investigate and solve the problem. And when we (or thousands of people around the world) keep making the same mistake, the tool should notice that and provide proactive help to others in the future.
We use tools because they're helpful, but they don't always provide the right amount of help at the right time. This is especially true for new programmers who find themselves stuck. The most we can say is that tools will complete a line of code or add brackets - neither of which helps with the bigger issue of program design. It should be the job of our tools to notice perilous situations and provide help. If a programmer is opening the code editor for the first time ever, how about walking them through a "hello world" program? If someone made steady progress for 15 minutes but has slowed down, it might be time to help them debug. If someone is using an advanced feature when a simpler one will do, why not point that out? We put so much pressure on the engineer to know everything about the language, we forget that humans aren't even biologically equipped to remember so much, and nor is it an efficient use of our time and energy. (Again, we have computers to automate calculations and store large amounts of data, so we don't have to).
The most suggestions are ones that teach the user - about a new thing to try, or about an optimization for what they've already made. The computer is only half of the story, though. Good tools become great tools when you leverage a community of other programmers.
If you're trying to accomplish something that other people in the community have already done, the tool would suggest that. "It looks like you're making a login form. Do you want to use this form that Sam in Indiana made?" And instead of downloading their code and creating a separate copy, the tool would provide a way to reference it as if it were your own. In turn, you could share what you've developed with others.
What I've just described is programming as a fun, friendly, and engaging endeavor. One redesigned around users. Designed for everyone. Relevant to girls. Relevant to kids. Relevant to grandma. Democratic. Empowering. Productivity-boosting. Achievement-enabling. It's a style of programming that doesn't hold you back. That facilitates your expressiveness instead of hindering it.
It's programming for the modern day. Accessible to everyone.
If there's one (unfortunate) thing GamerGate has taught us, it's that people don't like change. They get territorial about their hobbies and feel threatened when other people try to democratize them. Then they lash out, to the harm of all involved. I'm sure some in the old guard of programmers will feel threatened by these ideas. They may dismiss them as unrealistic, or may retort that people just need to tough it out. And this old guard is entitled to their beliefs. It takes a while for people to get comfortable with new ideas. But make no mistake: programming is changing. It's becoming more accessible. You can't stop this tide any more than a judge in Alabama can stop same-sex marriage. If you have something to contribute, please do. But we will not wait for you to accept a world in which everyone can participate.
Existing programmers can be the most helpful group in this entire process, because they can build the tools that make it easier for everyone else to do great work. Don't be discouraged by the amount of work at hand. Even when it's difficult, know that it's quite possible to democratize complex things. We've democratized computing in general, which used to require knowledge of the command line. We've also democratized more specific areas like word processing, which used to be the domain of secretaries. We've democratized access to prototyping with 3D printers and maker spaces. If we've done all of this, surely we can empower a busy working mom to build a timer app!
The inevitable question: who will take this on? Google would be an obvious choice. They know how to make complex technologies simple for people to use. They strive to empower people to express themselves through technology. They're great about surfacing user-generated content, which would help build a strong library of reusable code. They invest heavily in open source through Chromium and Hadoop, among other projects. They've begun to think more holistically about problems, designing the software, the apps, and sometimes the hardware too. And, most importantly, their culture is open to this kind of experimentation and to the notion of increasing accessibility.
A few people have tried to make a universal language – or at least one that's more intelligible. These were either compromised in an effort to see public release, killed by lack of resources, or abandoned for lack of confidence in the vision and the idea that it's possible. And efforts to provide an end-to-end solution for programming have fallen apart for many of the same reasons. No company has seriously committed to making every component and making each perfect.
What if we try? What if we get together a few motivated individuals who believe deeply in this concept to guide it and protect the vision? And what if we get the backing of a community or an organization that's willing to build this out and see it go big?
It's impossible. And then we do it.