dhouston

20 ms·

151.
by dhouston 19y ago
why not something higher level (e.g. python)? just curious
152.
by dhouston 19y ago
i disagree. the interesting points aren't about food -- for example, it's a case study in how a lot of smart people, over a long period of time, can fool themselves -- in fact, the movements to improve software engineering have the same kin
153.
by dhouston 19y ago
i wouldn't bother trying to push the $5k+$5k*n . i think that precedent is pretty much set in stone. and even if you tried, the extra cash wouldn't matter much, and you'd more likely piss pg off than anything else.
154.
by dhouston 19y ago
in general, the median's around 6% and i think is also the most common, and i didn't encounter anyone who had negotiated it down. i don't think there's a formula. we had a working demo, and thousands of lines of code, but got the same deal
155.
by dhouston 19y ago
looks great, guys. i would bet that your chances are very good.
156.
by dhouston 19y ago
if you can, get traction first -- your valuation will be much higher; investors pay a lot for momentum. and start building the team early -- it's unlikely you'll get funded as an individual.
157.
by dhouston 19y ago
articulating your idea concisely (under the 120 word limit or whatever) and getting to the point quickly will be useful for yc and beyond (other investors or whomever else you need to sell.) make it easy to parse what you're doing and why i
158.
by dhouston 19y ago
what's a one or two sentence explanation that would get my little sister to use this? what value would she get within the first 2 minutes (assume early on, before you have a ton of people using it?) ideas like this are tough because they're
159.
by dhouston 19y ago
this is good news :)
160.
Mozy acquired by EMC for $76MM(techcrunch.com)
18 points by dhouston 19y ago|8 comments
161.
by dhouston 19y ago
peter was making the point that moore's law won't, for example, make my round-trip latency from sf to boston much less than 90ms, so optimizing to reduce round-trip times (and to a lesser extent, bandwidth) will _always_ be necessary to des
162.
by dhouston 19y ago
via a mutual friend at MIT who was also a yc founder. we lucked out in that it turned out to be a good fit.
163.
by dhouston 19y ago
find a cofounder! yc generally funds teams and isn't in the business of matchmaking. ("find a cofounder" is what pg will probably tell you; it's what he told me repeatedly before my interview. it was a big time investment to find the right
164.
by dhouston 19y ago
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 priori
165.
by dhouston 19y ago
never thought i'd see the day where a pg comment gets voted negative :)
166.
The Startup Game: How Anywhere.fm is building a hit niche(blogs.business2.com)
34 points by dhouston 19y ago|5 comments
167.
by dhouston 19y ago
RTFA. the blog post lists a 2-3 word blurb for each company in the first paragraph.
168.
by dhouston 19y ago
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
169.
by dhouston 19y ago
congrats guys!!
170.
The Fuzzwich Cartoon Maker (yc summer 07)(techcrunch.com)
29 points by dhouston 19y ago|23 comments
171.
by dhouston 19y ago
looks great guys!
172.
Greed Is Good and Ugly(nymag.com)
4 points by dhouston 19y ago|0 comments
173.
by dhouston 19y ago
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
174.
by dhouston 19y ago
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).
175.
by dhouston 19y ago
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 -- especiall
176.
by dhouston 19y ago
"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 t
177.
by dhouston 19y ago
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 -
178.
by dhouston 19y ago
(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.
179.
by dhouston 19y ago
4. not much effort spent figuring out what market they were going after or what problem they were solving
180.
by dhouston 19y ago
congrats guys!

More ›