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

Software Engineering at Google (2020)

abseil.io

Post reply on HN
Print view View original

141–150 of 352 posts

Re: Software Engineering at Google (2020)

#141

Post by filoleg »

drewg123 wrote: post #46
mushufasa wrote: post #4

Cool. Could someone, maybe an ex-googler, comment on which parts of these work well and which don't? A lot of other companies get into trouble trying to cargo-cult what Google does when they are operating in very different environments wherein those practices aren't optimal. E.g. different levels of scale. Additionally, critics of Google may point out that their engineering culture may not be great on its own terms -…

"Readability" works terribly when your company is acquired and your team enters all at the same time. Google has (or had ~10 years ago), a thing called "readability" for each language, where in order to be allowed to commit code to the central "google3" repo, you needed to have written some large amount of code in that language, and needed to have a readability reviewer sign off on your code. The process is designed…

"Readability" requirement is still a thing, but it isn't for every single piece of code in G3, and I haven't worked close enough to it to think about the exact mechanism of how it applies.

My previous team - pretty much any python submission was hitting me with a python "readability" requirement, and it was a bit painful, because only a single person in my entire group of teams (roughly 15 people total) had the "python readability expert" status. My current team - already submitted quite a few significant C++/TS/Java pieces of code to G3, and not a single "readability" requirement triggered.

Re: Software Engineering at Google (2020)

#142

Post by foldr »

biztos wrote: post #129
foldr wrote: post #106

Earlier quoted context omitted.

The Apple Silicon transition also involves software (Rosetta), which works absurdly well given the complexity of what it's doing.

Exactly my point: the same company wrote Rosetta and the new Settings. Clearly not the same level of talent and commitment in those two teams.

I think it would be difficult to imagine a company the size of Apple not having variance in talent and commitment between different teams.

Re: Software Engineering at Google (2020)

#143

Post by teaearlgraycold »

jollyllama wrote: post #59
fnordpiglet wrote: post #29

Earlier quoted context omitted.

I’ve not worked there but I’ve worked with many exgooglers. They tend to think Google * is the best in the world and they created it before anyone else and everyone else with similar capabilities copied them, and that Googlers are smarter. However every company of their size and technical complexity has built almost exactly the same tooling and processes, but don’t carry the same attitude around. At a certain point I…

Great comment. Google and others blazed a trail, but by 2010 you could find similar, often specialized tooling and practices emerging at most Fortune 500 tech companies.

Today you can almost universally get a better off-the-shelf solution with a SaaS product than what Googlers are able to access internally.

Re: Software Engineering at Google (2020)

#144

Post by sumtechguy »

MarceColl wrote: post #38
jeffbee wrote: post #17

Earlier quoted context omitted.

In my ex-Google experience, here are the stages of denial about something that Google does which is good but the industry doesn't yet embrace. Stage 1: "We're not Google, we don't need [[whatever]]"; Stage 2: Foreseeable disaster for which [[whatever]] was intended to address happens; Stage 3: Giant circus of P0/SEV0 action items while everyone assiduously ignores the [[whatever]]; Stage 4: Quiet accretion, over seve…

The tools, design and manpower needed to build a skyscraper are different from those needed to build a 1-story wood house. It's not that the ones that build the wood house are failing to study and adopt the ways of their extremely successful competitors. Now, some of the things you say like unit-testing and user data encryption are ones that I've never seen associated with the "We're not google" mindset, so maybe peo…

"were not google" is usually good for things where people are using cargo cult. I saw at one company that went open floor plan because google did it. No one was happy about that. Retention became very low and everyone bailed out. Emulating google does not fix process and management issues. As what may be at google for a good reason may be an utter failure at another company. There are things all shops can adopt that google does that would help them. But many of the ones I have seen adopted were little more than showy garbage instead of the things that would actually help.

Also sometimes you just need a simple tool to get something done. As engineers we like to build things so sometimes we make it way more complex than it really needs to be. For someone like google that may just be fine to do. For others a minimum viable product may be in order. Do not worry about optimizing for the 3 million user per day case when you have 10 total users a month. Add logging and keep an eye on it. Then worry if you need to scale. As building good scale takes time and thought. Many times you do not need that at all.

As your company/group grows you will take on more and more of the things 'google does' because you will need to, or you will go nuts chasing everything. You could probably even make stages out of the different times to do/evaluate things. To do it early could actually harm what you are doing. You need to evaluate what you are doing and why. Just copying someone else does not always lead to a good outcome and you could be wasting effort when you could be making product.

Re: Software Engineering at Google (2020)

#146

Post by UncleMeat »

water-your-self wrote: post #55

How have layoffs impact group psychological safety?

Not good.

I've seen people rapidly shift to career protection, wagon-circling, and empire building. I've seen more competition for leading junior people since there are fewer new hires coming in. But mostly I've seen the company become more cynical towards executives.

Depending on your feelings on AI, you might see new excitement and opportunity opening up or further meddling and messy product management in the future. I'm not sure where I land here yet.

I think Google is still a very good place to work. Pay is high. WLB is great (at least where I sit). Tooling is very good. I haven't had any asshole managers or directors. But I definitely find it hard to get people excited about taking a big risk or maintain a project that is important but somehow misaligned with what your VP cares about.

Re: Software Engineering at Google (2020)

#147

Post by paul7986 »

paul7986 wrote: post #88
mabbo wrote: post #15

Earlier quoted context omitted.

> I'm strongly under the impression that 20 years ago they discovered unobtanium in the form of a very under-served search and ads market, they plopped down camp on top of it and turned it into a giant money firehose In 2010 when I interned there, one of my mentors said something to me that stuck with me: "Google found a hose that money pours out of, and it's name is 'online advertising'. All we do is optimize that h…

Yes and just like all tech companies.. Google steals from smaller companies to the dreamers they inspired to invent and create. Sonos: https://www.theverge.com/2023/5/26/23739273/google-sonos-sma... A MIT student: https://news.ycombinator.com/item?id=18566929 I met them (they were horribly unprofessional) in 2013 around time Sonos did to discuss my audio syncing tech. Best to steal tech then bother investing into R&D…

I've been told I shouldn't talk about this anymore on hacker news by Dang.

I haven't mentioned my experience in years cause it's old news but Sonos court victory is new relevant news to my experience meeting Google R&D that same year.

Though I can say for sure and claim is that they were extremely and laughably unprofessional to me and I met with other tech companies then who were very professional and polite.

Re: Software Engineering at Google (2020)

#148

Post by DoingIsLearning »

flohofwoe wrote: post #31
ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

I can't think of a single C++ library coming out of Google I had to deal with and where I didn't have massive problems integrating them into my own C++ projects because of all the Google specialties baked into those projects (their own weird build tools which don't seem to have changed much since the early 2000's and the use of other Google dependencies like abseil). Maybe it works well inside Google, but definitely…

Off the top of my head I used FlatBuffers in quite a few projects many moons ago and that was pretty seamless.

Arguably it was a bit thin on documentation but it just worked.

Re: Software Engineering at Google (2020)

#149

Post by UncleMeat »

aatd86 wrote: post #126
UncleMeat wrote: post #104

Earlier quoted context omitted.

Google has 180,000 employees. There's an org that is responsible for internal tooling, but they are an org with priorities and challenges like any other. So sometimes Search needs a thing and Core won't do it so some people in Search build a tool. Maybe later somebody in Ads needs a similar tool but has never heard of the thing that Search built. So there is an organic force to this sort of complexity. There are syst…

Should be easy nowadays to have a chat-based AI which, given some provided requirements, suggest similar tools that have been built by other SBUs. Even if only to look at the code.

Maybe.

But this only solves a visibility issue (and codesearch/moma is already pretty good at this). It doesn't help you when the tool supports a different language or the team that owns it isn't willing to commit to the SLO that you need or whatever.

Re: Software Engineering at Google (2020)

#150

Post by fer »

georgemcbay wrote: post #86
rb2k_ wrote: post #51

Earlier quoted context omitted.

Last I talked to people about Apple's internal tooling, it was still pretty fragmented between different organizations. I was told about e.g. multiple internal CI/build systems because one org didn't want to rely on the other, so they both built their own little software stacks. That's a bit different than what I've heard from meta/google/amazon who seem to be more open to running centralized internal services

Amazon famously mandated such internal services at one point: https://gist.github.com/chitchcock/1281611 This was rather a long time ago now so I wouldn't be surprised if things have changed since then, though having never worked at Amazon I wouldn't know one way or the other.

The main thing that changed is that now the service approach also generally enforces a particular framework (Smithy/Coral)
Post reply on HN