Great post, Years following Addy. I wonder know how he manages his time, in addition to being a leader at Google, and writing such a valuable blog.
Lessons from 14 years at Google
21–30 of 732 posts
Re: Lessons from 14 years at Google
#2214 years? Wild. I remember when Addy came into the scene hot with a new jQuery tutorial (what seemed like) every few days. To be clear, that's not a knock despite how it may read in 2026.
Re: Lessons from 14 years at Google
#23The biggest one that resonates with me is that cleverness is overhead. My #1 issue with mid level engineers is that they like complexity and find complexity fun and interesting. An experienced engineer knows that complexity is irritating and frustrating and that a simple solution is harder and superior. A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. If you…
> A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius.
Well put. Chasing "How simple can we make this?" is a large part of what makes this job enjoyable to me. But it's perhaps not a good career advice.
Re: Lessons from 14 years at Google
#24I’d agree on most of these but the biggest value in such a list is for the writer to actually put it on paper. You have to reflect on multiple aspects in your career and synthesise those. Reading them is close to useless, like scanning a page full of news, it all just evaporates once you start your daily work routine.
The best suggestion would probably be to try and write such a list yourself IMO.
Re: Lessons from 14 years at Google
#25Thank you for sharing this. Well articulated.
Re: Lessons from 14 years at Google
#26They 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.
It is good only if the whole team believes it.
If the team mates have a different mindset, they see it as half baked or hacky. And if there is ever some bad feedback, they just use it as a "I told you so" and throw you under the bus.
Re: Lessons from 14 years at Google
#27> At scale, even your bugs have users
Also known as ossification. It is a term most often heard in the context of network protocols, but it applies more generally to every system where users depend on unspecified behaviors and even bugs.
Reading about HTTP/3 and QUIC is interesting in that aspect. I first didn't understand the insistance on encryption. Turns out it is not just security and privacy, but by encrypting everything that is not strictly necessary for proper transport, you make it impossible for any "middlebox" to make assumptions they shouldn't make.
I think similar approaches can be used by APIs. Never expose more than what is specified, treat the ability to access internal state as a bug, not because it is secret, but because if users start relying on it, internal changes that shouldn't break anything will.
Re: Lessons from 14 years at Google
#28> Abstractions don’t remove complexity. They move it to the day you’re on call.
Then they are bad abstractions. I get where he is coming from, but the entire field is built on abstractions that allow you to translate say a matmul to shuffling some electrons without you doing the shuffling.
Re: Lessons from 14 years at Google
#29The biggest one that resonates with me is that cleverness is overhead. My #1 issue with mid level engineers is that they like complexity and find complexity fun and interesting. An experienced engineer knows that complexity is irritating and frustrating and that a simple solution is harder and superior. A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. If you…
> A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. Well put. Chasing "How simple can we make this?" is a large part of what makes this job enjoyable to me. But it's perhaps not a good career advice.
Yeah, "resume driven development" is a second major force pushing complexity that I didn't mention. People want to be able to get experience with as many buzzwords and technologies and stacks as they can for obvious personal self interest reasons.
The incentive is real. A great programmer who does a great job simplifying and building elegant maintainable systems might not get hired because they can't say they have X years experience with a laundry list of things. After all, part of their excellence was in making those things unnecessary.
It's a great example of a perverse incentive that's incredibly hard to eliminate. The net effect across the industry is to cost everyone money and time and frustration, not to mention the opportunity cost of what might have been had the cognitive cycles spent wrangling complexity been spent on polish, UI/UX, or innovation.
There's also a business and VC level version of this. Every bit of complexity represents a potential niche for a product, service, or startup. You might call this "product portfolio driven development" which is just the big brother of "resume driven development."
Re: Lessons from 14 years at Google
#30I clicked through to the bio and am super confused. Third person, extremely long, lots of pictures with CEOs and smelling of LLM writing.
Here's a sample:
> His story isn’t just about writing code, but about inspiring a community to strive for a better web. And perhaps the most exciting chapter is still being written, as he helps shape how AI and the web will intersect in the coming decade. Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come.