Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

Post reply on HN
Print view View original

41–50 of 732 posts

Re: Lessons from 14 years at Google

#41

Post by sowbug »

firefoxd wrote: post #5

They 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 liked that one, too, but for an additional reason.

Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install the version of the PageReader™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ toolchain to their version). And so on.

All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google.

Re: Lessons from 14 years at Google

#42

Post by nemo1618 » 

   The 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 that we’re so good at writing it that we forget to ask whether we should.
   This isn’t passive acceptance but it is strategic focus.
   This isn’t just about being generous with knowledge. It’s a selfish learning hack.
   Insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.
   Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission.
I'm so tired bros

Re: Lessons from 14 years at Google

#43

Post by ramijames »

hbs18 wrote: post #33
trescenzi wrote: post #13

> 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…

So what is the correct solution to that specific problem then, adjust loading time per customer?

Ignoring the users is the correct solution. Defining company culture through software loading is ridiculous.

Re: Lessons from 14 years at Google

#45

Post by DougN7 »

jimmyl02 wrote: post #32

Usually there are nuggets of wisdom in lists shared like this but I feel like every lesson shared here has immense value. > "remain skeptical of your own certainty" > "Model curiosity, and you get a team that actually learns." These are two lessons that typically require battle scars to learn. For such big ideas to be summed into two sentences is pretty remarkable and puts to words lessons I wish I knew how to share.…

I was going to skip the article until I read your comment, and wow! You’re totally right - my hard won understanding is there, including things I sort of knew but couldn’t put into words before. Going to share this with my adult kids.

Re: Lessons from 14 years at Google

#47

Post by kyrra »

trescenzi wrote: post #13

> 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…

This was well talked about in Hyrums Law, which came from a Googler as well.

https://www.hyrumslaw.com/

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Re: Lessons from 14 years at Google

#48

Post by llmslave2 »

firefoxd wrote: post #5

They 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, correct, and performant software even if it meant delaying additional features or shipping a constrained version of their vision. The minimalism of the software would probably end up being a net benefit instead of stuffing it full of half baked features anyways.

Re: Lessons from 14 years at Google

#49

Post by bakugo »

croemer wrote: post #30

I 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…

The linked post itself also reeks of LLM writing (negative parallelisms in every other paragraph). But sadly, it seems like this is just the new standard for highly upvoted front page posts.

Re: Lessons from 14 years at Google

#50

Post by rvz »

lklkllko wrote: post #35

[flagged]

Some people just want to be remembered for the "engineering" / "social engineering" they did, while others what to be remembered for being employee of the month for 10+ years at the company.

Both are a complete waste of time.

It's more impressive if you bootstrapped your own company to millions instead of chasing false praise, engaging in employee politics and being employee #470293 at big company.

But I predict you will get the same thing with those at the big AI companies.

Post reply on HN