In a post entitled Please Don’t Learn How to Code, software developer Jeff Atwood argues that the “everyone should learn programming” meme has gotten out of control, and that most people don’t need to learn how to code.
I mostly disagree with Atwood’s premise and land on Benjamin Stein’s side of the argument. Coding teaches you analytical thinking skills, logic workflows, and debugging like no other activity can, and you can apply those skills to lots of situations beyond actually building production apps.
But Atwood hit one nail right on the head that I can’t stress enough to people who want to make digital tools:
[Coding] puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?
I often get email from people who “have a great idea for an app” or newcomers who want to contribute to ThinkUp but aren’t programmers. These people are convinced the first thing they have to do is learn how to write code. It isn’t.
The world of software development needs more people who know how to define better solutions than the ones we have now.
See, when I ask these people to describe their great app idea, they never have wireframes or mockups, and usually can only explain it in the vaguest terms. When I ask newcomers what they want to change or add to ThinkUp, they often can’t tell me—they just want to be a part of the community. (Nothing wrong with that, but code isn’t the only way to contribute. It’s not even the primary way.)
Software development is not code. It’s solving problems. Before you learn how to code, learn how to propose better solutions. You are most likely already qualified to do this.
A few years back I took a weekend-long intensive course on shooting and producing video journalism. In the first hour of the first day, our instructor said, “What makes great television? If you love watching TV, you already know.”
The same principle applies here. If you love, use, and think about technology, you already have a good idea of what’s possible, and what elements make up a user interface. You know when to expect a text field and when you should get a dropdown. You understand the difference between saving a file locally and saving it to the cloud. You know the apps you love the most and what about them makes them special.
This is what you need to know to start designing new solutions.
If you aspire to build an app, the first thing you should do is define the problem, your idea for the solution, your target user base. Do your research. Know all the existing solutions out there, and exactly how your spec is different and better. Choose a platform, and start mocking up screens. Get in deep. Agonize over what words appear on the button labels, what the user success, information, and error messages should read, every single thing that could go wrong in the process of using the app and how it will recover, what your one-sentence description will be when your app appears in a store somewhere. Arguably, defining great specifications is a more important part of creating digital tools than writing the code itself.
If you want to build a new app, or contribute to an existing one, you don’t have to learn how to code first. But please do learn how to propose better solutions.
