Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

361–370 of 732 posts

Re: Lessons from 14 years at Google

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

That code from your post is fairly standard image load handling, but the notable part is this line:

self.apng_supported = ctx.getImageData(0, 0, 1, 1).data[3] === 0;

Unless I'm misunderstanding, it's basically a "neat trick", like using ~~ for rounding or a fast inverse square root.

Is the intent that everyone who makes use of that trick is supposed to link back to your blog?

Re: Lessons from 14 years at Google

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

Jesus, bro. Let bygones be bygones. How long is this ago? It's just code. And what the code did, is not even fundamental. It's not like you cured cancer.

I tend to see my code in these terms as well, it's not dear to me. But I'd never presume to tell someone how to feel over having their work stolen (and I'm using that term because that's how I'm sure Mr Grey felt).

Re: Lessons from 14 years at Google

#363
post #71

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…

First define who the real customer is.

Second define what the real problem is.

Third define a solution that solves 80 percent of their problem.

None of this is intuitive or obvious. It may not even be technically feasible or profitable.

Re: Lessons from 14 years at Google

#364

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…

I agree -- the career advancement bent of this article is the most off putting aspect.

Re: Lessons from 14 years at Google

#365
post #33

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

Organizing workers

What’s the alternative? Ask the boss for favors? That’s what organizing is for

Re: Lessons from 14 years at Google

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

Thanks for sharing, I found the blogpost hypocritical even without knowing about this

Re: Lessons from 14 years at Google

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

Disagree. There's levels to this. Not all bad pages are better than blank ones. Ones that harms user data or worst is worst than blank pages.

Re: Lessons from 14 years at Google

#368
> 13. The work that makes other work possible is priceless - and invisible.

> Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. ... The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact. Timebox it. Rotate it. Turn it into artifacts ... make it legible as impact, not as personality trait.

I see my own experience in this, but I don't think he's identified the problem correctly. Timeboxing, rotating, etc, is easy. Convincing management that it is as important as non-glue work and therefore worth allocating your time for it is the hard part. And if you can't do that, you end up stuck in the situation described.

The other option is to just let things fail of course, but then you have to convince both management AND the rest of your team to do this, otherwise someone else will just pick it up between the cracks too.

Re: Lessons from 14 years at Google

#369
post #281

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

I say that in most of my past experiences I learned how to NOT do something, so when facing a similar scenario, I’d do them differently.

Re: Lessons from 14 years at Google

#370

Earlier quoted context omitted.

> The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk. I assume…

One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.

"Laid off" may be more appropriate than "fired", but in essence, removing the need for costly labor is often the main "value" of any technology. Society as a whole comes out ahead from it, I mean for all the ice transporters and merchants put out of a job by electric refrigeration, and all the sailors put out of a job by modern cargo ships I think we're better off for it. But at the individual level it does make one uneasy about the prospects of individuals affected by it. My personal conclusion is that people have a personal duty to anticipate and adapt to change, society might give them some help along the way but it doesn't owe them that their way of life will be maintained forever.
Post reply on HN