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

51–60 of 732 posts

Re: Lessons from 14 years at Google

#51

Post by spiralcoaster »

nemo1618 wrote: post #42

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

Thank you for doing this. It allowed me to skip reading the article altogether immediately knowing it is AI generated slop. Usually I'm a little ways into it before my LLM detector starts going off, but these "This isn't X. It's Y." phrases are such a dead giveaway.

Re: Lessons from 14 years at Google

#53

Post by papacj657 »

nemo1618 wrote: post #42

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

So glad I’m not the only one that noticed that.

There’s some really solid insights here, but the editing with AI to try to make up for an imperfect essay just makes the points they’re trying to convey less effective.

The lines between what is the author’s ideas and what is AI trying to finish a half or even mostly baked idea just removes so much of the credibility.

And it’s completely counter to the “clarity vs cleverness” idea and the just get something out there instead of trying to get it perfect.

Re: Lessons from 14 years at Google

#55

Post by ThrowawayR2 »

NitpickLawyer wrote: post #34
ThrowawayR2 wrote: post #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.

> You can edit a bad page, but you can’t edit a blank one.

Ideally, yes, but the final result of LLM assisted textual output by many users shows that they often have neglected the editing part just as much as they have neglected the writing part.

Re: Lessons from 14 years at Google

#56

Post by dchftcs »

ramijames wrote: post #43
hbs18 wrote: post #33

Earlier quoted context omitted.

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.

Their bosses are likely happier for the lower downtime required to run the software anyway.

Re: Lessons from 14 years at Google

#57

Post by samiv »

llmslave2 wrote: post #48
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, c…

I wish people who ship crappy software didn't ship it and would let someone else ship something better instead.

It really sucks when the first mover / incumbent is some crappy half assed solution.

But unfortunately we live in a world where quality is largely irrelevant and other USPs are more important. For example these little weekend projects that become successful despite their distinct lack of quality

Linux kernel - free Unix.

JavaScript - scripting in browser

Python - sane "perl"

Today on GitHub alone you can probably find 100 more featured and higher quality projects than any of these were when they launched but nobody cares.

Re: Lessons from 14 years at Google

#59

Post by aprilthird2021 »

nemo1618 wrote: post #42

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

Re: Lessons from 14 years at Google

#60

Post by thelastgallon »

alex1138 wrote: post #38
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…

https://xkcd.com/1172/

Hyrum's Law: https://www.hyrumslaw.com/
Post reply on HN