#12 is so simple yet so true. Great list thanks for sharing.
Lessons from 14 years at Google
81–90 of 732 posts
Re: Lessons from 14 years at Google
#82> If you win every debate, you’re probably accumulating silent resistance.
This is very true in personal lives as well.
Re: Lessons from 14 years at Google
#83> At scale, even your bugs have users. First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turnin…
For close to a decade my business revolved around a common bug in both Microsoft and Netscape, the dominant browsers of the day. With every release we were thinking 'this time they'll fix it' and that would have caused us some serious headaches. But they never did!
I was curious what the commenter's business was, and found this post about HTTP protocol latency: https://jacquesmattheij.com/the-several-million-dollar-bug/
Re: Lessons from 14 years at Google
#84They are pretty insightful. Particularly this one: > 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. I have my own version of this where I tell people that no amount of good advice can help you make a blank page look better. You need to have some published work before you can benefit from any advice.
I wish Google would be biased a little more towards quality and performance. Their user-facing products tend to be full of jank, although Gmail is quite good to be fair. In general I think the "ship fast and break things" mentality assumes a false dilemma, as if the alternative to shipping broken software is to not ship at all. If thats the mentality no wonder software sucks today. I'd rather teams shipped working, c…
When you're not shipping, you're not learning from users. As a result, it's easy to build working, correct, performant code which doesn't fit what anyone actually needs.
Re: Lessons from 14 years at Google
#85Wish I'd read this before I started at Google.
Re: Lessons from 14 years at Google
#86> 1. The best engineers are obsessed with solving user problems.
The author lost me right here.
Not because he’s wrong about this in general - he is not. But it seems to not be any kind of differentiator at Google. Maybe the opposite is true- make it as screwed up as physically possible, then make it a little worse, then release it - that seems a lot closer to the lesson Google engineers learn. As long as you are “first” and shipped it.
Then get promoted, move on and meanwhile your crap code eventually gets the axe a decade later.
Re: Lessons from 14 years at Google
#87The skill isn’t being right. It’s entering discussions to align on the problem. Clarity isn’t a style preference - it’s operational risk reduction. The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate.” This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone. The problem isn’t that engineers can’t write code or use AI to do so. It’s t…
It's just so disrespectful. I put my time in reading this. You (author) couldn't put some time into reading this once over before publishing? The points are generally good too, which is why the AI slop tone bothers me even more.
We should not bother to read things that the author didn't bother to write.
Re: Lessons from 14 years at Google
#88> First do it, then do it right, then do it better. Get the ugly prototype in front of users.
Great, give users something that messy, horrible and not fully functional. Customer who spend big for production environments are exploited to "be the outsourced QA"
Re: Lessons from 14 years at Google
#89> Addy Osmani is a Software Engineer at Google working on Chrome and AI
Thanks for all the spyware in Chrome ig? And for many inane design decisions that favor usability over privacy and security?
Re: Lessons from 14 years at Google
#90The writing is excellent. Very correlated with the quality of the message I'd imagine.
It is very heavily filled with LLM-isms. The writing is bland AI output.
how do you know?
in the first item, LLMs don't use incomplete sentence fragments?
> It’s seductive to fall in love with a technology and go looking for places to apply it. I’ve done it. Everyone has. But the engineers who create the most value work backwards: they become obsessed with understanding user problems deeply, and let solutions emerge from that understanding.
I suppose it can be prompted to take on one's writing style. AI-assisted, ok sure, but hmm so any existence of an em-dash automatically exposes text as AI-slop? (ironically I don't think there are any dashes in the article)
EDIT: ok the thread below, does expose tells. https://news.ycombinator.com/item?id=46490075 - yep there's definitely some AI tells. I still think it's well written/structured though.
> It's not X... it's Y.
That one I can't unsee.