Enabling the Next 50 Million Developers

Debunking the myth of being born to code

Smartphones are bringing another 5 billion people online; we’re going to need tens-of-millions of new developers to help build products and services for those new users.

To increase the diversity of developers, we in the developer relations community must increase the variety of our content, presentation styles, and delivery mechanisms

Users and developers are coming from increasingly diverse backgrounds, so our programs need to reflect that variety in order to grow and remain inclusive.

Different Approaches for Different Developers

Growing up, whenever a new piece of electronics entered my house I’d want to plug it in and start playing with it until I’d figured it out. My dad though, as methodical as you’d expect a Swiss expat to be, he’d carefully read the manual from cover to cover before even plugging it in. It drove me crazy.

Not that it takes much. Pair programming makes me want to stab my eyes out to give my programming partner a fair chance as I attempt to bludgeon them to death with the keyboard — and it turns out some people find pair programming really useful, so my experience isn’t universal. Which is kind of the point.

For me, coding has always been an exercise in exploration. The idea of writing code had my curiosity in the 5th grade when I could write code to control the Turtle robot. It had my attention in the 7th grade, when I discovered I could change the dialogue in Granny’s Garden with a few lines of BASIC. Since then everything I’ve learned has been because I need to know it for whatever project I’m playing with.

Unfortunately, if you look around and see a lot of people with the same backgrounds and educations, it’s easy to conclude that anyone who learns differently from you isn’t as smart, or is less advanced.

But not everyone is inclined to learn how to code on the fly. Others feel like that’s setting out on a road journey heading downhill in a car chassis on wheels, getting ready to build the engine, steering wheel, brakes, and airbags if and when they become necessary.

That difference in approach has a deep impact on how we use resources to learn new technologies. I’m always looking for an answer to the most immediate problem, while others are looking for a more guided or structured approach.

It’s not a linear scale where different approaches work at different stages of a developers career:

The wrong approach

It’s a matrix, where the depth of content changes as your experience grows, but that’s independent of your preferred learning approach:

A better approach

If we want to expand the diversity of engineers, we need to embrace these different learning styles.

The Developer Origin Mythology

My own programming history looks like this:

I started programming in BASIC when I was 11, before completing an honors degree in Computer Science at the University of Western Australia. I then taught myself Delphi working on a project for my first job, C# .NET doing the same for my second job, and Android in the weekend after the beta was released so I could write a blog post.

As part of my career I’ve interviewed hundreds of engineering candidates, and while the details vary, the pattern is familiar: A first class university taught understanding of core CS concepts like algorithms and data structures, bookended with self-taught practical skills based on an innate passion for coding and years of hacking on “real” software projects.

There’s nothing wrong with that background — but the lack of variety has led to the pervasive myth in our industry that coding is something you’re born to do and have pursued your whole life.

To paraphrase Christopher Nolan (if The Dark Knight Rises were a movie describing the origin story of a brooding software developer rather than a crime-fighting vigilante):

“You think software is your ally? You merely adopted engineering. I was born in it, molded by it. I didn’t see a UI until I was already grown, by then it was nothing to me but blinding!”

This mythology is a big part of how many of us identify ourselves as developers — but the simple problem with this belief, is that it’s bullshit.

Now, it’s not untrue for everyone — I remember the summer I first learned to program in BASIC, holidaying on Rottnest Island with friends, complaining that I wanted to get back home to write some code — it’s that it’s not true for everyone, yet as an industry we tend to present it as the only legitimate path.

That makes it far too easy to over-optimize our learning materials for people who learn the same way we did, which excludes talented future developers with different learning preferences, and creates an environment that actively discourages every would-be-engineer who didn’t realize their passion for code until they were out of high-school — or who didn’t have the good fortune to grow up with a computer and an internet connection.

Let’s start by assuming the entire audience is smart

There’s a lot of people trying to make computer science education more equitable. Programs like Code School, Hackbright Academy, and Udacity, are demonstrating different ways to find and train a more diverse set of engineers, and are uncovering a world of talented developers — every bit as talented and passionate as those of us who followed a more familiar route.

And that’s a Good Thing, because if we want 50 million more developers we can’t expect they’re all going to start coding in grade school and go on to graduate from Stanford with a CS major.

I could write another article on new approaches to making STEM and computer science education more broadly available, but I don’t want to derail too far. Professionally, my focus is ensuring that once new developers have learned the fundamentals of computer science, when they arrive at Google’s developer sites, they can find the resources they need to continue their learning in whatever style they’re comfortable with.

Take a look at Android. The Android Developer site has always had great docs and samples, and StackOverflow is a rich resource of answers to specific problems. Over the last year we’ve been adding increasingly rich video on YouTube for developers who are more engaged by watching or listening to people than by reading walls of text.

What we’ve generally lacked is a more structured approach to advanced learning; our new Android Fundamentals course with Udacity is an attempt to rectify that.

We set out to create a guided online course that’s advanced and technical enough that experienced developers will find it engaging. Our target audience was the non-Android developers on my team at Google. Smart people who are new to Android — maybe even new to mobile — but not new to programming.

So we don’t teach object-oriented programming, Java, databases, SQL, or MVC patterns. It’s not for beginners. It’s for professional developers ready to become exceptional Android developers, but who prefer to learn it in a guided way.

Assumption 1: The audience is experienced professionals who understand how to write good code, they just don’t know Android yet.
Assumption 2: Good engineers want to see code and want to get coding quickly.
Assumption 3: The audience is motivated and talented.

Creating guided, advanced content that continues to engage professional developers over the course of several hours of instruction introduces its own set of challenge (and is worthy of yet another post). But the result — I hope — will help teach a more diverse set of developers how to develop great Android apps.

So, Can Different Approaches Create More Developers?

This year at Google I/O we set out to find talented developers from more diverse backgrounds and give them the opportunity to attend. Specifically, in recognition that many women are on a self-learning path, we provided academic-priced tickets to organizations that teach women technical skills, and build communities for women to be successful in the technology industry. That helped double the number of women in previous years, up to 20% from 8% in 2013.

Finding new developers with different origin stories and welcoming them to our community is only the first step. Now we need to continue to create and present material better suited to the needs and preferences of this increasingly diverse range of talented developers — so they can continue to grow.

Which is the short answer behind why Google’s Developer Relations team has been expanding beyond documentation, conference speaking, blog posts, sample code, hackathons, and StackOverflow answers to include:

I feel like we’re gaining a lot of momentum; we’re steering in the right direction — now we just need to finish building that engine and we can really accelerate!