Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Working on complex systems: What I learned working at Google

thecoder.cafe

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Working on complex systems: What I learned working at Google

#51

Post by wiseowise »

blitzar wrote: post #30
dijit wrote: post #17

Earlier quoted context omitted.

The idea is if someone helps you in a really big way that you’re able to reward that. So you can ask the company to give the person either credits for an internal store, or a direct addition to their salary for one month. Obviously, there are limits to how many pay bonuses you can give out and if it’s direct money or store credits. Directly asking for a peer bonus’ is not very “googly” (and yes, this is a term they u…

> The idea is if someone helps you in a really big way that you’re able to reward that It never ceases to amaze me how (early) big tech embraced and even promoted things that would have been considered "career limiting" in traditional big corporations.

> would have been considered "career limiting" in traditional big corporations.

How so?

Re: Working on complex systems: What I learned working at Google

#53

Post by CommenterPerson »

RenThraysk wrote: post #44

There is a certain amount of irony when the cookie policy agreement is buggy on a story about complicated & complex systems. Clicking on "Only Necessary" causes the cookie policy agreement to reappear.

It didn't appear on DuckDuckGo either, Thanks.

Re: Working on complex systems: What I learned working at Google

#54

Post by newsclues »

dmoy wrote: post #5

> My immediate reaction in my head was: "This is impossible". But then, a teammate said: "But we're Google, we should be able to manage it!". Google, where the impossible stuff is reduced to merely hard, and the easy stuff is raised to hard.

“the difficult we do immediately. The impossible takes a little longer” WW2 US army engineer corp

Re: Working on complex systems: What I learned working at Google

#55

Post by jcranmer »

ggm wrote: post #18

I think there are two myths applicable here. Probably more. One myth is that complex systems are inherently bad. Armed forces are incredibly complex. That's why it can take 10 or more rear echelon staff to support one fighting soldier. Supply chain logistics and materiel is complex. Middle ages wars stopped when gunpowder supplies ran out. Another myth is that simple systems are always better and remain simple. They…

> Middle ages wars stopped when gunpowder supplies ran out.

The arquebus is the first mass gunpowder weapon, and doesn't see large scale use until around the 1480s at the very, very tail end of the Middle Ages (the exact end date people use varies based on topic and region, but 1500 is a good, round date for the end).

In Medieval armies, your limiting factor is generally that food is being provided by ransacking the local area for food and that a decent portion of your army is made up of farmers who need to be back home in the harvest season. A highly competent army might be able to procure food without acting as a plague on all the local farmlands, but most Medieval states lacked sufficient state capacity to manage that (in Europe, essentially only the Byzantines could do that).

Re: Working on complex systems: What I learned working at Google

#56

Post by pclmulqdq »

repeekad wrote: post #36
kubb wrote: post #24

Earlier quoted context omitted.

I’d wager 90% time spent at Google is fighting incidental organizational complexity, which is virtually unlimited.

The phrase thrown around was “collaboration headwind”, the idea was if project success depends on 1 person with a 95% chance of success, project success also had a 95% chance. But if 10 people each need to succeed at a 95% chance, suddenly the project success likelihood becomes 60%… In reality, lazy domain owners layered on processes, meetings, documents, and multiple approvals until it took 6 months to change the te…

There's a culture of "I won't approve this unless it does something for me" at Google. So now changing the text on a button comes with 2 minor refactors, 10 obvious-but-ignored bugfixes, and 5 experiments that it is actually better.

Re: Working on complex systems: What I learned working at Google

#57

Post by Demiurge »

kubb wrote: post #24
braza wrote: post #10

One of my pet peeves with the usage of complex(ity) out of the traditional time/space in computer science is that most of the time the OPs of several articles over the internet do not make the distinction between boundaried/arbitrary complexity, where most of the time the person has most of the control of what is being implemented, and domain/accidental/environmental complexity, which is wide open and carries a lot o…

I’d wager 90% time spent at Google is fighting incidental organizational complexity, which is virtually unlimited.

And when you’re at a smaller company 90% of your time is fighting societal complexity, limit of which also approaches infinity, but at a steeper angle.

No greater Scott’s man can tell you that the reality is surprisingly complex, and sometimes you have resources to organize and fight them, and sometimes you use those resources wiser than the other group of people, and can share the lessons. Sometimes, you just have no idea if your lesson is even useful. Let’s judge the story on its merits and learn what we can from it.

Re: Working on complex systems: What I learned working at Google

#58

Post by TexanFeller »

braza wrote: post #10

One of my pet peeves with the usage of complex(ity) out of the traditional time/space in computer science is that most of the time the OPs of several articles over the internet do not make the distinction between boundaried/arbitrary complexity, where most of the time the person has most of the control of what is being implemented, and domain/accidental/environmental complexity, which is wide open and carries a lot o…

Rich Hickey is famous for talking about easy vs. simple/complex and essential vs. incidental complexity.

“Simple Made Easy”: https://youtu.be/SxdOUGdseq4?si=H-1tyfL881NawCPA

Re: Working on complex systems: What I learned working at Google

#59

Post by moregrist »

pclmulqdq wrote: post #56
repeekad wrote: post #36

Earlier quoted context omitted.

The phrase thrown around was “collaboration headwind”, the idea was if project success depends on 1 person with a 95% chance of success, project success also had a 95% chance. But if 10 people each need to succeed at a 95% chance, suddenly the project success likelihood becomes 60%… In reality, lazy domain owners layered on processes, meetings, documents, and multiple approvals until it took 6 months to change the te…

There's a culture of "I won't approve this unless it does something for me " at Google. So now changing the text on a button comes with 2 minor refactors, 10 obvious-but-ignored bugfixes, and 5 experiments that it is actually better.

While this sounds pretty frustrating, there is at least a small upside: at least you get to the obvious-but-ignored bugfixes.

Most smaller places don’t have the bandwidth and many larger ones don’t have the desire.

I’m not sure if that makes up for bugs potentially introduced in the refactors, though.

Re: Working on complex systems: What I learned working at Google

#60

Post by brap »

newsclues wrote: post #54
dmoy wrote: post #5

> My immediate reaction in my head was: "This is impossible". But then, a teammate said: "But we're Google, we should be able to manage it!". Google, where the impossible stuff is reduced to merely hard, and the easy stuff is raised to hard.

“the difficult we do immediately. The impossible takes a little longer” WW2 US army engineer corp

“and the easy... well, that’s not a good promo artifact, so never”
Post reply on HN