I never worked for google (interviewed but was rejected) but I have suspected this is true -- that there was a sweet spot where google was a magical place, but that time has long passed.
One of the better decisions I ever made was not ignoring emails from folks recruiting for Amazon in 2003. It was a different place back then, and truly like "the world's largest startup." The other thing that was different back then was that the people I worked with were all so blindingly smart. I'm pretty smart, but in 2003 I often felt like the dumbest person in the room[1]. In 2025 that feeling was rare, and not simply because I had 20 years more wisdom.
I left Amazon for the third and last time a couple months ago and have no regrets.
If you're still there and reading this, Amazon still has a lot going for it as a place to work. But it's not the electric place I recall from 20 years ago. I'm not sure if there is any company that can match both the startup-like freedom of action with massive scale of early 2000s Amazon.
[1] In case it isn't obvious: this is a desirable condition because it means you get to learn something.
I wrote a talk entitled How Humans See Data that puts several of these ideas, among others, into a coherent framework based on research by Bill Cleveland.
In 1999, front end templates were written in an internally developed macro language named catsubst and served by a C (maybe C++?) application named Obidos. Later (starting in 2003-ish), front end code was written in Perl (Mason) and served by another application named Gurupa. The transition to Gurupa was very long and arduous. I've no idea how the site works now.
Your control is greatly reduced in aerobars, but more importantly, your ability to defend your space is hugely reduced, which makes riding in a pack extremely dangerous. This video explains why having the ability to protect your bars prevents crashes: https://www.youtube.com/watch?v=sRIsWzrMmBs
Cycling has some dumb rules (e.g. sock length), but banning aerobars in mass start races is not among them.
I'm like this, but when I have too much caffeine I notice that it's harder to turn the monologue off. It becomes a little shouty in fact. Brains are weird.
You've got it more or less. The way I say it is that bad ideas can't hide in writing. You can fool yourself and others with a powerpoint or a spoken argument. But clear writing demands clear thinking. Poorly constructed arguments are (usually) obvious as such when put into writing.
In practice I find prophet far superior. Prophet can deal deftly with the kind of problems that show up in real-world data like missing values and radical changes in trend from shocks to the system you're modeling.
For textbook problems like forecasting electricity demand, sARIMA works just fine, but you'll struggle forecasting anything more complex. This is not to say that it's impossible, but it will require far more expertise.
The specific anecdote may have been fabricated, but the principle is sound. An example is the marshmallow problem[1], where a group is given some materials and is asked to build, under time pressure, the tallest tower they can with a marshmallow on top. Adults generally fare poorly because they don't experiment enough, building a tall tower and placing a marshmallow on the top as time is running out, only to have the tower collapse under the newly introduced weight. Children often do much better because they start with small, simple structures and iterate quickly.
Did you even read the headline? “Supplements won’t prevent dementia...”
The first half of the article is all about various dietary supplements and how there is no good evidence for them. But there is decent evidence for exercise, controlling blood pressure, and congnitive training.
He suggests that a great memo takes a week or more. In my experience that's roughly right, though you'll often have been mulling over the problem for weeks before you actually start writing.
Because of its audience and goals it's necessarily less technical and more essay-like than a typical s-team memo. For obvious reasons, I can't link to any of those.
An example that's close and is in the public domain is Jacobsen's TCP slow start paper: https://ee.lbl.gov/papers/congavoid.pdf. He's advocating a specific change in the TCP protocol and marshalls evidence beautifully to make his argument.
I agree completely. It's also important that the audience can actually tell the difference between good writing and poor writing and give useful feedback. You can't just ask people to write and hope for the best.