dhouston

Fair criticism. The tricky part though with any scaled service is that for every legitimate case like this, there are many more bad actors trying to hijack accounts through exactly this mechanism -- so account recovery has to be conservative by default, which means legitimate cases sometimes get caught in the friction. Not an excuse, but it's a hard problem at scale and not just e.g. a cost-cutting thing or not giving a shit.

Hi Josh -- Drew here -- our escalations team should be reaching out shortly. (Losing phone, 2FA keys, etc. can be tricky but they should be able to work with you and hopefully verify enough to get you unblocked.)

+1 — cut my teeth on learning C in middle school by hacking up a DikuMUD derivative. So many great memories of that period.

And not just C but Linux (Slackware!), sockets, even kludging the single-player DOS port to be two-player by playing over a serial cable to another PC. And annoying my future Dropbox teammates by including an extra space after/before parens in function calls (and if/for/switch statements), putting { on its own line, etc as was the convention in that code base IIRC.

Qlora + axolotl + good foundation model (llama/mistral/etc, usually instruction fine tuned) + runpod works great.

A single A100 or H100 with 80GB VRAM can fine tune 70B open models (and obviously scaling out to many nodes/GPUs is faster, or can use much cheaper GPUs for fine tuning smaller models.)

The localllama Reddit sub at https://www.reddit.com/r/LocalLLaMA/ is also an awesome community for the GPU poor :)

This strikes me as a good place to start, both for founders who are running something for the first time and also for more experienced execs as a good review of the fundamentals. In other words, I wish I had seen something like this when I was starting Dropbox in that a lot of our scaling problems would have been prevented by doing these basic things properly and consistently.

(I don't know Matt, and haven't been coached by him, but I do know a lot of the founders he's coached, and have read his book https://www.amazon.com/Great-CEO-Within-Tactical-Building-eb... which covers much of the same material.)

To be clear (if you only read the headline :)), not entirely remote. Solo work at home, collaborative work in "studios", basically reimagining the offices into collaborative/convening spaces that you go into from ~once/week to once a quarter depending on team/role.

Remote-only cuts out the in-person experience entirely, which is problematic for building teams and culture; and ad hoc "WFH whenever you feel like it" gets a sort of worst-of-both-worlds situation where you neither get the same kind of flexibility nor the sense of community you typically get from an office (since a large percentage of the team isn't there on any given day, and folks that come in the office less tend to be at a disadvantage in terms of visibility & recognition).

IMO this post has some good points but makes the executive sound like a passive referee, ultimately misunderstanding what High Output Management (also one of my favorite books!) is about. (Admittedly adding my own editorial here from my experience founding a startup and now running it as a ~3,000-person public company.)

The basic principle of HOM is that the fundamental job of an executive is to deliver results ("output"), and that the measure of an executive is the output of their organization. Importantly, there is no one right way to deliver results -- successful CEOs can have very different styles and techniques.

That said, for every effective way to deliver results there are vastly more that are ineffective. Complexity, ambiguity, and uncertainty are not your friends. Time is not your friend. Everything is situationally dependent. There are many skills to develop and principles that can help but there's no formula.

This also partially explains why the median CEO or exec is perceived as ineffective, often because they are. It's a hard job, otherwise everyone would do it well and there would be a surplus of good (and cheap) execs.

Contrary to what the post suggests, HOM does not say not that the job of an executive is to wave some kind of magic culture or "values" wand and rubber-stamp whatever emergent strategy and behavior results from that. CEOs and executives absolutely do (and must) make important decisions of all kinds, break ties, and set general direction. Occasionally they need to give commands but more typically you work collaboratively with and (as the post correctly suggests) empower your team and avoid doing too much as an individual contributor.

If you're curious about what execs do and how to be a good one, HOM is an incredible book. The Effective Executive by Drucker is another favorite.

https://hbr.org/2009/05/what-only-the-ceo-can-do is one of my favorite articles about the responsibilities of the CEO.

https://hbr.org/2018/07/the-leaders-calendar is a fascinating study of where CEOs spend their time and what they actually do day to day.

Thank you Paul and Jessica for taking a chance on us — we wouldn’t be here without you and YC :)

And thank you HN — I’m pretty sure the upvotes on the original screencast helped us get into YC and on Paul & Jessica’s radar to begin with!

Even you BrandonM — https://news.ycombinator.com/item?id=9224 — my favorite HN comment thread of all time :)

it's not going anywhere :)

(actually, come work on it: https://www.dropbox.com/jobs :))

yes we are :)

wildly out of context (comically so if you know me IRL) -- oh well :)

UI isn't the only platform-specific thing in the code; we have a bunch of (non-Python) native code on each platform to monitor filesystem changes.

just so everyone knows, this complaint raises old issues that we addressed in our public blog post a few weeks ago: http://blog.dropbox.com/?p=735

we have a variety of easy-to-use sharing mechanisms (public links, shared folders, etc.) that people have been using for a long time for legitimate uses.

to be clear, we _never issued_ any DMCA takedowns to anyone -- the OP incorrectly received a bizarrely-worded email from us saying we had received a takedown notice from ourselves (no such notice ever existed) for which we've apologized.

We didn't file a takedown to github -- the author voluntarily took the code down

correct -- fixed this distinction in my reply, thanks

i can promise you we're not trying to piss off the HN audience, but sometimes we manage to anyway :)

drew from dropbox here. i hope you guys can give us the benefit of the doubt: when something pops up that encourages people to turn dropbox into the next rapidshare or equivalent (the title on HN was suggesting it could be the successor to torrents), you can imagine how that could ruin the service for everyone -- illegal file sharing has never been permitted and we take great pains to keep it off of dropbox. the internet graveyard is filled with services that didn't take this approach.

so, when something like this gets called to our attention, we have to do something about it. note that this isn't even by choice -- if we don't take action, then we look like we are tacitly encouraging it. the point is not to censor or "kill" it (which is obviously impossible and would be idiotic for us to try to do), but we sent kindly worded emails to the author and other people who posted it to take it down for the good of the community so that we don't encourage an army of pirates to flock to dropbox, and they voluntarily did so.

there were no legal threats or any other shenanigans to the author or people hosting -- we just want to spend all our time building a great product and not on cat-and-mouse games with people who try to turn dropbox into an illegal file sharing service against our wishes. (for what it's worth, dropship doesn't even work anymore -- we've fixed the deduplication behavior serverside to prevent "injection" of files you don't actually have, for a variety of reasons.)

that said, when we disabled public sharing of that file by hash, it auto-generated an email saying we had received a DMCA takedown notice to the OP, which was incorrect and not what we intended to do, so i apologize to dan that this happened.

(*edited the last paragraph: we didn't send a takedown notice, we sent a note saying that we received a DMCA takedown notice, which was also in error)

go for it :) jobs+hn@dropbox.com

yes, hence the title "TC Cribs"

no, it's not. it's saying that if you can quickly gain an audience (the hard part) by deliberately making a "feature" that can spread quickly (instead of a full-fledged product) you can parlay that audience into something more substantial later.

(delivering an MVP or shipping early is more oriented towards quickly seeing if a market exists/initial assumptions are correct)

thought i'd weigh in on this

obviously if you are an amazing engineer without a degree, of course come talk to us. arash, my cofounder and the slacker that he is, does not have his bachelor's degree :)

so hope you can give us the benefit of the doubt that we didn't intend to exclude qualified people

we're bummed about this. it's probably a fruitless exercise, but does anyone have any insight into how to get unblocked?

this is really impressive -- high fidelity, search, scrolling, no waiting for flash to load. congrats guys! we'd love to get this kind of previewing on dropbox

I've known a few people in this situation. If you're feeling completely burned out, you might want to chill out and travel around for a few weeks (or whatever) to clear your head. After that:

- If you want, go back and get your degree (it only gets harder as you get older)

- Do an entrepreneur-in-residence gig (instead of an associate.) From what I've seen, EIRs do anything from hanging out and shooting the shit all day (i.e. very little) to reviewing investments/networking/helping portfolio companies to actively incubating their next idea (or a bunch of ideas simultaneously)

- Join a growing startup that is past the ramen-fueled-fight-for-survival frenzy, which might be a good balance of upside vs expected value. A lot of former YC founders do this if their companies don't work out. As a current venture-backed founder/CEO, I can say with certainty that your startup experience would be highly valued.

- Join Google, Microsoft, or Facebook, check your dreams at the door, and ride out comfortably into a middle-aged sunset (I kid, I kid.)

Feel free to email me at drew at dropbox[dot]com if you want stories or intros to people who have been through this.

believe it or not, this was intentional and an homage to slashdot (the concept of having low IDs that are publicly viewable), however obscure

the public link feature was actually a proof of concept and never intended to stick around :)

but anyway, having this information doesn't let you do anything but get a rough count of our users, so saying it's a security issue is a stretch. there are no public-facing forms or inputs that take these values as input

my cofounder arash and team definitely deserve more credit than i do.

This is dangerous advice; failing fast is way better than failing slow. To get to (in your example) breakeven in year 2, you better be showing traction in year 1 after launch, or at least signs of life, which they were not. No one liked or cared about what they were building, and they wisely realized they had no idea what market they were really going after and (after several months' worth of learning) still had no evidence one even existed.

Given they're still at square one, if they identified a more promising market, they should go for that, and it takes a lot of discipline to admit that all that prior effort is sunk cost.

Article said a couple years after going public he sold his remaining stake, bringing his total gains to $100mm (presumably cash.)

Dropbox is hiring -- we need great Python (ideally C/C++ too) hackers. YC '07, later backed by Sequoia and Accel, growing like crazy (almost 2 million users, up from <100k this time last year)

jobs@getdropbox.com, please put "HN" in the subject