There is a lot of chatter out there in the vein of “should all founders know how to code?”, “should all human beings know how to code?”, and “what do we even mean by know how to code?”. I struggle in a few ways with these questions, so let’s break them down a bit.

Knowing How To Code

At the most basic level, I think everyone should learn to code (go read my thoughts on that, it’s important). Or rather, to learn the fundamentals of programming, which turns out to be very different than learning to actually write production software.

Like any mature discipline, understanding “computer science” or even the more pragmatic “programming” is too large a task for anyone, let alone for everyone. It’s safe to say that computer and Internet tech is evolving quickly enough that even if you could learn the vast majority of it, it’d take so long that you’d be forever chasing a moving target. Welcome to the world of being a developer. It’s exhausting!

This is hardly a challenge unique to the high-tech sector, of course, but it’s especially daunting given the pace of innovation over the past few decades in world history (and at least the next few too, I don’t think we’ve reached the inflection point yet).

Saying simply that you want to learn to code is like saying “I want to build things.” It’s so generic as to be laughable to the ears of a technologist. Do you want to build transistors, jewelry, furniture, cars, roller-coasters, igloos, skyscrapers, dams, or a space station?

The world of programming is officially large enough that everyone needs to specialize, or at least pick a place to start. Maybe you want to:

  • Build web sites
  • Build web applications
  • Build mobile apps
  • Analyze an interesting set of data in your field of study
  • Make Excel do amazing magic tricks
  • Write an AppleScript to control Photoshop
  • Help your kid learn Scratch
  • Write a printer driver
  • Create a synchronized light display for your next band-gig
  • Make a dynamic art exhibit that feeds live off a Twitter feed

Be specific about what you are trying to learn and accomplish.

Driven To Code

I see four predominant camps of people who want to learn to code beyond the fundamentals, to actually write computer software that performs complex functions in the real world:

  1. Those who aspire to a career as a professional software engineer.
  2. Those who work closely with engineers, and for whom a fluency with the language and skills of that trade will help them interface with or better manage technical teams.
  3. The naturally curious, without a particular agenda, who find the idea intrigues their inner geek.
  4. Those who want to build something, and out of necessity desire to learn enough about programming to manifest their vision in an MVP or a full fledged technology solution.

If you’re in camp 1 or 2 or 3, go forth and find enlightenment through software. May you enjoy many late nights basking in the glow of backlit screens fueling your desire with a steady supply of Diet Coke, Doritos, and an ignored social calendar.

If you are in camp 4, you are in the contentious group, so read on.

Coding Isn’t The Answer

Within the startup world, there’s healthy debate on whether founders should be compelled to code to prototype or build their products.

Fred Wilson takes a clear stance that founders should “get technical”. He’s right that coding isn’t that hard. And he’s seen thousands of companies, so of course has some data points on founders who’ve successfully used this strategy.

I share Fred’s enthusiasm for spreading the good word of Coding far and wide, but disagree with his dangerous conclusion that the best way for a non-technical founder to start a company is to head off to Code Academy. Here’s a hint: the founders who were successful with this strategy were already in groups 1–3 above. If you have to uncertainly ask the question “should I learn to code?”, then the answer is already “nope”.

Ciara Byrne at Fast Company gives a great counter-argument. She writes, “Coding is not a goal. It’s a tool for solving problems.” If you are an aspiring founder-cum-coder, you have the problem of building a business, and coding is unlikely the best tool for solving your problem.

First of all, even if you do learn to code by reading books, taking classes, and thousands of hours of personal study, learning to code in a vacuum isn’t the same as preparing to build a successful tech product.

But more importantly, building a company is hard enough without having to be simultaneously master a whole new discipline. You have to focus on selling your idea to the world, making sure the business is a growing concern, keeping the bank account in the black, and hiring great team members to help you. That’s an awful lot of work already. Are you sure you want to add a whole new course of study to your plate right now?

Find A Partner

Here’s the harsh reality: If you can’t find and convince a technical resource to help you build your amazing new product, then your vision and pitch is broken, and learning to code it yourself as a last resort isn’t the answer.

Engineers love building things. They love it at their core. And they dream about building something that has an impact, makes a difference, gains critical success, touches millions of people, and makes billions of dollars. There’s no magic to their motivation, and the same vision and enthusiasm you need to bring them on board will be a requirement for the success of your business with investors, customers, and the press. So you might as well nail that part now.

A lot of great techies, usually from Group 1, would be happy to prototype out an idea in their spare time, if they believe in it (coders collectively spend millions of hours on open source projects, after all). Find them, convince them, get rid of your ego and offer them healthy equity and recognition for the important role they’ll play in bringing your vision to life, even if just in a prototype form so you can raise money.

Be charismatic, genuine, clever, and generous. You’ll find someone to help build your dream, and in the meantime, keep yourself focused on how the product should work, not how it should be coded.