How about choosing a project that's too small & inconsequential to be called a "startup" (Paul Graham has indicated that he thinks these can be some of the best startup ideas anyway) and use it as a test case to improve your programming skills? (The advantage of choosing something small & inconsequential is that you can get a quick, small win in order to build a success spiral for later attempts at big startup projects. Bonus points if your quick, small win could lead to a series of slower, bigger wins, e.g. in the case where your small & inconsequential project gets you some sort of audience or gives you some firsthand knowledge of how a particular industry works.)
My first thought was, "what if that project got lots of traction, and you didn't have the technical skills to continue iterating fast enough?". But I suppose that's a pretty good problem to have - you may find that you in fact can iterate fast enough, you may find it worthwhile to find and work with someone who could help you, and you'll probably learn a lot about users/startups/projects.
The downside I see is that working on a project may not be the best way to develop technical skills. For example, consider a front-end developer with almost no CS background - it may be worth it for that person to take some time building up a reasonable foundation of networking, databases, operating systems, algorithms and whatnot before taking the "learn by doing" approach. In the scenario where "learn by doing" is in fact the most effective way to develop technical skills, then it does seem to be a win-win situation. But in the scenario where it isn't, I think the downside of slower learning needs to be balanced against the upsides of a) potential success, b) learning about startups/users, and c) potential confidence stemming from a success spiral in the case where the smaller project is successful. I'm not sure what to think about this balance.
My first thought was, "what if that project got lots of traction, and you didn't have the technical skills to continue iterating fast enough?
How many startups do you know of that failed this way?
Twitter and reddit both survived despite major performance issues. And social media has quite low profit per HTTP request served relative to other web businesses. So I'd expect scaling to be much less of an issue if your startup is almost any other area. I also suspect that this kind of scaling failure is becoming rarer and rarer as the skills, resources, and technology to scale up a website get commoditized.
it may be worth it for that person to take some time building up a reasonable foundation of networking, databases, operating systems, algorithms and whatnot before taking the "learn by doing" approach
Apparently that kind of "foundational" knowledge gets forgotten after people graduate from college because it doesn't really get used: http://blog.triplebyte.com/bootcamps-vs-college I think a lot of this stuff functions partially as a way to signal intelligence. Although I'll grant that CS degrees are not as bad in this regard as most degrees are.
A compromise approach: If you are running in to a tricky issue with your database, give yourself time to study enough about databases so you have a decent mental model of what's going on under the hood so you can fix the problem. ("Just-in-time learning")
If you're worried about not knowing that a particular CS subfield is relevant to a problem your startup is facing, you could try Steve Yegge's breadth-first learning philosophy: http://steve-yegge.blogspot.in/2006/03/math-for-programmers.html Not all CS subfields are worth learning for this reason though. I think this justification doesn't really work for networking, databases, or operating systems. It might work for algorithms or artificial intelligence. However, I think it's a pretty weak justification overall. I still think diving in is a superior path.
If you have an inherent desire to learn more CS for some reason, you could deliberately pick a project that will require you to pick up some CS knowledge along the way. This will also look better on your resume (since it signals intelligence). It also creates a bit of a barrier to entry for competitors.
As for your points on learning by doing, I'm not sure what to think, but I appreciate and value them. I'm someone who tends towards textbooks and classes, but I've been slowly turning towards learning by doing. Both in theory, and in practice (ie. my life). At some point I plan on thinking about this question more thoroughly, and posting on LW about it. As for the question posed in this post, it's on the condition that learning by doing is not the most effective method (which may or may not be a correct premise, at least in my eyes).
You could try learning by doing as an experiment to see how it stacks up compared to textbook methods.
How many startups do you know of that failed this way?
I don't necessarily mean scaling, I mean iterating on product as well, because even with lots of traction, you still need to iterate on product, I assume. I base this on hearing advice from YC and the likes on the importance of continuously talking to customers and iterating, although I personally am not aware of enough data on startups to draw the conclusion strongly myself. The advice of YC may be wrong. And I may be misinterpreting it. What do you think?
It's possible that your startup will fail because you didn't iterate on the product fast enough, but so what? My guess is you will still have leveled up your dev skills at a rate comparable to self-study. The main bad outcome will be if you get discouraged by this failure and don't feel motivated enough to do another startup. That's why I suggest trying to create a success spiral. Try to pick a project where you can't really fail. You're just creating a nice little tool for yourself to use or something like that. Something that will look cool on your resume. Real world users are gravy. If you're having trouble coming up with ideas, PM me and maybe I can help.
Having a lot of traction is a good problem to have. It's something people work really hard to achieve. It's not something you usually achieve by accident. If you really want to avoid getting traction, just focus on developing your product and don't do any marketing. If you really have more interest than you can handle, talk to an angel, get some funding, and hire some solid programmers to work with.
My first ever web development project was a website that would generate random plots for Michael Crichton novels. I was inspired by this web page. I knew next to nothing about web development at this point. Someone submitted my app to reddit--you can see the discussion here. My second app was a website for students to buy and sell used textbooks. I taught myself a different framework to make that site, and I was still a novice web developer, but I still got it done before the end of the spring quarter. I plastered my college campus with advertisements and got hundreds of textbooks listed. That was a huge confidence boost. I felt motivated to tackle anything at that point. The next thing I chose was a project I wasn't passionate about in a "red ocean" full of competitors who went to crazy lengths to get customer attention. My skills as a web developer didn't give me a strong comparative advantage here. I didn't have a good theory of what motivated my users, and the task of promoting the heck out of my site didn't appeal to me. I've tried to start a few companies since then. I almost always end up teaching myself new technologies for new projects, but I never feel like technology is the bottleneck. I left MealSquares recently. (It was always more Romeo's project than mine--he's still working on it and I wish him the best of luck.) I'm not planning to start another company any time soon; I'm a little burnt out on startups. If I start another one, it will probably be something where I feel motivated to build the thing even if no one ever uses it.
iteration speed is less important than core quality I think. Minecraft was worth millions while still in alpha/beta and that didn't depend on how fast it was updated.
Facebook didn't start as a startup but as a side-project. You develop technical skills through actually writing code.
There seems to be evidence that programmer productivity varies by at least an order of magnitude. My subjective sense is that I personally can become a lot more productive.
Conventional wisdom says that it's important to build and iterate quickly. Technical skills (amongst other things) are necessary if you want to build and iterate quickly. So then, it seems worthwhile to develop your technical skills before pursuing a startup. To what extent is this true?
Furthermore, domain expertise seems to be important:
You want to know how to paint a perfect painting? It's easy. Make yourself perfect and then just paint naturally.
I've wondered about that passage since I read it in high school. I'm not sure how useful his advice is for painting specifically, but it fits this situation well. Empirically, the way to have good startup ideas is to become the sort of person who has them.
The second counterintuitive point is that it's not that important to know a lot about startups. The way to succeed in a startup is not to be an expert on startups, but to be an expert on your users and the problem you're solving for them.
So one guaranteed way to turn your mind into the type that has good startup ideas is to get yourself to the leading edge of some technology—to cause yourself, as Paul Buchheit put it, to "live in the future."
So then, if your goal is to start a successful startup, how much time should you spend developing some sort of domain expertise before diving in?