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

101–110 of 147 posts

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

#101

Post by vkou »

pclmulqdq wrote: post #99
vkou wrote: post #94

Earlier quoted context omitted.

They aren't asking for you to write tests because 'it benefits them', they are asking you to write tests because as a professional engineer, you should write tests , and not just yolo it. Look, sometimes you may have good reasons for why a test is impractical. You are allowed to push back, or look for a different reviewer. There's a hundred thousand people in the firm, you should be able to find one or two that will…

If you are turning a button to a slightly different shade of blue and it's not a button you own, the owner of the button should not be asking you to write tests for the button.

If the case is as simple as you describe, surely there's more than one owner of the code that can approve this, if one guy is being unreasonable.

If there is actually only one owner that can approve changes to the package, there's something really weird and unusual about that project setup, or it's someone's internal hobby project that they wrote five years ago and semi-maintain, in which case, I have to wonder why you submitting one-liner changes to it is all that important.

We're all adults, we all work together, we can all work this out. If someone absolutely insists on being an asshole, escalate. It's why you have a manager, and why they have a manager.

My experience is that very few people are unreasonable assholes.

There's always plenty of organizational, vision, strategy, and execution problem in any billion-dollar company, but 'people are unreasonable in code reviews' is not one I'd put in the top 10. It might be something that ruins your day once or twice, but that doesn't make it systemic.

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

#102

Post by bitpush »

hiddencost wrote: post #71

This is all exacerbated by a ton of the ML stack being in Python, for some god Forsaken reason.

How is the choice of language the cause of anything complex/complicated?

Both python and rust (for instance) are both turing complete, and equally capable

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

#104

Post by cowboylowrez »

zmb_ wrote: post #29
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…

Following the definition from the article, armed forces seems like a complicated system, not a complex one. There is a structured, repeatable solution for armed forces. It does not exhibit the hallmark characteristics of complex systems listed in the article like emergent behaviors.

not a fan of the article for this reason alone. good points made, but no reason to redefine perfectly good words when we already have words that work fine.

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

#105

Post by dietr1ch »

specialist wrote: post #97
dietr1ch wrote: post #70

Earlier quoted context omitted.

Well, when the owner asks for a whole test suite that didn't exist to get a fix in, what most likely happens is that you just wasted your time in a draft CL that will get lost.

Do you mean the relevant code area(s) didn't have (sufficient) tests? You're being asked to backfill those missing tests in addition to your fix?

Yes. I've experienced pushback from obvious fixes with requests to formally test their code for the first time.

All because it may break someone. Even when I presented a real defect based on docs/comments and fixed it. You'd think that if they truly cared about breakages they'd already have some tests for it from where I can easily start.

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

#106

Post by kridsdale3 »

miki123211 wrote: post #86
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…

Another side of this coin is that the expected payoff from a project depends on how many unrelated projects your organization is engaging in , which is deeply counterintuitive to most people. Every project carries with it three possibilities: that of success, where the company makes money, that of failure, where the company does not, and that of a "critical failure", where the project goes so wrong that it results in…

This is an excellent explanation of the culture of BigTech.

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

#107

Post by dietr1ch »

vkou wrote: post #101
pclmulqdq wrote: post #99

Earlier quoted context omitted.

If you are turning a button to a slightly different shade of blue and it's not a button you own, the owner of the button should not be asking you to write tests for the button.

If the case is as simple as you describe, surely there's more than one owner of the code that can approve this, if one guy is being unreasonable. If there is actually only one owner that can approve changes to the package, there's something really weird and unusual about that project setup, or it's someone's internal hobby project that they wrote five years ago and semi-maintain, in which case, I have to wonder why y…

> If someone absolutely insists on being an asshole, escalate.

That's doubling down on time spent on contributing back. It's usually cheaper to workaround the issue once you notice it'll be way harder than it should be (not hard at all).

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

#108

Post by YZF »

miki123211 wrote: post #86
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…

Another side of this coin is that the expected payoff from a project depends on how many unrelated projects your organization is engaging in , which is deeply counterintuitive to most people. Every project carries with it three possibilities: that of success, where the company makes money, that of failure, where the company does not, and that of a "critical failure", where the project goes so wrong that it results in…

I like the ideas here but I think the actual chance of getting sued for $3b is so small as to be negligible in the context of costs. It's also questionable how much the additional process/overhead moves the needle on that chance. Larger companies also have various "shields" against these sorts of lawsuits. E.g. they lobby politicians, they employ lawyers, they have legal and IP protection.

Just like anything else in life you want to look at the present value and then get insurance for huge risks.

That said agree that a startup can take more risk but I don't think that is the major factor explaining why larger companies tend to be process heavy and slower.

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

#109

Post by tunesmith »

I think the definitions of complex/complicated get muddled with the question of whether something is truly a closed system. Often times something is defined as "complex" when all they mean is that their model doesn't incorporate the externalities. But I don't know if I've come across a description of a truly closed system that has "emergent behavior". I don't know if LLMs qualify.

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

#110

Post by ncruces »

pclmulqdq wrote: post #99
vkou wrote: post #94

Earlier quoted context omitted.

They aren't asking for you to write tests because 'it benefits them', they are asking you to write tests because as a professional engineer, you should write tests , and not just yolo it. Look, sometimes you may have good reasons for why a test is impractical. You are allowed to push back, or look for a different reviewer. There's a hundred thousand people in the firm, you should be able to find one or two that will…

If you are turning a button to a slightly different shade of blue and it's not a button you own, the owner of the button should not be asking you to write tests for the button.

It's as good an opportunity as any to improve things.

They're acting as selfish demanding you do something for them, as you are for refusing.

Post reply on HN