Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Employee #1: Dropbox

themacro.com

Post reply on HN
Print view View original

31–40 of 96 posts

Re: Employee #1: Dropbox

#31

Post by jacalata »

dasmoth wrote: post #21
typetypetype wrote: post #2

> We were all using the product so when there was funny stuff we tended to catch it. I love this. There have been so many times I've run into a bug that makes me wonder if anyone on the engineering team actually used the product.

I somewhat blame this on the emphasis that now gets placed on automated testing (to the extent that nobody actually pronounces the "automated"). It's got some good points, but if it comes at the expense of manual testing I'm not convinced that's always a great trade-off, especially for interactive software.

I don't think conflating dogfooding with manual testing really works - they are different actions and you can have a dogfood culture without manual testing, or vice versa.

Re: Employee #1: Dropbox

#32

Post by zenlikethat »

ryandrake wrote: post #26
keithwhor wrote: post #10

I was lucky enough to hear this story almost verbatim from Aston and it's so exhilarating to listen to how much fun everybody seemed to be having. He tells it with a lot of enthusiasm that you can feel just from the depth of his responses. I think the one thing that stuck with me, personally, is the issues Dropbox had in the early days (TC 50 tech issues) and that it took six months to get Aston on board. From what I…

What I don't get is why try to recruit the same person over and over for six months? I wonder what the outcome would have been had they just hired someone else equally as talented right away instead of going without an employee for all that time. You can't re-play these things so we'll never know, but it just seems odd to me.

Chemistry and low risk. They knew what they were getting which is worth its weight in gold considering how hard it is to generally judge how well software engineers will perform once on the job.

Re: Employee #1: Dropbox

#33

Post by krupan »

dude_abides wrote: post #7

> But I ended up picking Mercurial for the distributed version control system, which we were definitely wrong on that one–should have picked Git. I'm curious to know: is this sentiment widely shared? Is git really that much better than hg?

Yes, the sentiment is widely shared.

No, git is not really that much better than hg (I personally find hg to be superior).

Re: Employee #1: Dropbox

#34

Post by williamstein »

dude_abides wrote: post #7

> But I ended up picking Mercurial for the distributed version control system, which we were definitely wrong on that one–should have picked Git. I'm curious to know: is this sentiment widely shared? Is git really that much better than hg?

In my experience, yes. With SageMath we put a huge amount of work into switching from Mercurial to Git (I had originally chosen Darcs, then switched to Mercurial, then we switched to Git). In practice, the depth of functionality with Git can sometimes be an order of magnitude greater than that of Mercial, just do to git accumulating so much more developer momentum (see, e.g., the man pages for "git log" versus "hg log").

Re: Employee #1: Dropbox

#35

Post by dasmoth »

jacalata wrote: post #31
dasmoth wrote: post #21

Earlier quoted context omitted.

I somewhat blame this on the emphasis that now gets placed on automated testing (to the extent that nobody actually pronounces the "automated"). It's got some good points, but if it comes at the expense of manual testing I'm not convinced that's always a great trade-off, especially for interactive software.

I don't think conflating dogfooding with manual testing really works - they are different actions and you can have a dogfood culture without manual testing, or vice versa.

If you're talking about manual testing in the sense of "run down a long checklist", yeah that's different and automated tests are a better (although still not perfect) substitute for that kind of thing. But definitely still consider dogfooding to fall under "manual testing."

Re: Employee #1: Dropbox

#36

Post by _RPM »

psyc wrote: post #28
_RPM wrote: post #23

Earlier quoted context omitted.

Yep. That explains how he was able to focus full time on Dropbox then. He must have always had a trampoline to bounce him back up should he fail. I know it was funded from the beginning most likely, but there had to have been a time before it was funded.

I know it's fun to be envious of rich people, but I grew up in poverty, and so far I've earned myself 5 years to focus full time on my stuff. I know it's a little harder, maybe, but all I had to do was go to work first. Most people go to work anyway.

Maybe I did come off as envious, but I'm not angry, or sad, or feeling like I don't have opportunities to be a successful startup founder myself. It's just that you do often see a pattern among founders. It's so common that I've started noticing it.

It's certainly not true that you have to come from a privileged family to be a successful entrepreneur. Look at examples like Larry Ellison.

Re: Employee #1: Dropbox

#37

Post by mkagenius »

nostrademons wrote: post #30
ryandrake wrote: post #26

Earlier quoted context omitted.

What I don't get is why try to recruit the same person over and over for six months? I wonder what the outcome would have been had they just hired someone else equally as talented right away instead of going without an employee for all that time. You can't re-play these things so we'll never know, but it just seems odd to me.

They didn't have funding (other than YC, which at the time was $6k/founder, not nearly enough to support an employee) until right before they hired Aston. Drew had approached me about being employee #2 for DropBox, and I had lunch with him, Arash, and Aston in Feb 2008. They'd only closed the Sequoia seed round about a month before. IIUC, Aston had been officially hired the day before. I (stupidly in hindsight, but f…

Interesting example. Genuine question, had it been the opposite, if you circle back in time, would you really take that job? (Trick question: Are you less happy than you think you would have been in other case?)

Re: Employee #1: Dropbox

#38

Post by hemancuso »

_RPM wrote: post #23
samfisher83 wrote: post #16

Earlier quoted context omitted.

His dad went to harvard so I am guessing he grew up pretty well off.

Yep. That explains how he was able to focus full time on Dropbox then. He must have always had a trampoline to bounce him back up should he fail. I know it was funded from the beginning most likely, but there had to have been a time before it was funded.

The trampoline is the MIT degree and incredible engineering talent. If Dropbox failed Drew could've gotten a job within a few days.

Re: Employee #1: Dropbox

#39

Post by thedufer »

nostrademons wrote: post #27
BinaryIdiot wrote: post #25

Earlier quoted context omitted.

Such a genius idea. I see far too many web applications not caring about latency. Forcing a developer to experience the same pain should help them. Unless that simply becomes the day everyone typically takes off, blames productivity on slow network connectivity, etc.

Google had a latency proxy on the corp network that you could use to simulate dialup, 2G, DSL, etc (along with unreliable connections). It was a great tool, and you could learn a lot by doing all your normal searches through the latency proxy. Alas, not many developers knew about it, and even fewer were willing to take the convenience hit to use it as part of their normal experience.

OS X used to have a "Network Link Conditioner" that shipped with XCode, I believe. It did a lot of the things you're suggesting, but right at the network interface level. Unfortunately, it broke with the advent of Mavericks. No idea whether it works now, or even still exists.

On the last web-app project I worked on, we had a middleware that activated automatically in dev mode and just inserted a delay in every request to bring a local delay up to our users' median delay. It was intentionally a bit of a pain to turn off, so almost everyone ran in that mode.

Re: Employee #1: Dropbox

#40

Post by marcosdumay »

dude_abides wrote: post #7

> But I ended up picking Mercurial for the distributed version control system, which we were definitely wrong on that one–should have picked Git. I'm curious to know: is this sentiment widely shared? Is git really that much better than hg?

Mercurial supports only a subset of the use cases of git, while adding no exclusive functionality.

It is true that it is the subset that 90+% of the people need. But there are network effects on VCS, making git a clearly superior choice.

Post reply on HN