Lessons from 14 years at Google
addyosmani.com
Lessons from 14 years at Google
1–10 of 732 posts
Re: Lessons from 14 years at Google
#2Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true.
The two that stand out are
> Novelty is a loan you repay in outages, hiring, and cognitive overhead.
and
> Abstractions don’t remove complexity. They move it to the day you’re on call.
as a warning against about being too, too clever.
Re: Lessons from 14 years at Google
#3Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true. The two that stand out are > Novelty is a loan you repay in outages, hiring, and cognitive overhead. and > Abstractions don’t remove complexity. They move it to the day you’re on call. as a warning against about being too, too clever.
Agreed.
Not just engineers, but basically everyone involved in creating products including designers and PMs.
Every single bullet point here is gold.
Re: Lessons from 14 years at Google
#4The writing is excellent.
Very correlated with the quality of the message I'd imagine.
Re: Lessons from 14 years at Google
#5They 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.
Re: Lessons from 14 years at Google
#6I like this one
> At scale, even your bugs have users.
Something I discovered the hard way over many years of maintaining rclone. Fixing a bug has consequences and there are sometimes users depending on that bug!
xkcd: https://xkcd.com/1172/
Re: Lessons from 14 years at Google
#7> "Writing forces clarity. The fastest way to learn something better is to try teaching it."
Something that seems lost on those using LLMs to augment their textual output.
Re: Lessons from 14 years at Google
#8Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true. The two that stand out are > Novelty is a loan you repay in outages, hiring, and cognitive overhead. and > Abstractions don’t remove complexity. They move it to the day you’re on call. as a warning against about being too, too clever.
There's rarely a bullet point advantage that some new language or tech stack can offer me that would outweigh ten years of observation of how a familiar setup behaves in production, such that the space of unknown unknowns is reduced to almost nothing.
Re: Lessons from 14 years at Google
#9I like this one > At scale, even your bugs have users. Something I discovered the hard way over many years of maintaining rclone. Fixing a bug has consequences and there are sometimes users depending on that bug! xkcd: https://xkcd.com/1172/
Thank you for your work on maintaining rclone! It is a wonderful and very underappreciated piece of software.
Re: Lessons from 14 years at Google
#10I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/
Likewise, "Abstractions don’t remove complexity. They move it to the day you’re on call." made me think of this 23 year old classic from Joel Spolsky, the Law of Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...