Can you talk more about your method for solving problems? That's normally where I get stuck.
1,235 karma · joined November 24, 2011
TJ? :P
And that's the point the original article was trying to make ("The reason turns out to be embarrassingly simple: the Dunning-Kruger effect has nothing to do with human psychology. It is a statistical artifact — a stunning example of autocorrelation."), though that point does lost a bit as it goes on.
I think this article gives a better summary of how the Dunning-Kruger effect probably isn't a psychological effect: https://www.mcgill.ca/oss/article/critical-thinking/dunning-...
> Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons <waveshand>
> It's the reason we display this when you try to do it. But a better fix would be for us to make it more easily reversible in the future.
https://twitter.com/martinwoodward/status/149333649025189478...
Changes:
- When I joined in 2015, it was already forbidden to just log text on the server. Only a small number of SREs even had access to the text logs. Any event that you cared about needed to be logged from the system described in "App-specific metrics", which was pretty easy to use. (That said, on desktop we still used logspam because when you're debugging a desktop client doing the wrong thing, sometimes the only lead you have is tracing which lines of code are being run by looking at which logs are being printed.)
- Re: shards, by the time I joined most of the mysql was replaced by a homegrown KV/graph database on top of mysql that had a fixed number of shards (something like 255).
Things that didn't change (at least by the time I left in 2020):
- Everything was in UTC, including in the UIs for everything (e.g. metrics, exceptions, crashes, etc). I ended making a GPS clock that showed UTC to put on my desk as a fun project, and I know at least one SRE who had set basically all their clocks to UTC time (e.g. phone, laptop, calendar, etc). This is in contrast to Google, where almost every system either shows your local time or "Google Standard Time" (which is just Pacific Time).
- Python was still used for virtually everything.
That said, I think what I noticed at Dropbox is that asking lots of tough questions gets you a lot of pretty talented folks who are very interested in solving hard technical problems. So from an infrastructure side, Dropbox was overflowing with talented people. From the product side, though, it was harder for teams to staff frontend projects or make progress when their ideas were challenged by infra.
I'm also not sure how it is at other companies (at Google but haven't gone through interview training yet), but Dropbox's rubrics are also pretty strict. Doing "well" on a question requires getting through multiple parts normally with close to zero bugs that you don't catch yourself.
If that's actually the reason for the question, that's clever :P It doesn't necessarily imply that they cheated, but maybe they use that to flag candidates. I've done a lot of interviews, and there were a couple of phone interviews where I suspected the candidate was cheating.
That said, there are no American sports with a promotion/relegation system (probably because those systems evolved organically in Europe from local teams just becoming good and gaining a following, and the American way of having billionaires owning one of a small, fixed set of teams means that they want to protect their investments and wouldn't accept a chance of being relegated and losing their valuable TV money), so it would be interesting if one of them picked it up. From an outsider's perspective, though, I think it'd probably be better to bias towards simplicity instead of trying to fix every problem. E.g. instead of having the "must win 86 games in two/three seasons to make it to the champions league", fix the number of teams in the top league and promote the top of the bottom league and relegate the bottom of the top league. Making the system more complicated to prevent teams from tanking probably isn't a worthwhile tradeoff, since 1) it sucks when teams tank, but it's very exciting when a bad team starts to do very well (e.g. the Bengals at this year's Super Bowl), and 2) that system still doesn't stop the teams at the bottom of the second league from tanking, since there's no punishment for them and they can get better draft picks.
Though my 2c to improve baseball as someone who just started watching football and tried to follow baseball when I was younger:
1. Reduce the number of games. In football, there are so few games that each one matters a lot. In baseball, there are so many that it's hard to be invested.
2. Find a way to make games more fun to watch on TV. Going to a ballpark in person is always a fun, chill experience as long as you bring a friend. That atmosphere doesn't translate when you're watching on TV, so the game itself probably has to be made more exciting in some way (add more time pressure, or let the players take steroids /s).
We started out with the same approach as you guys, by introducing Typescript to the company, making it possible to write code in Typescript, and encouraging teams to use it. We had an OKR to convert all of our Coffeescript to Typescript by the end of the year, though, so eventually we had to go with an automated approach to convert the rest of the files, which you can read about here: https://dropbox.tech/frontend/the-great-coffeescript-to-type...