Learn To Build

I recently received an email from a friend who isn’t a software engineer but is working at a well-known Silicon Valley tech company. She asked if I could recommend any good “basic coding courses” in order to learn enough to hang with the engineers at her company.

Being a (mostly) self-taught engineer, I’ve gotten this question a few times. And the concept of “learning to code” outside of school is obviously gaining traction with a wide audience when even Obama is recommending it. Tools like Codecademy and Khan Academy as well as online courses like Stanford’s CS106A will help you get your footing when just starting out.

Developers love that everyone in the world is now turning their heads towards technology and software and thinking “I should have studied computer science in college”. We have adopted “learn to code” as a mantra, to be repeated to friends and family and colleagues after they pitch us on a new app idea, or to students when suggesting important skills to develop.

But the recommendation to simply “learn to code” feels slightly off to me, because it doesn’t really encompass what programming and writing software is all about: actually building stuff.

The phrase “learn to code” carries with it the subtle implication that “coding” or “programming” alone is a worthwhile end in itself. But it’s really not, and we shouldn’t be giving that impression to those just starting out with software development. The idea that learning how to add 3 and 4 in Python or learning how to write an if-statement in JavaScript is useful on its own is farcical.

I am not suggesting that learning the basics isn’t important or required. But creating usable software is complicated in a way that, to pick one example, creating edible food is not. “Learn to cook” followed by a basic course in cooking coupled with a few simple recipes will go a long way towards helping you to cook for yourself.

Many industries suffer from the opposite problem. It takes years of study and training and practice as a chemist to develop a new drug, for instance. Which is why we don’t see the president encouraging everyone to spend an hour “learning chemistry”. Software development occupies a magical sweet spot where it’s relatively easy to get started, but there are still lots of interesting and complicated problems with solutions waiting to be built.

We shouldn’t shy away from this. And instead of “learn to code”, we should encourage newcomers to “learn to build”. Code is just a tool for building things. And since software is one of the most powerful things a person can build, it makes sense that more people should learn to build it. Learning to code is the first step in learning to build software, but the learning can’t stop there.

The problem with learning to build is that it can’t really be taught in a class. You can teach skills, but building isn’t a skill. It’s a mentality. It’s seeing the world of software around you as manipulable, and figuring out how to manipulate it. This can only come from hands-on experience.

And so my recommendation to my friend was that she get her hands dirty. Here’s what I told her:

Start at the start. Take a basic programming course. Get familiar with variables and data types and control structures and functions. You will develop an understanding of programming vocabulary that will help you to ask better questions, which is crucial when you run into roadblocks later (and there will be lots).

Find a project. At the same time, start looking at work or at school for a software system designed or supported by someone you know that you use regularly but you think is broken in some simple way. It could be as small as an annoying phrase in an error message that you see all the time that you’d like to remove. Try to figure out some small problem to solve in an existing system.

Fix something small. Don’t spend more than a couple of weeks on the basic programming concepts, unless you really enjoy it (and even then, move on after a month). As soon as you’re comfortable with basic programming, get down to business: try to solve one of the small problems you’ve identified. The learning curve here will be quite steep at first and it is easy to get discouraged, so it will help to have someone who knows about software available to chat with you.

Don’t stop. Once you’ve solved one problem, or even just gotten the software you’re trying to fix running on your computer, you’ll feel a tendency to declare victory. Fight that tendency, take a celebratory lap (or nap), and dig in again. Bite off a bigger chunk. Find a new project to work on if you’re bored with the current one. Talk to people about what you’re working on and what you’re learning to get ideas for what to do next.

Invent something. Eventually you will have enough experience to build something mostly from scratch if you want to. This is an amazing position and you should absolutely take advantage of it if you have the time and desire. But even if not, you’ll have developed the skill of identifying a problem, figuring out how to fix it, and then fixing it. And hopefully you’ll be able to help the next person who comes along and wants to learn to build.

I also warned her of the problems she would face:

The gatekeepers for the software you’re trying to fix won’t want to let you have copies of the source code on your computer. Figure out how to make it happen anyway. Often times improving an internal tool or system at work or school will be far easier than improving an externally-facing thing due to political issues. Open source projects might seem like a good place to look since the code is readily available, but be wary as they are also known to be heavily gatekeeped and often getting started is more difficult than it should be.

You won’t know how to even make small changes at first. Because generally any system that’s useful will also be very complicated. Don’t worry. This is completely normal. Start by searching all of the files in the project for some words that you see in the interface of the thing you’re working on. Once you find them, change one of the words to demonstrate your immense power to manipulate the computer and bend it to your will.

You will get discouraged. Again, most things are very complicated. Ask someone who knows how the system works to help explain what you are struggling to do. Make sure you get an explanation, not just the solution. As long as you are trying to make a positive change most people will be happy to help you out. And if you demonstrate that you’ve put in real effort to understand as much as you can (by having good questions) then it should be easy to convince people to help you. Of course there will be exceptions, but those people are jerks who live pathetic lives and you should ignore them.

And assuming my friend follows these steps and learns to build, here’s what I would tell her happens next:

You do it all again. You learn to iterate. You learn that nothing is ever finished, and everything can be improved. You learn how to decide which things are worth improving given limited resources. And all along the way you share the knowledge of how to build with those around you, so that you can all build together.

If you enjoyed this you should follow me on Twitter here.

Thanks to Bridget Campbell, Daniel Zarick and Kyle Conroy for their excellent feedback.