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

141–147 of 147 posts

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

#141

Post by nottorp »

fidotron wrote: post #50
globalnode wrote: post #11

Earlier quoted context omitted.

Speaking of games, why hasn't google made a game. They could create a gaming division and well... make one. Amazon did. I wonder why they haven't.

Google has a really hard time grokking the games industry, to the point they can hire people from it and just almost totally ignore them. Their ideas on how Android game development should be done were utterly hilarious, and it's only because of a couple of their dev relations people going to ludicrous lengths that it is actually viable at all. Fundamentally, and ironically, Google likes to offload complexity on to e…

> Google has a really hard time grokking the games industry

And Apple :)

The two mobile duopolists don't understand gaming.

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

#142

Post by fidotron »

nottorp wrote: post #141
fidotron wrote: post #50

Earlier quoted context omitted.

Google has a really hard time grokking the games industry, to the point they can hire people from it and just almost totally ignore them. Their ideas on how Android game development should be done were utterly hilarious, and it's only because of a couple of their dev relations people going to ludicrous lengths that it is actually viable at all. Fundamentally, and ironically, Google likes to offload complexity on to e…

> Google has a really hard time grokking the games industry And Apple :) The two mobile duopolists don't understand gaming.

Apple absolutely do get it, they might disagree with you about what that is. Google just can't. I worked in the games industry in exactly this area, and the difference between the two is just enormous, but in ways we cannot go into in this forum.

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

#143

Post by bigyabai »

barbazoo wrote: post #76
AtlasBarfed wrote: post #47

Earlier quoted context omitted.

[flagged]

I don’t get the connection to capitalism here. Care to elaborate?

This video should help: https://youtu.be/QIrM9vKKxTs

People don't show up to work for a gold star, they want money. Any consolation you offer employees in the form of a candy bar or massage credits can be better expressed as a fiscal bonus that isn't half as patronizing.

If you see this as a "why can't we have nice things" situation, then you must not grasp how these incentives replace actual motivation. It's the equivalent of tipping culture transposed to overpaid SWE seats. It should not exist. Fair compensation should be demanded as a baseline.

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

#144

Post by __turbobrew__ »

dietr1ch wrote: post #105
specialist wrote: post #97

Earlier quoted context omitted.

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.

I don’t think that is necessarily unreasonable. The team may have the same constraints on themselves in that they wouldn’t touch the code either until tests are written.

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

#145

Post by junto »

mwbajor wrote: post #95
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…

Im a HW engineer and don't really understand "complexity" as far as this article describes it. I didn't read it in depth but it doesn't really give any good examples with specifics. Can someone give a detailed example of what the author is really talking about?

Cynefin framework:

https://en.m.wikipedia.org/wiki/Cynefin_framework

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

#146

Post by junto »

wooque wrote: post #121
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.

Same here, it's because you have third party cookies blocked.

My assumption with bugs like this is that they are “geographically based edge cases” that have been poorly tested due to engineers not being in the right location to test it, but affects a large number of users without throwing a error that can be logged.

GDPR banner only to be used in EU, with conditional of only accepting non-essential cookies, and the engineer or QA is based in the U.S.

As a side note, as someone that lives in the EU my pattern of usage here is:

- choose only non-essential, but if not a presented option then

- reject all cookies, but if no reject all available then

- switch the reader mode (or hide distracting items), or if not possible then

- close tab

I’m getting much more aggressive when dealing with cookie banners dark patterns. I will not a third third party advertising cookies as much as possible and support websites that allow me an easy way to opt out of them.

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

#147

Post by specialist »

dietr1ch wrote: post #105
specialist wrote: post #97

Earlier quoted context omitted.

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.

Thanks for clarifying. Sympathies.

I've been on every side of this conundrum. Not being allowed to improve/fix stuff is super frustrating, very demoralizing.

I can quickly recall 3 separate projects where we weren't allowed to fix stuff on new products that hadn't shipped yet (not even beta). (Oops, just thought of 2 and 1/2 more projects.)

It's hard to not treat that as beligerent, spiteful, gatekeeping, control issues. For me, half the time it absolutely was.

I've also managed legacy code bases that we dare not accidentally breathe on. Somewhere between archaeology and necromancy.

For me, when I'm in charge, project (engineering) management comes down to mitigating risk, usually by driving down the cost of change. I'm sure I'm preaching to the choir.

Alas, it's been a long time since I've been on a project that had anything resembling proper PMI, QA, Test, etc. So there's really no process or strategy to mitigate risks.

IIRC, the contemporary deliberate rejection of process is called something like the "Argyle" Methodology. Or maybe it's "Agile". Or "Argh-gargle". I don't quite remember. I can dig up those books and links, if anyone is pervously curious.

Well. Good luck.

Post reply on HN