I disagree strongly. Coding is a great skill and just about everyone should be familiar with it, but telling starry-eyed entrepreneurs they can learn to code well enough to launch a successful tech startup on their own in a short timeframe is extremely misleading. Coding and design are the core competencies of any tech/web startup, and you can't hope to succeed if you're essentially an amateur at your core competency. Because the fact is, coding may not be hard, but coding well and being responsible for the software infrastructure of a successful project is hard and isn't something you can pick up overnight.
By all means, learn to code. It will help you in innumerable ways, and maybe after a few years of practice you can start to think about launching a cool project on your own. But don't be deluded into thinking you can pick up "Ruby for Dummies" and have a hot new web startup 6 months later without some real technical expertise.
If you look at a good undergraduate CS program, you'll note that majority of is going to be general skills relevant to any sort of scientific/engineering work: e.g., there may be at most a single programming course in the entire freshman year. That drove me crazy as an undergrad ("when do I get to code, why am I doing all these proofs with Greek symbols?"), but it taught me to reason and think in a rigorous manner.
Of course professional programming experience also teaches you about things such as debugging, release engineering, configuration management and operations; all of these are crucial but are more about being able to scale and iterate upon a basic product, rather than discovering what the product you're building should be.
What i found is that there is so much help, so many places to find the answer if u can research. Just reading the source code, Readme docs, chat rooms, is so much help. Cookbooks, tutorials by bloggers are all helping me along. Also, you can create so much with just a little technical skills. At the end, you still have to run a business, be a hustler. So when i launch my little application, i will try and get some talent on board as well(if i am lucky). The key is to achieve a lot with a little.
I almost forgot......Google developer tools, has sped up my learning so so much, reading the source code of websites and looking at all the scripts. Its just amazing the resources available today vs 5yrs ago.
If you're too poor to pay for it this book is available free online:
This is probably the best place to get started with HTML and CSS:
Once you know regular CSS, if you're going to be designing your own sites, you should start using this (little known secret weapon):
I'd say once you understand all that stuff, learn Django
http://yuiblog.com/crockford/ (download with netvideohunter firefox extension and watch sped-up with vlc, [ and ] keys control speed. I wish I'd taken notes.)
If you've got capital you can hire other people to do design:
There are a lot of services on the internet that will convert PSD (photoshop) documents that 99designs guys make in to xhtml and css for a few hundred dollars. So you don't have to go deep in to design if you don't want to.
I wish I'd installed Ubuntu and learned to use the command line earlier; otherwise I wouldn't have gotten frustrated when trying to install software. I'd say once you've got Ubuntu running, read everything under Linux on this page:
Normally you want to be learning things on a just-in-time-basis, so you're learning something in order to apply it to some project. But system administration isn't like that because you don't know what you need to know.
As for regrets: I think I would have learned a lot faster if I'd given myself designated study hours. Probably half an hour a day to start, with gradual increase. Also, I shouldn't have been so hesitant to register for accounts and ask questions on forums, IRC channels, etc.
Paul Graham has more tips: http://paulgraham.com/pfaq.html
If you have no coding ability whatsoever, you have no understanding of a major part of your business, and you will not have much a clue when hiring programmers about how skilled they are. So you'll end up hiring people that sound good, not are good.
Think of betterworldbooks.com. I'm sure that code is very important to them. They probably have great programmers working there. But, going to campuses, exciting students and organising fund-raising book collections is probably more their core competency. Zappos needed great software, but it wasn't necessarily technical prowess that made them successful, their customer service seems to the the credit. There are many web startups which are e-commerce companies at core. AirBnB, from what I read, is an impressive startup, but the problems they solved to get it going where not primarily technical. They are taking advantage of opportunities that technological advancements have created and have big, important technological components to them (compared to restaurants, shops, dental practices..), but they are not pure technology companies.
Being an amateur level programmer (can code an e-commerce site) could let someone have a go at a lot of potential ideas. You probably can't be Google or Paypal but you might be a Woot! or something.
This might be a good place to point to Peter Norvig's essay Teach Yourself Programming in Ten Years -- http://norvig.com/21-days.html
In Entrepreneurship(Particularly web apps), i disagree that
you need to be an expert, i believe that you need to be able to get something built and manage whatever traction you get from there to make your business solid. Such as getting top talent to do thinks the right way. The key is just get something built first......in my opinion.
The drawback is that it gets more expensive the longer you wait. The more code from a beginning programmer there is, the more there is to be overhauled, and the more ingrained your seat-of-the-pants interaction design and visual design is, the more challenging it will be for your designer and/or front-end developer to lift out and replace.
Anybody technically can do anything themselves, if there is a skill worth learning then it probably is programming, since it allows you to amplify your ability to get work done in a given amount of time (which usually is your most scarce resource).
But you won't be managing that time effectively if you want to launch a start-up and learn this skill at the same time, then you're probably better of hooking up with a competent coder and letting them lay the bricks in a way that will help your business to succeed.
I'm all for learning new skills, I can weld, but when my life and or my business depends on it I go to a welder.
So if you are not already a competent coder and you have the choice to team up with a coder or to delay the launch of your product by a couple of years to get you up to speed seems like a no brainer to me.
It's unlikely that someone who doesn't know how to program would be aspiring to do startup that takes a few years of practice in programming.
The last startup I did failed miserably. When I looked back to see what went wrong it was obvious that if I could have coded it myself I would have been a lot better off, and it might have worked out.
So I started learning how to program so that I would be better prepared next time around. Best decision I ever made.
I can now get an idea, and straight away do something about it instead of first having to convince someone to do it for me. As an extra bonus it's now trivial for me to see things that weren't at all obvious before such as why one feature is much more demanding to code than another, why seemingly simple things take so much time, and much more.
I'm by no means a good programmer: I can't do a high scalability clustered scheme app, but I know enough to actually do things. And really that's all that matters.
If you're into startups and can't code follow Gabriel's advice and learn how to do so. Right now. It's the best decision you'll ever make.
Learning how to program gives you a better sense of what it takes to build something. I personally believe that if you're in startups, you should at least be somewhat knowledgeable in the technologies used.
The cure reminds me of what Fred Brooks said in The Mythical Man-Month after 20 years, at p.258-9 (MM-M, 2nd ed.) about defining the user set (ie. who the users are), as a population assessed along several attributes, with a frequency distribution over each (my eg. how much RAM they have; their largest file - but the most interesting ones are app-specific). He says you should GUESS the set of attributes and distributions:
1. you will think about it carefully;
2. they will be debated by the team, revealing differences in how each member sees the user set;
3. it "helps everyone recognize which decisions depend upon which user set properties. Even this sort of informal sensitivity analysis is valuable. When it develops that very important decisions are hinging on some particular guess, then it is worth the cost to establish better estimates for that value."
He summarizes: "It is far better to be explicit and wrong than to be vague"
The design brief for our website was seven pages if I remember correctly. First we described who our customers were, along with their psychology and values. Then we described the vibe we were going for and why it would resonate with them. Then we described 10 or so design elements that sent signals consistent with what we were going for, and listed five or so examples of each element being used on various sites across the web. Now I realize that this is different than a business plan, but if you haven't done more than five pages worth of thinking then you probably don't understand what your assumptions are or how to test them.
You're more likely to find someone to invest in or collaborate with you based on a prototype than a detailed rationalisation of the thought behind the prototype you're thinking of building.
Putting your thoughts on paper is one thing. Putting your thoughts on paper as a substitute for trying to put them into practice is another.
However I think most of these 'cures' are 'easily' achievable, but having enough time to cure these symptoms and looking for a co-founder are the hardest parts of becoming an entrepreneur. In my case I took advantage of having been laid off in 2009. So I've decided not to look for a job until I've got some stuff done.
It least we did our own coding.
1. Gives you an idea of what your friends will think about you after you become a real entrepreneur.
2. Gives you hope that you can and will change your circumstance.
3. It consumes you till you make the jump.
4. Plus you get to practice a very important skill - how not to worry about what people think of you :).
5. Gives you chance to evaluate whether you really want to be a founder.
6. It makes you go to real entrepreneur events so you can meet and mingle with them and get to know what its really like.
This is a great article to break out of wannabe mode but I dont think being a wannabe is necessarily a bad thing.
Hey - fake it till you make it :).
Being an entrepreneur is not something you 'fake' any more than you could fake playing the violin (well, you could but it would not get you any closer to playing one), you either do it or you don't. You could do it badly though, and most entrepreneurs do that for a while until they've racked up enough experience to make a go of something. That's called practice.
Wannabe entrepreneurs usually stay that way, entrepreneurs get up and do stuff, they don't 'want to be something'.
Putting your intention out there and building that network even before you start will always help.
Infact that act of creating that network might be the one thing that would force you to make the jump into being a real entrepreneur.
I see a disturbing trend in my environment where people will spend more and more time 'networking' and less on developing their product and / or their business in general. They're all backslapping each other what great entrepreneurs they are, they organize events and so on. Meanwhile the real entrepreneurs run off with the contracts.
Networking has its uses, but don't overestimate it.
EDIT: Wow. Some people are really pathetic with down votes. It was a mistake and should be correctable.