Should everyone learn to code?

January 31, 2013 | 6 comments

I posted this the other day, blissfully unaware of how contentious it would be:

“Learning to code is non-optional in the 21st century.”

It’s a piece of hyperbole, of course; learning to code is perfectly optional. Nobody’s pointing a gun at your head and forcing you to do it. But here’s what many of my friends and contacts read into it:

  • People who can’t code are less valuable in the 21st century.
  • Coding is as important as, or more important than, learning to read, write, do math, or cook.

Of course, I didn’t say any of those things. It’s interesting that they were inferred, and that the idea that everyone should code was seen, generally, as being self-important and enthocentric from the perspective of the tech community.

Here’s why I said it:

  • Software technology is an integral part of all of our lives. It’s part of our environment, and will only become more so.
  • Coding gives us an increased level of control over our environment.
  • Without being able to make or alter software, you are relegated solely to being a consumer of it.
  • Learning to code is virtually free (if you already have a computer), and it’s not hard to get started.
  • The web in particular is a medium that has the potential of allowing anyone to contribute to it. I feel strongly, ideologically, that it should not be yet another medium where a few large companies dictate the form.

It’s also true that, in today’s economy, technology is one of the few growth industries, and having technology skills means you’re much more likely to be able to get a well-paying job. It’s also, generally speaking, not an elitist industry: most tech companies care much more about what you can do, rather than where you went to school (or even if you did). There are also no required professional qualifications to obtain. It’s a pretty good deal. All you need to do is know how to make things well, and you get to teach yourself. (Codeacademy and Mozilla Thimble: both fantastic.)

Far more importantly, technology isn’t going away. It’s not a fad; it’s ingrained in everything we do. There’s no reason at all why you should have to do it for a living – and obviously, there’s a universe of fulfilling career options out there – but understanding how technology works is empowering. It’s a 21st century literacy that will differentiate – as Douglas Rushkoff says – between the programmers and the programmed. And guess what: I do think that the people who understand how it works will ultimately be more valuable. They’ll make better technology decisions, which – as technology becomes more and more ingrained – will mean that they’ll make better decisions overall.

But hey, what do I know. What do you think? Was I out of line? Or is code as important a skill as I think it is?

Recipes for startup failure

November 20, 2012 | 4 comments

Technical co-founderPaul Graham’s essay, How to Get Startup Ideas, is long but very much worth reading. Normally I’d pull a quote, but it’s a valuable piece from start to finish, and it’s hard to know what to choose. Go read it, then come back.

He makes clear that, more than anything else, if you want to be a tech entrepreneur you need to live in the future and build what’s missing. That’s an important idea, which we can break into parts:

  • Have a great idea
  • Build it.

Sounds simple, right? But that second bullet is the hard bit. It’s not anywhere near enough to come up with a great idea, although you can’t have a great startup without one. (Paul has some valuable thoughts on this, including turning off your “sexy” filter and allowing yourself to see problems whose solutions are going to be a pain in the ass for you, but valuable for your customers.) You also have to build it.

This is a complicated field, on which a lot has been written. But I think there are a couple of things that will never allow you to build a successful software-based startup.

If you’re not a geek, don’t outsource the product.

Forget what you may have heard about IT projects. Building a technology company isn’t as simple as coming up with the idea, sending a plan to an outsourcing company and then reselling the result. Not only will your technology be frozen in time, with the outsourcing company effectively holding all of your value (you’ll need to hire them again to make improvements, and it’s important to realize that software products are never actually done), and not only does it send a clear signal that you don’t really care about your product, but it’s also a certainty that no outsourcing company cares as much about your startup as you do. An outsourced software product will always be inferior to one produced in-house by a dedicated team.

There are no shortcuts. Your startup must know how to code. And you, as a startup founder, must learn enough about the technology to be able to make informed decisions. Don’t hand it off – and if you possibly can, learn to code yourself. It’ll be worth it, and as long as you can think logically, it isn’t as hard as you think.

(One quick special note: if you instinctively recoil from the idea of learning how code works, or DNS, or servers, or any of the fundamentals to running a technology company, don’t get involved in tech startups. Those things are the building blocks of your product.)

If you are a geek, don’t make the mistake of thinking it’s all about the code.

This is the mirror image of the above mistake. Building the product is important, as I’ve just laid out. But a startup isn’t a webpage, a service or an app: it’s a company. The temptation, particularly as a single founder or a small team of developers, is to spend all your time working on awesome code that works well. But, equally importantly, you need to nail down the fundamental framework of the business you’re creating.

How do you work? How is your company incorporated? How will you sell your product and market yourself to your potential customers? How will you find those customers? How can you grow? You can’t code the answers to these questions, and if you’ve never started a company before, you’ll find that they’re far harder than building software (because these are new challenges). You’ll need to be empathic, unless you’re building software for a million people who are just like you. (Hint: there aren’t a million people who are just like you.)

As far as the product goes: get something working, fast, and then iterate on it, while you work on the tough stuff. You’re a coder, so you probably don’t read manuals, but get used to not knowing stuff and having to test it in the real world. That’s how companies work. There’s no such thing as sitting in a dark room and – ta da! – coming up with a world-beating company that’ll make you millions. Any story that says otherwise is a lie (because the company in question will have worked out that it’s a great way to sell people their product).

(The geeks get a special note, too: design is marketing. It’s how people perceive your product. If you’re a back-end coder, not only will you need to learn the spreadsheet side of your startup, but you’ll need to learn how to make a clean design, too. You can’t outsource this, but luckily, projects like Bootstrap and Glyphicons help. Get a real in-house designer as soon as you can.)

Your business is the product, and your product is the business.

You can’t do just one. Starting a technology company is an amazing experience – but if you’re a spreadsheet person, you’re going to have to get used to looking at the technicals. And if you’re a technical person, you’re going to have to get used to looking at the spreadsheets. That’s just how it works.