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