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

311–320 of 732 posts

Re: Lessons from 14 years at Google

#311

Post by dijit »

geodel wrote: post #291
dijit wrote: post #274

Earlier quoted context omitted.

Sometimes. Sometimes it's just bullshit . Learn the lingo, the language, the proper way of posturing and the correct way to shirk responsibility and that's what matters in certain orgs. I sound really bitter, but I'm not, I'm actually quite good at the game and I've proven that, I just don't really like the game because it doesn't translate into being able to take pride in what I've done. It's all about serving egos.…

> I'm actually quite good at the game and I've proven that, Good. I failed and very likely about to face consequences.

Nobody that actually matters will hold it against you.

Fuck the posers. Do real shit.

Re: Lessons from 14 years at Google

#312

Post by 0______0 »

Sephr wrote: post #287

This feels somewhat hypocritical coming from Addy. Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts. I cannot accept his apology until he actually syndicates it with his followers. Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best cod…

FWIW, the actual apology is well written.

Re: Lessons from 14 years at Google

#313

Post by nabbed »

inopinatus wrote: post #234
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…

To be fair, it reads precisely “1. The best engineers are obsessed with solving user problems”. This doesn’t say those engineers are working at Google, just that it’s something the author learned whilst they worked at Google. “Some [of these lessons] would have saved me months of frustration”, to quote the preamble.

I was going post exactly this! He was talking about those engineers that really exemplified, from his point of view, good engineers.

And dealing with engineering managers that didn't see much use in such activity might be part of "figur[ing] out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity".

Re: Lessons from 14 years at Google

#314

Post by avidiax »

Rapzid wrote: post #272
martinpw wrote: post #244

Earlier quoted context omitted.

Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where…

This reads like it was written by a PM. You lacked higher level context and prioritization skills early in your career so the take away is it's best to divest agency to others? There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.

I think he has a point. These power structures exist for some good reasons as well.

The opposite thing (engineers engaging directly with customers) can eventually lead to customer capture of your engineering org. You shouldn't have a small group of existing, noisy customers directly driving your engineering to the detriment of other existing or future customers.

Microsoft had customer capture institutionally: the existing big corporate customers were all that mattered. It lead to rebooting Windows CE into Windows Mobile way too late to make a difference, for example. But it also meant that backwards compatibility and the desire to ship Windows XP forever were sacred cows.

There are also nasty games that can be played by soliciting negative feedback for political advantage.

Dysfunction can exist with any structure. It's probably best that there's some small amount of direct user feedback as well as the big formalized feedback systems, at least so that one is a check for the performance of the other. If the user engagement team says everything is good, but there are massive Reddit threads about how horrible the product is to work with and the engineers know it could be better, it's time for engineering to start addressing the issues alongside feedback to the user engagement teams.

Re: Lessons from 14 years at Google

#315

Post by decimalenough »

0______0 wrote: post #312
Sephr wrote: post #287

This feels somewhat hypocritical coming from Addy. Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts. I cannot accept his apology until he actually syndicates it with his followers. Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best cod…

FWIW, the actual apology is well written.

Although little note at the very end explains why:

> This note is in response to emails from Eli Grey to Chrome leadership from October, 2023

In other words, he wrote this because he was forced to.

Re: Lessons from 14 years at Google

#316

Post by embedding-shape »

alemanek wrote: post #255
embedding-shape wrote: post #233

Earlier quoted context omitted.

That's not a fair reading, he's as much of a developer as anyone else. But he wasn't (AFAIK) working on user-facing products specifically.

I think it is more the point that the users for his job were external developers. The role is inherently user facing and user focused. I don’t think anyone was trying to say he wasn’t a developer just that his job wasn’t to directly develop products

Yeah, I guess I just wanted to add that because of the way that quote was cut at the end, made me believe that the person quoting me thought Osmani "isn't a developer".

Re: Lessons from 14 years at Google

#317

Post by fwip »

haunter wrote: post #193
websiteapi wrote: post #157

Earlier quoted context omitted.

why would a great UX be tied to the source being open or not?

Because if you don’t like the UX you just edit the source code yourself and make it better /s /s but I wish it wasn’t because a lot of FOSS evangelists have this mindset (here on HN too)

More seriously - open source software is resistant to enshittification. It's obviously not a panacea, but the possibility of forks (or just the user deciding not to update), combined with the difference in profit motive, tends to result in software that respects the user.

(Taken holistically, the UX of software does not just mean the UI, or the moments when you are using the software. It also includes the stability of the software over time, including whether or not you are able to reject new versions whether you do not like.)

Re: Lessons from 14 years at Google

#318

Post by zelphirkalt »

mike_hearn wrote: post #139
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, 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?

Re: Lessons from 14 years at Google

#319

Post by keeda »

Aren't #2 and #14 mostly the same point? And they seem to indicate a rather unhealthy cultural dynamic. Amazon's "Disagree and commit" is a much healthier dynamic than "Pretend to agree and then silently sabotage."

I think there's a valid middle ground in finding a path that works well for everybody, but this does not seem to be the right way.

I wonder if this is a common thing at Google because I recall another interview (can't find now, I think in the context of WebRTC??) from many years ago where an engineer proudly described how he conspired against a major technical decision because it didn't align with his personal preferences. I was a bit shocked to see someone admit something like that so publicly.

Re: Lessons from 14 years at Google

#320

Post by mixmastamyk »

martinpw wrote: post #244
avidiax wrote: post #200

Earlier quoted context omitted.

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…

Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where…

An org can always go too far in the opposite direction, but this is not an excuse to never talk to the customer. The latter is much more likely, so the warning to not get “into bed” with the customer falls flat.

This is a common pattern here. Alice says 0 degrees is too cold, I prefer 20C, Bob chimes in “100C is too hot, it’ll kill us.” Ok, well no one said or implied to crank it to one hundred.

Post reply on HN