dhouston

sam's still right. all kinds of red flags -- "i'll give up my job, but only if things are going well", "i have 2hr/day to spend", resentment already building, etc. it's only gonna get worse.

number2 -- that's fine that you have those priorities (family, steady job), but it seems like you're in denial about the situation. absentee (or remote + part-time, whatever) cofounders are not what early stage startups need. and even if you disagree, your potential investors (e.g. yc) won't. if being remote and working 2hrs a day was a viable strategy for a startup founder, don't you think there would be more success stories that fit that profile? :P

that said, you can still come on board later after #1 gets things going.

never thought i'd see the day where a pg comment gets voted negative :)

RTFA. the blog post lists a 2-3 word blurb for each company in the first paragraph.

do you know how much of a fucking heart attack that link just gave me??

haha. but this doesn't look like platypus (the real gdrive); just the ability to buy more storage for gmail, picasa et al.

(not saying gdrive isn't coming, but this ain't it.)

congrats guys!!

looks great guys!

ec2 and mysql (or memcached for that matter) don't yet play well together. we were going to deploy a big database across several EC2 instances but the lack of static IPs and internal routing quirks makes configuration and automated failover extremely complex. sadly, the ability to deploy lots of instances != the ability to scale effectively, at least for mysql/memcached.

rescuetime looks really cool guys. would love to give it a shot (i just signed up for the beta using frenetic at gmail dot com).

maybe i'm getting trolled here :) but i don't see how joel's background makes his points less relevant: - it's easier to fix problems on sketches/paper than in code weeks later - specs cut down on amount of communication needed -- especially with outside stakeholders - and help with schedule estimates, etc.

sure, in your typical web 2.0 app, many things are easy to re-work, but others (e.g. end-to-end unicode support/other i18n issues, scaling, schema design, etc.) are better baked in from the beginning (just ask friendster.) or at least be cognizant of the tradeoffs you're making and budget time to throw away your prototype.

also, google and ms have pretty rigorous software engineering processes and tools (hell, they hired GvR just to write a code review tool.) sure, in the early days it was probably looser. but not zero structure whatsoever -- the total free-for-all that "just do it" implies -- hell, even "release early and often" is a kind of software engineering discipline.

there are benefits to cutting corners (i.e. the zero planning implied by "just do it") like getting to market faster for certain kinds of startups (early market feedback, etc.) but these come at a cost later on! i like dharmesh shah's idea of 'technology debt':

http://onstartups.com/home/tabid/3339/bid/165/Development-Sh...

and your assertion that QA is something that happens only after a product already exists is equally misguided -- you can save a lot of time overall by thinking early about how to structure and instrument your code to make it easy to test.

if your response is 'well of COURSE you'd think about all these things up front', then that's not really 'just do it', is it :)

"Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for."

http://www.joelonsoftware.com/articles/fog0000000036.html

i agree that you shouldn't be writing three-ring-bound tomes, but spending a few hours planning out exactly what the thing will _do_ (just the 'what'; not even the 'how') usually teases out problems that you'd only find a few weeks into winging it.

all of those processes arose precisely because "just do it" doesn't scale. even for a small team, things like functional specs and other plans can save a lot of suffering (e.g. joel spolsky's 'painless functional specs' and other writings -- http://joelonsoftware.com )

(from http://lauren.vortex.com/googler-lyrics )

"Our data store of your actions makes NSA's look just like toys,"

bet their pr folks love that one.

4. not much effort spent figuring out what market they were going after or what problem they were solving

congrats guys!

we're in a similar space -- http://www.getdropbox.com (and part of the yc summer 07 program) basically, sync and backup done right (but for windows and os x). i had the same frustrations as you with existing solutions.

let me know if it's something you're interested in, or if you want to chat about it sometime.

drew (at getdropbox.com)

+1 to above...

also, you can start a startup whenever, and have the rest of your life to live the 'startup life' (i.e. worksleepworksleepworksleep until/while good things happen :)), but only 4 years of college.

i would argue that tagging coeds and having a social life also helps you later as a founder to get along with the non-engineers, who often bond over drinking and talking about tagging coeds :) (not to mention the recent spate of articles about parallels between dating and startups..)

and taking time off is good (i took a year off but still lived with my college friends) but the longer you take off, the more coming back sucks, because all your friends have graduated.

def birthday(people=23): from random import randint as rand; return sum([len(set([rand(1,365) for x in range(people)])) != people for i in range(1000)])

(constructs fewer inner lists, otherwise changes are completely cosmetic)

dude, give it a rest. and read:

http://blog.pmarca.com/2007/06/the_pmarca_guid_2.html

yc's already given you something better than what you'd get out of a canned one-sentence response: a fantastic resource in which anyone can put up their site and get a lot of feedback, for free, from a lot of smart people. 100% of the "hey news.yc check out my site" posts i've seen, including yours, have gotten useful, actionable feedback and have consequently improved.

i think they only care what you build, and if you're smart. the idea of blacklists, or pg holding grudges, etc., is pretty silly.

they're pretty clear on this: if you make something people want (or have a demo that shows that you will), you should be fine for the app.

i've done this kind of thing for spans of a year or two. besides the advice you're probably already getting, i'd say going running regularly helps a lot. when i was running, i'd be have a lot more energy throughout the day and night; when i wasn't i'd want to nap when i got home.

finding a cofounder is also a big productivity boost. find one early -- the more progress you make by yourself the harder it is to get someone else excited about "your" idea. if you're moonlighting, it's easy to put this off, but you're only hurting yourself long term. (i used to believe the single founder thing was doable for a while, but all of pg's counterarguments are right.)

the article seems more nostalgic than practical; languages/technologies that provide higher layers of abstraction generally prove to be winners in the medium to long run. i don't know if flex is the next big higher layer of abstraction for the web (and the analogy is a little broken because flex isn't really built directly on top of html/css/js.)

but i would love something that abstracts away the arcane bullshit that you have to deal with when manually dealing with html, css, js, browser incompatibilities, etc. in the same way that python/other HLLs abstract away the details handled manually with lower level languages (e.g. memory management, creating data structures more complex than a linked list, etc.)

re: daikatana i think you mean john romero, not john carmack (it was ion storm, romero's game co -- though yes it was based on the quake engine/carmack's work)

cool idea, but it's a pretty small niche/problem to solve -- which is fine, but maybe not something to expect millions of people to use

that was enough of a kick in the ass to sign up for coverage (after having intended to for a while but never really getting around to it), thanks for the post :P

btw, other summer yc founders in cambridge (or other massachusetts residents): go to http://mahealthconnector.org ; the lowest plan costs like $119/mo and it takes like 5 mins to enroll and it's all online.

great interview, guys. i love the "make delicious software" quote... haha. keep kicking ass.

well, the negotiation will take some finesse, and might not have a happy ending.

if both sides were happy with the prior terms and had the same expectations -- i.e. you didn't really understand or investigate your compensation compared to market value, and/or they deliberately lowballed you -- they're probably not going to be thrilled about revising things right now if they're also stressed out with the crunch and also not too excited about paying more for the same labor (or having other stressed out employees grumble for more comp, or wondering if you'll threaten to leave again in the future, etc.)

so even though you may be justified in asking for more, it might be tough to get it given the constraints on their end. if, though, both sides expected at the outset you'd be working a normal 40 hr week and you're working 2x that, then the negotiation would probably be easier.

the good news is you'd have no problem snatching up another (probably cooler) gig -- just look at the yc job postings :)

how much and/or how many rounds of funding has the startup had? how many employees are there?

it depends, and in my experience can be reduced to a cost/benefit analysis. a sprinkle of different things has worked for me -- some things to think about:

what's the impact of a typical bug in your app: an error 500 page (annoying) or a BSOD or corrupted data (much worse) or a missile hitting a house? these will merit different levels of testing rigor.

if something is breaking, how do you even know? how much time will have elapsed? how long will it take you to find the cause, and is suitable debugging information available for your investigation? how quickly can you come up with a fix, and how expensive is it to deploy it? this is, in my experience, a much more effective place to optimize if you're a web app, especially if you're a small team.

for the non-core pieces of a web app, i'd rather release twice as fast and have logging and monitoring infrastructure in place to find and fix problems quickly (e.g. exception - logged and SMSed to our cell phones) than spend 2x to write unit tests (and maintaining them later.) a nice property is that you'll tend to find bugs roughly in order of decreasing impact, or at least prevalence. however, this approach won't do much against silent failures or bugs that are both rare and high impact.

there are lots of other effective tools: automated smoke tests (by which i mean end-to-end tests that quickly test large pieces of the app) deliver a lot of bang for buck, and root out unintended consequences of seemingly local changes that even unit tests sometimes miss. i also find generous use of the assert keyword finds failures fast/nearer to the cause.

enfp.. usually either entp or enfp :P

great article; the piece about the phase most developers go through where they like complexity for complexity's sake definitely resonated (or fancy algorithms, or design patterns, or whatever other programming-related book they just read.) if you've worked with developers like this (or gone through these phases ;)), you probably had flashbacks too -- wading through AbstractVisitorManagerDelegate classes, or half-baked home-grown heap allocators makes a little part of me die inside.