I, for one, think this is good advice for code in general. At least "at first, solve a problem, not a class of problems".
I have noticed that if I write my code too general at first, it ends up solving one class of problems kinda poorly, and ends up being re-written. If I write it for the specific problem I need to solve, and then generalize it to include another similar problem when I need to (and continue this process), I end up with very solid generalized code that solves a specific class of problems very (IMO) elegantly. It still gets re-written, but in a small-chunk iterative fashion.
This, of course, may be because of the way I think - or it may be due to me being relatively "young" as a developer. I am slowly generating more general purpose code that is getting reused for similar problems in different applications, however I write much more code for specific problems than I re-use.
Perhaps someone who's been doing serious coding work for more than a few years would like to weigh in on this?
I've always liked the rule of three; the first time, solve just your immediate the problem. The second time, notice that you solved the same problem twice. If the same situation occurs a third time, write a general solution.
Thoroughly enjoyed this post, especially since I remember a lot of these events as they happened. I was peripherally involved in the startup also for a good amount of time, and absolutely agree with everything he's said. I would also add that a big reason we had trouble getting off the ground was that Jon was really the only serious coder we had. The rest of us involved in the startup had skills in other areas (marketing, graphic design, etc), which although useful, were really NOT what the project needed at that point.
I would also say we probably fell in love a bit too much with our first idea, and probably held onto it too long.
Oh, and think (1) low cost, (2) sustainable, and (3) ability to monetize. We had #1 and #2 down pretty well, but had absolutely no real concept of how this thing could possibly make money. Most startups are NOT going to get taken over, so unless you are in it for non-$$$ reasons, it is probably a good idea to at least come up with some way you can profit if you manage to attract an audience but not a buyer.
Shout out to HN and to the community!! This is awesome!! I'm always encouraged and pumped learning from you all!! I don't think I would be following my passion and dream of hacking a webapp without you guys!!! =)
Nick
"I didn't realize how slowly I was working until I worked with a YCombinator company. I was making about 6-8 commits/day; they setup a new Subversion repository 2 days ago and it's already on revision 100."
Subversion commit rate is an abysmal measure of work speed.
They are, but nearly everything else is more abysmal. What else do you measure, lines of code/day? Hours spent working? Bugs fixed? New files created?
The nice thing about svn commits is that if you're doing atomic commits (and both organizations were, though I got a little sloppy about it with GameClay), 1 commit ~= 1 feature. There're still issues about what you consider a feature - if you do a feature right the first time and then check it in, is that better than if you check in a barely-working rough cut, then a couple UI enhancements, then some bugfixes for things you should've gotten right the first time? But those issues would crop up no matter how you try to measure forward progress.
Interesting, though I sure hope he is wrong about "If your idea starts with "We're building a platform to..." and you don't have a billion dollars in capital, find a new idea. Now.", since I work at a startup doing just that (buglabs.net). We are selling though, so hopefully we are gaining some traction.
Even a billion won't do. You can't write a "platform" from scratch. It just doesn't work. All successful platforms (yes, every last one of them) started out their life as useful tools with limited scope: the original Macintosh, Unix, Java, Rails, even windows. All of these things started out as specific products to fill a specific niche.
The only plausible counter-example I can think of off-hand is .NET. But even there, it started out not as a new from-scratch platform, but basically as a clone of Java with some windows-specific bits thrown in. So maybe a billion is enough if you're just trying to compete, not innovate.
There are probably exceptions to every single one of the observations I posted, but that one was the one that most stood out for me, both based on this startup and the last one I worked at. If I do a startup again, I'll definitely be waiting for an idea that's an app and not a platform.
Something to ask about your company: are you going out to find customers, or are they coming to you? If it's the latter, congratulations; you've succeeded where thousands of entrepreneurs have failed. But if you have to make lots of sales calls to close that one sale, it doesn't necessarily mean anything, even if you're profitable. Try enough prospects and one is bound to say yes, if only because they have money to burn and want to see if you can help them out. That was a lesson learned at my last employer, which was profitable before I joined but got no new business while I was there, because their revenue came from customers that didn't really use the product and just bought it because a couple million is a drop in the bucket when you manage a few billion in capital.
Of course, the latest "platform" example is facebook. Now, they're a platform for web apps, and I'm sure that was in their original vision. But they couldn't have started out saying "hey, we're a platform for apps". So they solved a problem (namely, the "I need to know more about my friends' lives & activities" problem) first. And THEN they became a platform.
"The initial idea does change, and it's almost certainly wrong. The thing is, the initial idea determines how the initial idea will change, which is crucial to all the execution that follows it"
I completely agree with this. Paypal would not have got it right if they didn't start with encryption technology or Microsoft with some kind of software.
You may miss the exact product initially but it has to be the right direction.
This is one of the better posts on this site. Long, insightful and educational. I'm sure Tang will be successful in the future, as he comes across and intelligent and humble.
Thanks. :-) There's actually a whole archive of posts (linked on the right) that detail my thinking at various points in the venture; I haven't seen it mentioned here, so I dunno if people don't know about it or haven't gotten around to reading anything but the postmortem or just aren't interested. Some of them may be helpful to folks though; there's a bunch on quitting the day job from July 07 and a lot of Pylons/Django comparisons in Dec 07.
I'm going on vacation in about 10 minutes, so I'm not going to see the rest of the discussion. If folks find other articles on the blog interesting, feel free to submit them; I have more than enough karma already.
Excellent post! One of the best ever. Very pg-esque.
It must take a lot of personal strength to put your failures out there for others to learn from. Thank you.
It's very, very difficult to wear both the developer and the evangelist hats at the same time: being a developer requires that you be very pessimistic, so you can see and fix all the problems in your design, while being an evangelist requires that you be very optimistic, so others can feed off your passion.
pg has mentioned many times that a startup is very difficult for a single founder. If I remember correctly, he says that because it's too much work for one person.
This is a slightly different angle that I had never really thought about. In effect, you'd have to be "Sybil" with multiple personality disorder to pull it off.
I tend to think of myself as a "very optimistic developer". I doubt I'd even try what I'm doing if I wasn't. Does this mean I may miss major design defects because of my rose colored glasses?
This was the part of the article that resonated the most with me. I wonder if this is the mechanism by which startups end up as big companies with totally useless IT departments - the people who built the stuff become identified as pessimists, and get starved for resources, good people leave, end up in a vicious cycle.
UNIX being a corporate project with billions of dollars of capital seems to be a slight mischaracterization (at least according to what wikipedia currently says, "some financial support from Bell", on the UNIX topic). Eventually it received more support, but it didn't start out like that.
[+] [-] kaens|18 years ago|reply
I, for one, think this is good advice for code in general. At least "at first, solve a problem, not a class of problems".
I have noticed that if I write my code too general at first, it ends up solving one class of problems kinda poorly, and ends up being re-written. If I write it for the specific problem I need to solve, and then generalize it to include another similar problem when I need to (and continue this process), I end up with very solid generalized code that solves a specific class of problems very (IMO) elegantly. It still gets re-written, but in a small-chunk iterative fashion.
This, of course, may be because of the way I think - or it may be due to me being relatively "young" as a developer. I am slowly generating more general purpose code that is getting reused for similar problems in different applications, however I write much more code for specific problems than I re-use.
Perhaps someone who's been doing serious coding work for more than a few years would like to weigh in on this?
[+] [-] llimllib|18 years ago|reply
[+] [-] run4yourlives|18 years ago|reply
Take a look at any piece of software you consider great, and you'll see that at version 1, it did very little, but did it well.
Conversely, take a look at something like Lotus notes, and you'll see that the opposite is true.
Consider yourself lucky to have discovered this idiom so early in your career!
[+] [-] alecthomas|18 years ago|reply
[+] [-] aston|18 years ago|reply
[+] [-] admoin|18 years ago|reply
I would also say we probably fell in love a bit too much with our first idea, and probably held onto it too long.
Oh, and think (1) low cost, (2) sustainable, and (3) ability to monetize. We had #1 and #2 down pretty well, but had absolutely no real concept of how this thing could possibly make money. Most startups are NOT going to get taken over, so unless you are in it for non-$$$ reasons, it is probably a good idea to at least come up with some way you can profit if you manage to attract an audience but not a buyer.
[+] [-] tptacek|18 years ago|reply
[+] [-] ucdaz|18 years ago|reply
[+] [-] boucher|18 years ago|reply
Subversion commit rate is an abysmal measure of work speed.
[+] [-] nostrademons|18 years ago|reply
The nice thing about svn commits is that if you're doing atomic commits (and both organizations were, though I got a little sloppy about it with GameClay), 1 commit ~= 1 feature. There're still issues about what you consider a feature - if you do a feature right the first time and then check it in, is that better than if you check in a barely-working rough cut, then a couple UI enhancements, then some bugfixes for things you should've gotten right the first time? But those issues would crop up no matter how you try to measure forward progress.
[+] [-] krschultz|18 years ago|reply
[+] [-] ajross|18 years ago|reply
The only plausible counter-example I can think of off-hand is .NET. But even there, it started out not as a new from-scratch platform, but basically as a clone of Java with some windows-specific bits thrown in. So maybe a billion is enough if you're just trying to compete, not innovate.
[+] [-] nostrademons|18 years ago|reply
Something to ask about your company: are you going out to find customers, or are they coming to you? If it's the latter, congratulations; you've succeeded where thousands of entrepreneurs have failed. But if you have to make lots of sales calls to close that one sale, it doesn't necessarily mean anything, even if you're profitable. Try enough prospects and one is bound to say yes, if only because they have money to burn and want to see if you can help them out. That was a lesson learned at my last employer, which was profitable before I joined but got no new business while I was there, because their revenue came from customers that didn't really use the product and just bought it because a couple million is a drop in the bucket when you manage a few billion in capital.
[+] [-] aneesh|18 years ago|reply
[+] [-] aditya|18 years ago|reply
go bug!
[+] [-] augustus|18 years ago|reply
I completely agree with this. Paypal would not have got it right if they didn't start with encryption technology or Microsoft with some kind of software.
You may miss the exact product initially but it has to be the right direction.
[+] [-] maxklein|18 years ago|reply
[+] [-] nostrademons|18 years ago|reply
I'm going on vacation in about 10 minutes, so I'm not going to see the rest of the discussion. If folks find other articles on the blog interesting, feel free to submit them; I have more than enough karma already.
[+] [-] DaniFong|18 years ago|reply
[+] [-] edw519|18 years ago|reply
It must take a lot of personal strength to put your failures out there for others to learn from. Thank you.
It's very, very difficult to wear both the developer and the evangelist hats at the same time: being a developer requires that you be very pessimistic, so you can see and fix all the problems in your design, while being an evangelist requires that you be very optimistic, so others can feed off your passion.
pg has mentioned many times that a startup is very difficult for a single founder. If I remember correctly, he says that because it's too much work for one person.
This is a slightly different angle that I had never really thought about. In effect, you'd have to be "Sybil" with multiple personality disorder to pull it off.
I tend to think of myself as a "very optimistic developer". I doubt I'd even try what I'm doing if I wasn't. Does this mean I may miss major design defects because of my rose colored glasses?
[+] [-] ojbyrne|18 years ago|reply
Great post.
[+] [-] wallflower|18 years ago|reply
[+] [-] jrockway|18 years ago|reply
Huh?
[+] [-] mechanical_fish|18 years ago|reply
Even better, a video of Linus Torvalds speaking on the history of Linux at the Computer Museum in 2001:
http://youtube.com/watch?v=WVTWCPoUt8w
[+] [-] thwarted|18 years ago|reply
[+] [-] louislouis|18 years ago|reply
[+] [-] zinxq|18 years ago|reply
[+] [-] mercury|18 years ago|reply
[+] [-] blang|18 years ago|reply
http://diffle-history.blogspot.com/2007/02/intro-post.html