- Can raise funding and know funders well

- Have a massive network of people to tap into

- Can cold-call like no-one's business

- Know how to negotiate a deal to the point of paranoia

- Have deep domain experience and connections

- Make plans for the future, but can pivot on a dime

- Can talk enough tech to understand well beyond buzzwords

- Know how to keep themselves and the tech side accountable

- Clearly presenting value prop

- Use CustDev framework to test and validate the idea

- Create and manage ad campaigns

- SEO and content marketing

- Conduct user tests

- Getting out of the building

Why should a business/non-technical founder learn to code? The answer to this is simple: so that you have better ideas. Or, put another way: learning to code gives you the ability to implement your ideas. And implementing your ideas forces you to recognize, after some time, what works and what doesn't.

Hackers who start their own projects tend to have a framework in their heads for figuring out which ideas are good/may work, and which ideas won't. And they know this because they've failed enough times to figure out what isn't good for a project. Whereas most business 'wantrepreneurs' I know don't have that. They don't have that because they've never implemented anything, and so how do they know if their idea's a good one or not?

It's interesting to note that you don't have to learn to program to get this framework in your head. Learning to program is simply the most efficient (and cheapest!) way of doing it. Prominent counter-examples come to mind: Steve Jobs never really learned to code, but he grew up in the valley, and chose to mix around with hackers (Malcolm Gladwell, in his book Outliers points out that as a teenager Jobs approached the CEO of HP to ask for parts). So it's probably safe to assume Jobs absorbed such a framework by osmosis - spend enough time around people who make product and you begin to see for yourself what works, and what doesn't.

Jason Fried has also been brought up in this HN thread. And I suspect that it's no different for him: Fried is no programmer (though he's a web designer). But he was willing to pay people to implement his ideas. He paid DHH, after all, to build Basecamp. And that's another hack - you don't need programming ability to learn the framework - in this particular case all you need is implementation (which you can pay for). And if the project fails, you learn from it. Either way you gain things to add to your internal framework. (Derek Sivers also springs to mind - he hired contract programmers to build CDBaby, if I'm not mistaken).

This mental framework you elude to might be described in another way... perhaps as 'optimal manifestation frequency'. Someone working in OMF is able to create reality (ie- code, design, deals, etc) at the highest levels of human capacity. Doesn't necessarily matter their particular area of expertise. People in their 'wave of impact' will know what to do.

I'm not a programmer, but I'm intimately involved with every piece of UI across our product line as well as our marketing sites.

Some of the UI I design myself, some I work with other designers on, and other bits I give advice, feedback, and guidance on.

I also write the copy on all of our sites, and I'm involved with most of the copy in the apps themselves as well.

I hired DHH as a programmer (and then made him a partner) because those were skills I didn't have. I've done some PHP programming in the past, and I met DHH when he was a PHP programmer, so I was able to evaluate his talent at a very basic level. Beyond that, however, I liked his business mind and general approach to things - they were closely aligned with my own.

So what you're saying is ... learn to program, unless you are sharp enough to identify talent and 'bullshit' ... How would one identify this innate ability to know that they didn't need to actually learn how to program then?

> the above advice isn't entirely applicable to his case.

I don't buy into everything he's selling (cf. Rework), but I think there's stuff worth picking out of his brain.

Replies like "wait. what?!" don't actually contribute to the conversation on YC.News and are functionally, pollution.

Also don't use downvotes as an "I disagree" weapon, but rather a way to cull commentary that isn't contributing to the exchange.

Much like your own, actually.

Confer with http://ycombinator.com/newsguidelines.html

In the "In Comments" section for more info if you haven't reviewed it already.

---------------------------------------------

I fail to see where that part is reflected in the guidelines. The comment basically contradicted itself enough that I felt that they actually needed to explain themselves further.

The fact that they had a functional prototype, regardless of how horrible the technical implementation was, showed me that they were serious and I'd be able to communicate technical aspects to them much easier.

a little proof that WordPress can be used for an interesting prototype: http://www.notepeep.com

I don't code and with a handful of plugins and a few changes to some PHP I was able to pull off a functioning prototype.

You will also be able to have an intelligent conversation with a developer.

I get sad whenever I encounter a business person with no technical bullshit filter. Not because I'm judging them, but because if I can bullshit them, any other developer can. Which probably means there's a problem somewhere that will hurt all of us.

If you learn enough to do a bad job building your prototype, you will learn what you don't know. Right now you don't even know what you don't know.

The other is you muddle through, learn a bit and do an OK job pulling together the prototype. Sure it doesn't look exactly right but you can log in, see some records, make some updates and it's all fine in demos and pitches - hell you've even stuck it on the web for friends to poke and prod.

You now think it's all straight forward and you're nearly there. The whole this isn't secure, is held together with sticky tape, updates aren't transactional so when something does go wrong the data is left in a mess, it has no error handling or referential integrity and won't scale beyond half a dozen users which is all it's ever had to put up with as a prototype but you've only been coding for six months so you hardly understand that these problems even exist let alone understand what's involved in solving them.

Personally I really really don't want to be the tech lead who has to then deal with someone who knows way less than they think and is being told that the thing needs to be rewritten and by doing so is not only delivering bad news but is also having to criticise the persons own personal work.

A good CEO shouldn't have to have every skill used by their organisation and I don't see how coding is any different to accounting, legal, sales or any other skills in this respect.

The mark of a good CEO is to be able to build good teams, be trusting enough to let them do the work they need to and smart enough to see when the wool is being pulled over their eyes.

1) with a greater appreciation of the talent/experience required for good development, a better BS detector arond technical issues, and a stronger understanding of what they don't know OR

2) a false impression that proof-of-concept = product and an over-inflated idea of what they've learned.

I'd almost argue that it can be a bad thing - I've lost count of the number of times I've been stitched up by someone with a small level of knowledge who extrapolated incorrectly from it. A little knowledge can be a dangerous thing as often as it can be useful and in 6 months that's all you're going to get (actually in six months coming from nothing you're going to know way less than most graduates and how many people consider that a decent skill level?).

Good founders should bring intelligence and an ability to learn quickly to the table, they should be willing to trust the experts they hire, but I think saying that they should be able to program is a very programmer centric view and no more valid than the sales guy saying you should go sell for 6 months, or the account saying you should be a book keeper for 6 months.

Re: #2—Let's reverse this, specifically for marketing.

Developers (and pretty much anyone) who know a little marketing can be harder to work with than those that believe they don't understand it. They over-rely on cliches and stereotypes without realizing it.

And what about the scenario where you end up with a person with limited technical knowledge micro-managing a tech worker? Not a good thing.

Re: #1—I find creating mock-ups shows functionality more accurately and in much, much less time than creating working prototypes.

I guess that's why proven coders and proven commission salespeople (and proven accountants) can always find jobs, while "big picture" folks are left unemployed, wondering why companies can't see their brilliance. Or, if they're lucky, they sue Zuckerberg because he was able to do make an actual product which never got past the great-idea-over-beer phase for them.

Specifically, it's much more true in consumer than B2B. In B2B, biz dev is building partnerships, channels, distribution, obtaining resources you need at prices you can afford, all that good stuff. It's the absolute engine of your business.

If you're writing a B2C app, doesn't matter about the platform, then what biz is there to dev? In a similar sense, you need marketers, not salesmen, because your problem is getting a call-to-action out to your potential market as effectively and efficiently as possible. You can't do that door-to-door at scale.

But if you're doing enterprise software, the converse is true. You need biz dev to shape your proposition, and you need a sales force to go and hammer down doors and melt the copper in the phonelines.

I'm learning a lot of mechanical engineering stuff from my co-founders that's critical to understanding why our product will or won't work.

That is what I thought too before writing. Let me tell you you don't understand it, my friend.

Do these sweeping generalizations do any good? No doubt, it helps to know at least some coding in this business, but isn't that just common sense? And even if someone disagreed with that sentiment, would they take this to heart anyway?

We're pretty busy, so let me cut to the chase:

The good: I'm credible to our tech folks. I understand when to slow down to integrate a library, and I'm more than willing to find time to re-factor. I learned that pair programming can be awesome, that bringing on new people slows you down, and a lot of other things that probably seem obvious to technical folks but are non-intuitive when you imagine software as assembling widgets.

The bad: Ultimately, we gave up 3-5 months that we could have been hiring, fund-raising, and building software. On balance, I think that this was good for me and bad for this start-up.

The ugly: As soon as I'd hired people, I think that we should have thrown out most of the code I'd written. We kept it because it worked and was fairly fast, but I'd made A LOT of newbie mistakes that have slowed things down.

As a corollary, be weary of AI. If you are solving a problem with AI that you don't understand, assume the AI won't work.

So you could have built a crappy prototype, true. However, while Twitter is an exciting startup, a Twitter clone is not (anymore).

If it is challenging, you get too deep into code, things take too long, get discouraged, etc.. Or settle for some gimmick that you can execute within a reasonable timeframe.

My take on it is simple: I passed this article along to my co-founder as a token of appreciation. See, he started along the way without any coding experience. He taught himself (with some pushes in the right direction) how to program, design, and even do some database stuff. He's decent at it, but that isn't necessarily what matters. What matters is now I have someone to discuss things with, someone who understands at least the basics (and has basic experience) with different design stuff. That's not only helpful for productivity, but morale as well.

I started with Python, using a combo of MIT OCW, Learn Python the Hard Way, and How to Think Like a Computer Scientist. I then started going through an online course on dynamic websites that touches on HTML, CSS, PHP, XML, MySQL, Ajax, and Javascript. I've been using w3schools.com and the online manuals to learn more about these.

While building my prototype I mostly feel like I have no idea what I'm doing but slowly and surely my site's starting to function, grow and work. Its amazing what persistence can accomplish.

Over the past year, we had many 'business' persons who offered to help out, and while that was awesome, what we really needed was qualified technical people. For a 'business' person, one can usually get an unpaid college intern and not have to sacrifice any shares in the company.

Also, I think as functional person you are somewhat "over the barrel" if your developers dont perform, and can do nothing except complain. I do believe it's better overall if you can build your own product. At the end of the day, we decided to educate our own team in Ruby/Rails rather than bring in outside developers. I think this was a smart decision, and also a more cost effective solution.