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

41–50 of 96 posts

Re: Employee #1: Dropbox

#41

Post by jacalata »

dasmoth wrote: post #35
jacalata wrote: post #31

Earlier quoted context omitted.

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."

I don't think it fits under that at all, and I find that when people do see it that way it gets an entirely different treatment. "Manual testing" is an activity you do when you are thinking about how the product works. "Dogfooding" is a culture of using the product in order to achieve other tasks that you really wanted to get done.

Re: Employee #1: Dropbox

#42

Post by marcosdumay »

bch wrote: post #15
diamondtrim wrote: post #11

Earlier quoted context omitted.

Never used mercurial. I suspect it's just as good, but the problem the author probably sees is, like me, most everyone is familiar with git and new hires need to be trained in something unfamiliar with less community around it.

I wonder how large that friction is. I look at git, mercurial, etc as distributed version control first and foremost, and that they're more alike than different. It could be that I witnessed the popular adoption of all this via Linux going from tarballs/patches/mailing lists -> bitkeeper -> git, and have used and witnessed-the-evolution-of rcs, cvs, subversion, various DSCMs, and so my concepts of source control are…

If you are used to an "always branch" workflow, mercurial can impose a lot of friction.

Re: Employee #1: Dropbox

#43

Post by psyc »

_RPM wrote: post #36
psyc wrote: post #28

Earlier quoted context omitted.

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.

Yeah, it's probably statistically more likely for success to breed success. It's fine to know that as long as we don't let that alone stop us.

Re: Employee #1: Dropbox

#44

Post by vazamb »

A minor detail, but I am surprised about the whole "it was hard to figure out when someone moved a file" thing. I always assumed the actual file on disk was abstracted away into a database record, that specified the folder etc. Were they actually using S3 Bucket/Folders for file structure on Dropbox itself?

Re: Employee #1: Dropbox

#45

Post by phonon »

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.

There is one built into Chrome now.

https://developers.google.com/web/tools/chrome-devtools/prof...

Re: Employee #1: Dropbox

#46

Post by hoov »

vazamb wrote: post #44

A minor detail, but I am surprised about the whole "it was hard to figure out when someone moved a file" thing. I always assumed the actual file on disk was abstracted away into a database record, that specified the folder etc. Were they actually using S3 Bucket/Folders for file structure on Dropbox itself?

It was more of a lack of abstraction than anything. The server reflected more or less what the OS presented -- an add and a delete rather than a move. Putting the pieces together later to present better information to the user was difficult. Not sure what they do today, but I remember many talks about ways to put that abstraction in place as close to the OS as possible. Reconstructing multiple, quick, renames/moves after the fact proved to be somewhat difficult from the frontend, which Aston worked on.

Re: Employee #1: Dropbox

#47

Post by ptomato »

thedufer wrote: post #39
nostrademons wrote: post #27

Earlier quoted context omitted.

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 reques…

Still exists. https://developer.apple.com/download/more/?q=Hardware%20IO%2... is the link you're looking for.

Re: Employee #1: Dropbox

#48

Post by billmalarky »

_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.

Drew built the MVP for dropbox as a side project while working fulltime for another company, that's how it was "funded before it was funded."

Re: Employee #1: Dropbox

#49

Post by pensive_returns »

An interesting titbit Aston leaves out about his early days is that he was actually cofounder of AutoAdmit.com[0], a law school admissions forum, semi-notorious for its defamation lawsuits and being an incubator for troll, Michael O. Church[1] (banned on Quora, Wikipedia, and Hacker News for being a thorn in Paul Graham and Dan G, sides) that formed after the great Princeton Review Discussion Board exodus and has persisted with an active user base for almost 13 years now. I wonder if he's ashamed of that history since he fails to mention it (despite it being on his early resume!).

[0] http://www.autoadmit.com/ [1] https://michaelochurch.wordpress.com/

Re: Employee #1: Dropbox

#50

Post by qq66 »

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.

Because 1) for brand new startups, which all kind of seem like dumb ideas or impossible ideas at the beginning, only a very small fraction of very talented people are willing to join, and 2) at such a small team size, there's so much more than talent that matters. You'll end up working with that person so closely that they can't just be smart or talented -- you have to trust them to be a partner in helping steer your company towards what it's eventually going to be, in product, technology, culture, etc.
Post reply on HN