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

281–290 of 732 posts

Re: Lessons from 14 years at Google

#281

Post by neilk »

Read it carefully.

He's not saying that these are all common values or practices at Google.

He's saying he learned those lessons while working at Google.

Despite the metaphor of a "lesson", a "lessons learned" post is almost never about something the author was explicitly told. It was something that you had to learn from experience, or at best from informal advice. Where you had to swim against the flow of your circumstances.

I neither think Osmani means to say that Google is _against_ these lessons. Every organization as big as Google has a lot of accumulated wisdom that will help you. These are just the things which remain hard, and some of which are even harder in a large organization.

Re: Lessons from 14 years at Google

#282

Post by shultays »

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…

Probably the users he is talking about are not the end users like you and me. It is one team using the tools/software of the other team and so "users" for that other team are the members of the first team.

Re: Lessons from 14 years at Google

#283

Post by seattle_spring »

Here's the lessons all ex-Google colleagues I've worked with have brought with them to their new jobs:

1. Use Bazel for everything. Doesn't matter that the documentation sucks and it's unbelievable bloat for smaller companies: use it anyway. Use it for everything.

2. Write things from scratch. Need a protobuf parser in C? Just write one up instead of using any of the battle-tested open source options.

3. Always talk down to frontend engineers and treat them as lesser/ not real engineers. Real engineers are backend engineers. Frontend is so easy that they can do a perfectly fine job if needed. Make sure to use Bazel for all frontend builds.

4. Did I mention Bazel? It's the solution to all problems for all companies.

Re: Lessons from 14 years at Google

#284

Post by charlieyu1 »

Worked at an AI training company for a few months. Enshittification is real. Idiots who never deserved to be here coming up with new policies every week, sometimes twice a week. Absolutely spineless when receiving nonsense from the client which is one of FAANG but will screw colleagues with no remorse.

Re: Lessons from 14 years at Google

#285

Post by majormajor »

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.

There's not enough hours in the day for everyone to do everything.

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

Yes, this is great for agency over implementation, because leaders do not have context to decide and dictate the What/How of implementing every single change or solution to a problem. And the implementers need to know the context to ensure they make decisions consistent with that context.

But "leaders providing the context" is very different from "everyone researching the context on their own." So where are leaders getting this context from? A not-very-differentiated pile of 1000 generalist engineers-who-also-talk-to-customers-frequently-and-manage-their-own-work-streams? Or do they build a team with specialists to avoid needing the majority of people to constantly context-switch in a quest to be all of context-gatherers, work-prioritizers, market-researchers, and implementation-builders?

Re: Lessons from 14 years at Google

#286

Post by hansmayer »

bitexploder wrote: post #265
hansmayer wrote: post #245

Earlier quoted context omitted.

> Google UX is decent and the author was not trying to comment on UX as a thing at Google. Interesting, so he was not, contrary to the blog title, writing on the basis of his 14 years of experience at Google?

Read their point 1 carefully. They are saying, when you are building something or trying to solve a problem (for internal or external users) if you follow the user obsessively you will have a far better outcome that aligns with having impact and long term success. This does imply thinking about UX, but transitively, IMO.

I am not sure I follow - is he, or is he not, writing about his experiences from 14 years at Google? The title suggests he does, yet you suggest that he does not?

Re: Lessons from 14 years at Google

#287

Post by Sephr »

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 code is the code you never had to write.", and "14. If you win every debate, you’re probably accumulating silent resistance."

1. https://addyosmani.com/an-apology-to-eli/

Re: Lessons from 14 years at Google

#288

Post by geodel »

k8sToGo wrote: post #250
bigcloud1299 wrote: post #133

15 years in leadership worked at 3 jobs lead major transformations at retail where nearly 100B of revenue goes through what i built. Ran $55-$100M in a yearly budget… over 300 FTEs and 3x contractors under my or my budget,…largest retailer in google at that time…my work influenced GCP roadmap, Datastax roadmap, … much more all behind the scenes…. besides your capabilities and ability that had to be there to get you i…

>b/c they didn’t know how to play politics Or they refuse to play that bs game

True. I used to count myself in that category. Do the work and stay away from games. I was also thinking of myself as clever, self-respecting by doing hard work and leaving daily politicking for others. And now sometime back I got like 2-3 dressing downs from managers, reason being I am not taking leadership feedback seriously enough and mending my ways. This despite I am only one with left with knowledge of legacy system. Clearly I am pretty dispensable while thinking otherwise all along.

No outside prospects considering market situation, miserable current workplace ultimately due to my choices. So in end just no winning for me by not playing game.

Re: Lessons from 14 years at Google

#289

Post by potatoproduct »

stefan_ wrote: post #197
p1esk wrote: post #168

Earlier quoted context omitted.

Almost nobody else in engineering did this. What you described is the job of a product manager. Are there no PMs at Google?

PM is a fake job where the majority have long learned that they can simply (1) appease leadership and (2) push down on engineering to advance their career. You will notice this does not actually involve understanding or learning about products. It's why the GP got that confused reaction about reading user reports. Talk to someone outside big company who has no power? Why?

Sounds like you just got stuck with a shit PM to be honest.

Re: Lessons from 14 years at Google

#290

Post by dijit »

kiwijamo wrote: post #279
dijit wrote: post #240

Earlier quoted context omitted.

> I’d take [teams] over Google Meets What? Why? Honestly your entire comment is almost exact polar opposite to how I feel. GCP Makes total sense if you know anything about systems administration, Google docs is limited for things like custom fonts (IE; not gonna happen) but it's simple at least and I can give people a link to click and it's gonna look the same for them. But, honestly, the Teams one is baffling. I can…

I've used Meet a few times for video calls and I was amazed at how poorly it worked given the amount of resources Google has at their disposal. I've never had a good video call on Meets. I've had a few Meet calls where over time the resolution and bitrate would be reduced to such a low point I couldn't even see the other person at all (just a large blocky mess). Whereas Teams (for all its flaws) normally has no major…

I've had the complete opposite experience. Meet has been rock solid for me whilst Teams has been an absolute nightmare.

The thing is though both Meet and Teams use centralised server architectures (SFUs: Selective Forwarding Units for Google, "Transport Routers" for Teams), so your quality issues likely come down to network routing rather than the platforms themselves. The progressive quality degradation you're describing on Meet sounds like adaptive bitrate doing its job when your connection to Google's servers is struggling.

The reason Teams might work better for you is probably just dumb luck with how your ISP routes to Microsoft's network versus Google's. For me in Sweden, it's the opposite ... Teams routes my media through relays in France, which adds enough latency that people constantly interrupt each other accidentally. It's maddening. Meanwhile, Meet's routing has been flawless.

But even if Teams works for your particular network setup, let's not pretend it's a good piece of software. Teams is an absolute resource hog that treats my CPU like a space heater and my RAM like an all-you-can-eat buffet. The interface is cluttered rubbish, it takes ages to start up, and the only reason anyone tolerates it is because Microsoft bundled it with Office 365.

Your mileage definitely varies... sounds like you've got routing that favours Microsoft's infrastructure. Lucky you, I suppose, but that doesn't make Teams any less dogwater for those of us stuck with their poorly-placed European relays.

Post reply on HN