"Solve a problem, not a class of problems." 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 pr…
Diary of a Failed Startup
11–20 of 35 posts
Re: Diary of a Failed Startup
#12I 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.
Re: Diary of a Failed Startup
#13"Solve a problem, not a class of problems." 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 pr…
Re: Diary of a Failed Startup
#14"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 fi…
Joy.
Re: Diary of a Failed Startup
#15"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 fi…
In theory all of our commits are approximately one feature, and I can't, for the life of me, imagine finishing 100 features in 2 days (even split between all three of my team). Clearly there's some disconnect between what different people consider to be a feature.
For the record, we've made a little over 1000 commits in the last five and a half months. I certainly don't think that makes us 20 times less productive.
Re: Diary of a Failed Startup
#16Re: Diary of a Failed Startup
#17This 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.
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.
Re: Diary of a Failed Startup
#18I 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.
Re: Diary of a Failed Startup
#19"Solve a problem, not a class of problems." 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 pr…
Re: Diary of a Failed Startup
#20More posts like this, pls.