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

341–350 of 732 posts

Re: Lessons from 14 years at Google

#341

Post by Yizahi »

Aurornis wrote: post #116
hansmayer wrote: post #93

Not looking to dismiss the authors long tenure at a major tech company like Google, but the first point kind of stuck like a sore thumb. If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. Every single one of their services is a pain to use, with unnecessary steps, clicks - basically everythi…

The short answer is that the UI isn’t optimized for users like you. I haven’t worked for Google specifically, but at this scale everything gets tested and optimized. I would guess they know power users like you are frustrated, but they know you’ll figure it out anyway. So the UX is optimized for a simpler target audience and possibly even for simpler help documents, not to ensure power users can get things done as qu…

Google UI seemingly is optimized for happy path cases. Search for the obvious word and click a relevant link on the screen which appears. Write a single response to a single email and abandon than conversation afterwards, always use new conversations for every new email. Click a recommended video thumbnail on the frontpage and then continue with autoplay. Put only short defined text type in the cells of a spreadsheet, like date/number/text etc. And so on with all of their products.

But as soon as user tries to search for something no on the first page, or reply to a 10-20+ message thread with attachments in history, or tries to use playlists or search in YT, or input a slightly more complex data in the sheet cells - then all hell breaks loose.

Just the latest Google thing I've experienced - a default system Watch Later playlist is now hidden on Android. It's gone, no traces, no way to search for it. The only remnant of it is a 2-second popup after adding a new video to Watch Later, you can press "view" and then see it. Meanwhile it is still present as a separate item on PC. I'm writing this eaxmple because that was deliberate, that was no error or regression. Someone created a Jira for that and someone resolved it.

Re: Lessons from 14 years at Google

#342

Post by xmddmx »

andyjohnson0 wrote: post #241

> 15. When a measure becomes a target, it stops measuring. This is Goodhart's law - "When a measure becomes a target, it ceases to be a good measure" [1]. [1] https://en.wikipedia.org/wiki/Goodhart%27s_law

Right, this annoyed me too - it was stated w/o attribution as if novel.

What is the name of the law when someone writes a think piece of "stuff I've learned" and fails to cite any of it to existing knowledge?

Makes me wonder if (A) they do know it's not their idea, but they are just cool with plagiarism or (B) they don't know it's not their idea.

Re: Lessons from 14 years at Google

#343

Post by elktown »

api wrote: post #29
elktown wrote: post #23

Earlier quoted context omitted.

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

Again, very well put. It often becomes a chain-reaction as well.

Re: Lessons from 14 years at Google

#344

Post by polynomial »

zelphirkalt wrote: post #318
mike_hearn wrote: post #139

Earlier quoted context omitted.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users,…

If an engineer talking to users is considered problematic, then it is safe to assume, that Google is about as fast away from any actually agile culture as possible. Does Google ever describe itself as such?

"data-driven agile"™

Re: Lessons from 14 years at Google

#345

Post by kinlan »

embedding-shape wrote: post #94
hansmayer wrote: post #93

Not looking to dismiss the authors long tenure at a major tech company like Google, but the first point kind of stuck like a sore thumb. If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. Every single one of their services is a pain to use, with unnecessary steps, clicks - basically everythi…

> If the Google culture was at all obsessed about helping users It's worth noting that Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer working on a product shipped to users. It might be useful to keep that in mind as you read through what his lessons are, because they're surely shaped by the positions he held in the company.

I was Addy's manager when he was on Developer Relations.

He moved to an engineering manager role on Chrome DevTools many years ago and has recently just moved on to a different team. I don't think it's fair at all to say he's not a developer working on a product shipped to users when he led one of our most used developer tools, as well as worked on many of our developer libraries prior to moving to the Engineering manager role.

Re: Lessons from 14 years at Google

#346

Post by johnmwilkinson »

kenferry wrote: post #278
johnmwilkinson wrote: post #64

> 4. Clarity is seniority. Cleverness is overhead. Clarity is likely the most important aspect of making maintainable, extendable code. Of course, it’s easy to say that, it’s harder to explain what it looks like in practice. I wrote a book that attempts to teach how to write clear code: https://elementsofcode.io > 11. Abstractions don’t remove complexity. They move it to the day you’re on call. This is true for bad a…

I agree with you re: abstraction - one of the author's only points where I didn't totally agree. But also worth noting that whenever you make an abstraction you run the risk that it's NOT going to turn out increase clarity and precision, either due to human limitation or due to changes in the problem. The author's caution is warranted because in practice this happens really a lot. I would rather work with code that h…

Broad strokes: absolutely. The practical reality gets tricky, though. All programming abstractions are imperfect in some regard, so the question becomes what level of imperfection can you tolerate, and is the benefit worth the cost?

I think a lot of becoming a good programmer is about developing the instincts around when it’s worth it and in what direction. To add to the complexity, there is a meta dimension of how much time you should spend trying to figure it out vs just implement something and correct it later.

As an aside, I’m really curious to see how much coding agents shift this balance.

Re: Lessons from 14 years at Google

#347

Post by dawnerd »

avidiax wrote: post #200
mike_hearn wrote: post #139

Earlier quoted context omitted.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users,…

Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. I think there are multiple reasons for this, but they are mostly overlapping with preserving internal power structures. PM's don't want anecdotal user evidence that their vision of the product is incomplete. Engineering managers don't want user feedback to undermine perception of quality and derail "i…

Where I work we regularly bring in engineers to talk to clients directly. Clears up a lot of confusion when there’s something technical a PM wouldn’t understand. We still like to have a filter so a client isn’t trying to get the engineer to do free work. Having engineering isolated is pretty bad IMO.

Re: Lessons from 14 years at Google

#348

Post by RagnarD »

Thought occurred to me to throw this at ChatGPT 5.2:

Given the article at https://addyosmani.com/blog/21-lessons/, find a short list of points which summarizes and touches on all of his lessons

Answer:

Here’s a short “umbrella list” that still covers all 21 lessons (each bullet is doing a lot of work on purpose):

  - Start with the user, not the toy. Get unreasonably concrete about real user pain (tickets, observation, “why” drills), and let solutions fall out of that—otherwise you’ll build complexity to justify a preconceived answer.

  - Engineering is a team sport: alignment beats being right. The job is getting to “right” together: create shared understanding, reduce misalignment (the real cause of “slow” teams), avoid “winning” debates into silent resistance, use metrics carefully (they get gamed), and design process to reduce uncertainty rather than produce paperwork.

  - Ship early, then iterate—clarity over cleverness. Bias to action: drafts and MVPs teach faster than armchair perfection. Write code and docs that are obvious at 2am during an incident, not “impressive.” And treat novelty as debt you repay in ops/hiring/cognitive overhead—spend your “innovation tokens” where you’re uniquely paid to innovate.

  - Do less: deletion is a superpower (and often the fastest optimization). Prefer “code you never wrote” (or work you removed) over clever additions. Many performance wins come from removing unnecessary computation, not adding fancy machinery.

  - Respect scale and failure: compatibility, migrations, and leaky abstractions are the real product. At scale, even bugs become dependencies; deprecations are migrations with empathy/tooling/time. Abstractions don’t erase complexity—they postpone it until on-call—so keep a working mental model of what’s underneath.

  - Make your impact legible and invest in compounding. Code doesn’t advocate for you—people do—so communicate outcomes, not just activity. Use writing/teaching to force clarity and deepen your own understanding; treat “glue work” as deliberate, bounded, and visible. Build psychological safety by saying “I don’t know.” Maintain relationships because your network outlasts any job. And manage your career like compound interest: protect time, practice deliberately, turn scar tissue into reusable playbooks.

Re: Lessons from 14 years at Google

#349

Post by conception »

DenisM wrote: post #71
ramijames wrote: post #43

Earlier quoted context omitted.

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

What about the second order effects? Ignoring the customers becomes a habit, which doesn’t lead to success. But then, caving to each customer demand will make solution overfit. Somewhere in there one has to exercise judgement. But how does one make judgment a repeatable process? Feedback is rarely immediate in such tradeoffs, so promotions go to people who are capable of showing some metric going up, even if the metr…

Steve Jobs has a bunch of videos on creating products- https://youtu.be/Q3SQYGSFrJY

Some person or small team needs to have a vision of what they are crafting and have the skill to execute on it even if users initially complain, because they always do. And the product that is crafted is either one customers want or don’t. But without a vision you’re just a/b testing your way to someone else replacing you in the market with something visionary.

Re: Lessons from 14 years at Google

#350

Post by H8crilA »

euifii wrote: post #206
spicyusername wrote: post #189

Earlier quoted context omitted.

So teach your kids to kiss ass and play poltiics. Or to stay far away and do something useful with their lives.

This is what I really don’t get about these types of folks. Do they really want to remember their life’s work as “kissing ass and playing politics”? I get the “work to live” and all that, but you’re basically tossing away half your life…for what, money? How much money do you need!?

You need to have the right personality. Either actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort. We don't get to choose our personalities, though some limited modifications are possible - see treatments for personality disorders, for example.
Post reply on HN