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

71–80 of 732 posts

Re: Lessons from 14 years at Google

#71

Post by DenisM »

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.

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 metrics is shortsighted. The repeatable outcome of this process is mediocracy. Which, surprisingly enough, works out on average.

Re: Lessons from 14 years at Google

#72

Post by AndrewKemendo »

This has to be the 50th or 100th version of this article that repeats the same thing

Every single point in this article was already explicitly described between roughly 1968 and 1987: Brooks formalized coordination cost and the fallacy of adding manpower in The Mythical Man-Month

Conway showed that system architecture inevitably mirrors organizational communication structure in 1968

Parnas defined information hiding and modularity as organizational constraints, not coding style, in 1972

Dijkstra *repeatedly warned* that complexity grows faster than human comprehension and cannot be managed socially after the fact

None of this is new, reframed, or extended here; it is a faithful re-enumeration of half-century-old constraints.

These lists keep reappearing because we refuse to solve is the structural one: none of these constraints are enforceable inside modern incentive systems.

So almost like clockwork somebody comes out of nowhere saying hey I’ve I’ve observed these things that are consistently documented in history of organizational management and specifically computing and software management look at this list.

It’s so Exhausting

Re: Lessons from 14 years at Google

#73

Post by TacticalCoder »

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…

Craziest I got was users complaining their laptops were getting too hot / too noisey because I correctly parallelized a task and it became too efficient. They liked the speed but hated the fans going on at full speed and the CPU (and hence the whole laptop) getting really warn (talking circa 2010). So I had to artificially slow down processing a bit as to not make the fans go brrrrr and CPU go too hot.

Re: Lessons from 14 years at Google

#74

Post by samiv »

ryandrake wrote: post #66
samiv wrote: post #57

Earlier quoted context omitted.

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

While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.

That's the other side of the value added coin. Users sometimes find value even in the half assed software.

Someone was once talking about the "solving the right problem wrong" vs "solving the wrong problem right".

Re: Lessons from 14 years at Google

#75

Post by johannes1234321 »

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…

That is https://xkcd.com/1172/

Re: Lessons from 14 years at Google

#76

Post by cmrdporcupine »

It's funny that I agree with most or all of these principles but don't feel like my 10 years at Google accord with most of this. I wouldn't say I learned these things at Google, but learned them before (and a bit after) and was continually frustrated about how many of them were not paid attention to at Google at all?

Incentive structure inside Google is impaired.

I do think Google engineering culture does bias against excessive abstraction and for clean readable code and that's good. But acting in the user's interest, timely shipping, etc... not so much.

Re: Lessons from 14 years at Google

#78

Post by doublerabbit »

imiric wrote: post #20
kayo_20211030 wrote: post #2

Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true. The two that stand out are > Novelty is a loan you repay in outages, hiring, and cognitive overhead. and > Abstractions don’t remove complexity. They move it to the day you’re on call. as a warning against about being too, too clever.

Eh, sure. But at the same time lessons aren't learned by reading what someone else has to say. They're learned by experience, and everyone's is different. An engineer with "14 years at Google" hardly makes them an expert at giving career advice, but they sure like to write like it does. This type of article reads more like a promotion piece from self-involved people, than heartfelt advice from someone knowledgeable.…

Mood. As someone who normally leaves after two years because the opportunity never raises to what was offered in the job spec these really don't for for me these bullet points as well wouldn't work for office culture in the EU.

15 Years worth of jobs and none gel. I'm a contractor now which feels more me. I have a contract length, don't have to deal with red tape political bullshit.

Turn up, do work and leave when contract had ended.

Re: Lessons from 14 years at Google

#79

Post by edonhametsu »

ronbenton wrote: post #44
unlimit wrote: post #18

I am going to file this line > If you win every debate, you’re probably accumulating silent resistance.

That one makes me uncomfortable, which is a bad sign...

I'd say it's a good sign – at least now you're aware it might be happening. A worse sign would be thinking you're definitely not that sort of personality; you'd be accruing silent resentment from both being loud _and_ clueless.

Re: Lessons from 14 years at Google

#80

Post by DenisM »

AndrewKemendo wrote: post #72

This has to be the 50th or 100th version of this article that repeats the same thing Every single point in this article was already explicitly described between roughly 1968 and 1987: Brooks formalized coordination cost and the fallacy of adding manpower in The Mythical Man-Month Conway showed that system architecture inevitably mirrors organizational communication structure in 1968 Parnas defined information hiding…

The fact that people don’t learn from the older books is somewhat annoying, but rewriting them makes sense precisely because people will likely trust it more.

Software engineers are prone to novelty bias. Thats in contrast to some other demographic groups who very much prefer ancient texts.

Post reply on HN