Why the Best Startup Founders Learn Computer Programming

Several times a month, I’m approached by a would-be startup…

By Jesse Flores


Several times a month, I’m approached by a would-be startup founder who is looking to hire us to build them an app. In many cases, we decline if nobody on the team has any technical expertise. This is because we know these teams are confronting an increased probability of failure…and the lesson won’t come cheap.


I remember looking at the app for the first time. Clicking and being amazed at what was happening…we were creating accounts, our (fictional) users could interact with each other. We could upload and download data, so we could run our pricing algorithms on the ticket options we were selling sports fans.

It was awesome.

But we couldn’t accept payment. Evidently, we forgot to mention that we’d need that. Something stupidly obvious…and we forgot to scope it

My co-founder and I looked at each other and grimaced, as we realized we’d have to shell out a few grand more to build in this obvious feature that we missed. Afterall, what good is a marketplace that doesn’t facilitate payment transactions?

That was in 2005, when I started working on my first software product. I didn’t know how to code and we relied on our developer, a sharp, smooth-talking guy to help us figure out what we were doing. We were sure Fansurance was going to be a hit, but we didn’t know anything about software development, user-experience testing, rapid prototyping…

Unsurprisingly, the startup failed.

For a lot of reasons.

But, one of the biggest ones was because we were trying to build a business that needed a core competency (coding) that none of us had. As a result, we couldn’t iterate cheaply. We couldn’t go out and test features easily. We had to rely on getting ahold of our developer to do seemly simple things like move buttons around.

Having been on both sides of this experience – I hired dev teams before I knew how to code – I think every startup founder should have at least a working knowledge of computer programming. If more founders could code, they’d be able to accelerate the growth of their startups, faster. They could avoid the rookie mistakes we made, and increase their chances of success.

[Tweet “Founders who can code, can grow their startups faster. via @StartupLansing “]

Why Founders Should Learn Computer Programming

I happen to think that it would behoove most founders to learn at least a little computer programming – especially if they intend to start a software company (and, frankly, these days almost every company is a software company!). There are principally three reasons:

  1. So you don’t need to hire a developer
  2. So you can iterate more quickly
  3. So you can better manage a development team, once you ship and are ready to scale.

Developers are Expensive

As an owner and employer of software developers, I can attest: developers are expensive. And they can be hard to manage (more on that below), if you don’t know much about programming.

As a startup, especially before you’ve found product/market fit, the preservation of cash is – or should be – a priority. In most cases, it’s a necessity – few people can afford to take the financial risk on a new venture with little certainty that it’s going to pay off. Yet, that’s exactly what a startup is: a temporary organization in search of a scalable, repeatable, profitable business model.

As an organization in search of a scalable, repeatable business model, you want most of your cash to go to validating hypotheses about customer demand. That – and rapid prototyping (which often doesn’t require coding) – intended to help you understand where and with whom your product will get traction.

Not hiring developers.

They Get Paid, Regardless

Because most startups are still in search of a business model, it is certain that it will fail.

Allow me to repeat that.

You will fail.

Nobody’s idea is perfect and nobody gets 100% of the features right the first time. It isn’t until you get real customer validation that you can begin to hone in on which features are the most important.

At an early stage, you’ll imagine that feature X is really important, only to have a customer tell you why feature X is not only unimportant, but stupid. They want feature Y. And so do all other customers.

That kind of learning is expensive, if you’re working with a developer, because you have to pay for each feature set iteration. If you can code the app yourself, you’ll lose a few hours re-writing some code, but that’s about it.

That said, when you’re coding your own app, you start to encounter software decisions that force you to have an opinion about the user or customer’s experience. It’s when I hit these decision points that I often begin to realize that I’m baking in assumptions, without being sure the time and effort will pay off.

That’s usually a good time to stop and go validate some assumptions.

Oh, and each of those iterations you hired the developer to do? They get paid, regardless. I don’t know about you, but when I was hiring developers to build apps on my hunches, I didn’t like paying them for my mistakes.

[Tweet “No product is perfect. Learning to code reduces technical risk. via @StartupLansing”]

Ship Quickly

I love Asana. We use it for everything from our editorial calendar to writing user stories. A few weeks ago, they decided to make some feature enhancements, which included changing the way people navigate through tasks and projects.

It was not well-received (see the comments).

So, they backed it out within 24 hours and restored the previous navigation experience.

By the way, Asana’s founder is Dustin Moskovitz, one of the co-founders of Facebook (and the world’s youngest, self-made billionaire. That’s billion. With a “B”). So, the guy knows a little something about coding. And they know a little something about user-experience, user-testing, and product rollouts.

And they still got it wrong.

Now, imagine that you don’t know how to code. You’ve just released a v1 of your application and the users don’t like it (chances are you didn’t go through my prototyping session, huh).

What happens next?

You send your developer a frantic email, which queues up behind the other emails that he or she has to get through that day. Then, he or she (or their team) has to budget for the bug fix, rollback the change, and re-release the previous version.

Meanwhile, you’re freaked out because you’re an early-stage company and you’re terrified that users are going to go on social media and blast you for having the worst product ever. And your company is going to be sunk before it even started (which, by the way, isn’t really true…but, I digress).

At best, the process likely takes a few hours. At worst, a few days. Depends on the team working on your project.

Now, imagine you know a little computer programming. At this early stage, all you do is rollback the feature, call up some customers, and do a little more discovery.

Easy peasy.

After all, you knew you were likely baking in assumptions that had a chance at being wrong.

So, you have a few more conversations, make a few more tweaks, and you’ve got your product shipped again within a few days.

The point: you’ll get some stuff wrong. And, for startups, speed really is everything – you need to get product/market fit, so that you can grow. Having the ability to code will make it much easier to ship, faster.

[Tweet “Learn to code. Ship faster. via @StartupLansing”]

Managing a Dev Team is Much, Much Easier

The first time I hired a developer to build a software product – before I knew how to program myself – they put together some wireframes, we negotiated them a little bit, and then they went off into their little black box to work.

A few weeks later, I got an app. But, it turned out, that there were a lot of assumptions that were baked into those wireframes. Assumptions I had made. Assumptions they had made.

And, it turns out, assumptions in software are expensive.

Well, we wanted to change some stuff up. Obviously.

“No problem,” they tell us, “…it’ll just cost this much…”


Once I learned how to program, I could work with a contract developer and talk about how they were approaching problems. I could spot assumptions more quickly and ask smarter questions about how things were going to work.

I still make mistakes.

But, those mistakes are often less expensive. And, I am far more committed to prototyping apps before investing in hardcore software development.

Moreover, managing user stories, sprints, scrums, and all the rest is much easier, when you know what’s going on. You can also do things like, for instance, look at a project’s github repo and figure out how much activity is really going on between check-in calls.

Computer Programming is Not a Requirement

That said, learning computer programming is not, strictly speaking, a requirement. There are some founders, like Alex Turnbull (one of my favorite entrepreneur bloggers), who don’t know how to code. And they’re pretty successful at building software companies in spite of it.

That strategy can work if:

  1. You’re a bang-up sales guy
  2. You have a really great technical co-founder
  3. You have a detailed, validated prototype

Selling Ice to Eskimos

Some people excel at persuasion. And they excel at sales. These people could sell ice to an eskimo, as they say. And these people can convince anyone to buy, build, or do anything. At the very least, you need one of these people on your team.

But, this person. This talented, passionate, sales person likely doesn’t need to learn programming. That’s because this guy is really good at getting other people to do things…at a bargain.

If you think you’re this person – here’s your first test: Go convince a really great technical co-founder to join your team for free (or with equity…just not cash). That is your first sale. Sell a technical co-founder on your idea and see if he or she buys your vision. If so, chances are you’ve got a good shot at convincing customers to buy your product. With “free” labor, you’ll be able to ship, lickety-split.

(If you’re this person, you may want to check out these 6 tips for finding a technical co-founder, which may help you out!)

You Have a Really Great Technical Co-Founder

If you’re that sales person and have already recruited a really great technical co-founder, then congratulations. You like don’t need to learn to code.

You Have a Great Prototype – And People Ready to Buy Your Product

Another group of founders who may not need to learn programming are those who have already built a great prototype and validated it with real, paying customers. With tools such as InVision, atomic.io, proto.io, and others, it’s possible to build really great, interactive prototypes.

These prototypes are great, because they can help to uncover the assumptions you are making about your customers, while also giving you something concrete to build and show them. In my experience, this not only helps to scratch founders’ itch to build something (we all want to, it feels like the important part…plus, it’s fun!), but minimizes the risk of building the wrong thing.

(If you’d like some help building a prototype, so you can get to market faster, let us know!)

Get Started

Ultimately, you may not have to learn programming in order for your startup to take off…but it can help. It can help you to find – and hire – the best developers, more effectively manage projects, and help you to become a better, more creative problem-solver.

And you can achieve all of this, without being a master coder. In fact, for most non-technical founders, I’d argue that they don’t need to be master coders. They should merely be competent enough to speak with their technical co-founder and development team in their own language. They should know enough to exercise good business judgment, even if they aren’t responsible for committing code to Github.

[Tweet “Even business #cofounders should have some knowledge of code. via @StartupLansing”]

To get started, there are tons of resources online from CodeAcademy & Udemy to online tutorials. Some are free. Many are not. And, whichever way you go, be prepared for a few months of focused, occasinally frustrating work.

But, then, something magic will happen.

You’ll look at a git repo and it’ll make sense. You’ll talk to a team of developers and understand what they’re saying. You’ll look at the work and be able to sniff out poor quality.
And you’ll find yourself asking different, better questions. The cost of development will decrease. Customer joy will increase. And your startup will start to take off.

learn computer programming at the lansing code academy

Read Next
system escape concept on the wooden background

From Solo to Systems

After Moses led the Israelites out of the Promised Land, his leadership was in high demand. Usually. At times, people grumbled greatly against him. But, in general, he was seen as the unequivocal leader of this movement. As a result, he was in high demand – everyone wanted to know what he thought about this...
Restricted Area Barbed Fence

Freedom is Difficult Work

Freedom is a habit of soul. But not for the faint of heart.
Work life balance scales

Work/Life Distribution

Is work/life balance possible? Probably not. Here’s what matters more.
Scroll to Top