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

221–230 of 352 posts

Re: Software Engineering at Google (2020)

#221

Post by kaycebasques »

natch wrote: post #156
namdnay wrote: post #152

Earlier quoted context omitted.

What you’re describing sounds more like a book on product management?

Yeah but ideally some PM spirit should also be built into a good developer culture so they can fill any PM gaps when needed, imho.

To add to your point, I think what they said about technical writing might also apply to product management:

> It introduced a perverse incentive: become an important project and your software engineers won’t need to write documents. Discouraging engineers from writing documents turns out to be the opposite of what you want to do. Because they are a limited resource, technical writers should generally focus on tasks that software engineers don’t need to do as part of their normal duties. Usually, this involves writing documents that cross API boundaries. Project Foo might clearly know what documentation Project Foo needs, but it probably has a less clear idea what Project Bar needs. A technical writer is better able to stand in as a person unfamiliar with the domain. In fact, it’s one of their critical roles: to challenge the assumptions your team makes about the utility of your project. It’s one of the reasons why many, if not most, software engineering technical writers tend to focus on this specific type of API documentation.

PMs are a scarce resource. A lot of eng teams within Google don't have a dedicated PM and need to carve out product-market fit for themselves. When you have a dedicated PM it's easier to offload all PM ideas and responsibilities to that person.

(I'm a technical writer at Google. The boilerplate "all opinions my own" is important in this convo because I think a lot of TWs and PMs will strongly disagree with these ideas.)

Re: Software Engineering at Google (2020)

#222

Post by opportune »

bluefishinit wrote: post #39

Unless you have a monopoly on the ad market that's going to mask all of your bad managerial, strategy and culture problems, then I'd advise steering well clear of copying Google. They make money in-spite of their day to day practices, not because of them.

From someone who’s seen how the sausage gets made, I both agree and disagree.

A lot of Google’s practices really are good software engineering practices - provided you have the money to invest in replicating it to a high degree of quality, which could be substantial and better spent elsewhere. When you have one of the most lucrative business models of all time you definitely have the money to invest in trying to make it as stable to maintain and easy to add value onto as possible, so it was definitely worth it for Google in many cases, but each other company will have to determine the costs vs benefits themselves.

Replicating Blaze and Forge seems really expensive and hard to get right (though it can be tremendously valuable for development on a large codebase). Postmortems, containerization, servers-as-cattle, gradual non-global releases… those aren’t as expensive to set up and have great cost/benefit ratios. It’d be stupid to not do these just because Google does them (and in some cases invented or popularized the practice).

Re: Software Engineering at Google (2020)

#223

Post by emodendroket »

fizigura wrote: post #211
emodendroket wrote: post #192

Earlier quoted context omitted.

Are you sure? https://appleinsider.com/articles/23/05/23/carplay-android-a... > A report from Straits Research found that 98% of newly produced vehicles were compatible with either CarPlay or Android Auto. Meanwhile, 80% of prospective car buyers strongly preferred having these smartphone-based infotainment systems in their new vehicles. The same research also shows Asia-Pacific to be the biggest market for these pro…

"connected" vs "compatible with" Tbf. 25% connected is huge. If you just jump into your car to quickly do groceries or pick up your kids, you may not be interested in connecting your phone to your car, even if you really like that feature. So there could be a natural ceiling for the "connected" number and 25% feels getting close to that ceiling actually.

If 80% of buyers express a strong preference for having Carplay/Android Auto I don't think it's reasonable to say that they haven't seen "widespread acceptance."

Re: Software Engineering at Google (2020)

#224

Post by bradley13 »

crazygringo wrote: post #208
lhorie wrote: post #185

I'm stumbling into this thread right after experiencing what appears to be a pretty catastrophic failure of Google's main product. As I write this, the search results for "Google stock" (among other queries) returns zero results ("Your search - google stock - did not match any documents"). I'm not really sure what to make out of these discussions about how X or Y Google engineering is, while the production service is…

Searching for "Google stock" shows me correct results. A stock chart followed by various search results. There's no news of a widespread Google failure. Maybe you have a browser extension interfering? Or there's some kind of very localized hiccup. In any case, your experience right now isn't even close to representative. For its scale and complexity, Google search is probably one of the most reliable services ever bu…

Possible. I noticed recently that Google search no longer works with NoScript. It used to work. Not sure when this changed, since I don't often enable NoScript.

Re: Software Engineering at Google (2020)

#225

Post by klooney »

jeffbee wrote: post #113
dinvlad wrote: post #94

Earlier quoted context omitted.

Curious how pre-commit code review worked, could you please elaborate a bit?

Every change is reviewed by someone other than the author before it lands in the repo. At google they take this a bit further. Every change has to have been either written or reviewed by a designated owner of the code (designated by subdirectory) and one of the participants must be a qualified user of the languages used in the change ("readability"). And they have technical measures in place to ensure that programs r…

The real problem with code review is that if people don't do it/just hit sign off, it's worthless. Your whole company has to believe.

Re: Software Engineering at Google (2020)

#226

Post by greiskul »

opportune wrote: post #190
MH15 wrote: post #153

Earlier quoted context omitted.

"Readability" is very much still a thing. It's a mess and would be one of the worst things to take from Google. If you can't enforce the code style you like through autoformatters and linting, it's not worth enforcing.

I kind of disagree in the sense that readability indirectly forces someone who has been at Google for a while/ is more experienced to have to sign off on new people’s code. Without it, you could have some very junior members with OWNERS reviewing other very junior members’ code. And there is more to style than just linting, IMO. For example in C++ there are some complex macro-based test predicates that are hard to le…

> I kind of disagree in the sense that readability indirectly forces someone who has been at Google for a while/ is more experienced to have to sign off on new people’s code. Without it, you could have some very junior members with OWNERS reviewing other very junior members’ code.

Exactly. It is very likely for a lot of junior engineers will be working with other junior engineers, and they will in fact have the most specific knowledge of the part of the project that they are implementing. And human nature makes it so people are afraid of being judged by their "superiors". Readability makes so that it breaks that barrier, guarantees that a more senior engineer will be involved, and will teach the ropes into writing readable, mantainable code to nooglers.

Re: Software Engineering at Google (2020)

#227

Post by lhorie »

crazygringo wrote: post #208
lhorie wrote: post #185

I'm stumbling into this thread right after experiencing what appears to be a pretty catastrophic failure of Google's main product. As I write this, the search results for "Google stock" (among other queries) returns zero results ("Your search - google stock - did not match any documents"). I'm not really sure what to make out of these discussions about how X or Y Google engineering is, while the production service is…

Searching for "Google stock" shows me correct results. A stock chart followed by various search results. There's no news of a widespread Google failure. Maybe you have a browser extension interfering? Or there's some kind of very localized hiccup. In any case, your experience right now isn't even close to representative. For its scale and complexity, Google search is probably one of the most reliable services ever bu…

Small update: It's definitely not extensions, it's giving the same result on two different devices (mobile and laptop). I've narrowed it down to there being something going on w/ being logged into specific accounts. On my work account, I get no results (and this is a query that used to return results under the exact same setup just last week). Trying on an old personal gmail account, I'm getting the UI localized to what seems to be mandarim for who knows what reason (I don't speak mandarim, and don't even use this account on a regular basis).

As for why this happens, I have no idea. I've had Google Maps completely black out on me and then eventually magically fix itself many months later.

As for reliability, I would probably have agreed if it was a "simple" system (which the original Google was). Today, I'm not so sure. I at least understand that Google today is made up of a large number of subsystems, and subsystem failures like the ones I'm experiencing (and bad search results as others have also reported) do in fact erode my trust in the product. "Your 99.9% is not my 99.9%" feels like an apt quote here.

Re: Software Engineering at Google (2020)

#228

Post by crazygringo »

bradley13 wrote: post #224
crazygringo wrote: post #208

Earlier quoted context omitted.

Searching for "Google stock" shows me correct results. A stock chart followed by various search results. There's no news of a widespread Google failure. Maybe you have a browser extension interfering? Or there's some kind of very localized hiccup. In any case, your experience right now isn't even close to representative. For its scale and complexity, Google search is probably one of the most reliable services ever bu…

Possible. I noticed recently that Google search no longer works with NoScript. It used to work. Not sure when this changed, since I don't often enable NoScript.

[Deleting -- I thought I was replying to the same commenter. Never mind, bradley13! Thanks.]

Re: Software Engineering at Google (2020)

#229

Post by H8crilA »

raldi wrote: post #83
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…

Off-topic for this thread, but one of the most poignant quips I remember about Google culture was that the performance-review process was really good at rewarding hard, challenging work that didn't produce much value and not very good at recognizing work that produced lots of value but was not astoundingly difficult. I think you were the one who first noted this.

The performance review process has a small impact on salary.

The promo process is not based on value or difficulty, but on the size of the organization that one is running. This is also true for higher level ICs, except they do not manage people, but rather manage/lead projects (which then have a certain amount of people involved).

Here's a rough breakdown:

  - L4 -> 1 person
  - L5 -> 1-3 people
  - L6 -> ~7 people
  - L7 -> ~25 people
  - L8 -> ~70 people
The approximate 3x difference between the levels is also found in other organizations, for example in armies: division ~= 3 brigades, brigade ~= 3 battalions, battalion ~= 3 companies, company ~= 3 platoons.

Misunderstanding this is the source of almost all frustration with the promo process. This process is designed to build and expand the organization, not reward awesomeness. There are of course deviations from the simple schema I listed here, but this is the hard reference point.

Re: Software Engineering at Google (2020)

#230

Post by w10-1 »

As a counterpoint to the engineering/product/culture comments providing context on the book, I would point out that Urs Hölzle has recently stepped back from uber-manager to individual contributor in the infrastructure space.

This is the guy who built the hotspot JIT that added decades to the life of Java, and who engineered Google's data centers and GCP. He obviously doesn't need more money or glory or experience, so ... why?

There are a million examples of things gone wrong, but it may be worth studying one example of how someone could have such an impact and still just love what he's doing.

Post reply on HN