As a counter-point, I worked at Google for two years and what the author is describing is completely consistent with my experience with the engineering culture and the systems it produces.

Fundamentally there is a hostility towards the philosophical aspect of software engineering which involves a careful consideration of the essential nature of the system as a whole as it relates to some ultimate end and the nature of logical components of the system and how they interact. Note that these considerations can occur prior to any code being written and also as part of an iterative process as the product and understanding of the product develops.

I believe this stems from three sources:

1. The criteria and process for getting promoted is very focused on shipping new and complex things which in practice is at the exclusion of all other considerations. This means that improving or maintaining existing systems or producing systems which are well architected at all is not as clearly valued. The promo committee is comprised of people who don't know the specifics of the systems you're working on so the easiest thing to convey is that feature X or product Y was shipped.

2. There is a hyper-rationalist, hyper-modernist, data-driven, anti-intuitionist view which pervades Google which completely discounts any sort of philosophical/qualitative thinking. People get really uncomfortable when you try to start even the most anodyne discussion about the product or service as it relates to some broader goal since those involve qualitative judgements that can't be reduced down a set of metrics. Some of this may be attributed to the CYA culture among management.

3. The interview process doesn't select for software engineering or software architecture skills (aka people who have developed an intuitive understanding of the art of software engineering) so there are many people within Google who lack the ability to effectively evaluate the architecture choices that are being made around them or that they themselves are making.

With all that said I did meet and work with many brilliant engineers and others who were very talented and did think deeply about things but those were relatively rare. And yes it is a big company with many different teams and subcultures but what the author and I have described are the patterns that one sees broadly across Google.

It’s pretty uncool to use just two years of experience at a place as a credential to shit on the culture of that place (and through implication, the engineers there).

I’ve been at Google for six years, and I’ve never encountered a “hostility towards the philosophical aspect of software engineering”. What a bunch of hooey.

There are certainly problems with the promotion system (and incentives it creates), but it’s laughable to say that it rewards shipping “at the exclusion of all other considerations”. In two years, I imagine that you didn’t yet serve on promo committees (or see many successful and failed promotions of colleagues), so I’m not sure your criticisms are coming from a deep understanding of how they work.

I’m sorry that you had a bad experience, or that you felt your specific working group had some kind of CYA culture or anti-engineering vibe. But it upsets me to see people indirectly shitting on or commenting about tens of thousands of engineers that they had never worked with or even interacted with. I don’t know why it’s fashionable to do this with Google right now, but it just shouldn’t happen with any company.

If you want to describe your specific, concrete experience, I’m sure that would be much more helpful and constructive than saying “the culture is X”, “Google engineers are Y” without any connection to specifics. My 2c.

If you've been at Google for 6 years then you know that my point about the promo system is the dominate opinion held by engineers there. Not that Memegen is the best barometer but you should check that out around promo time since it does comport with the opinions of engineers I talked with in other contexts. I had thought that would be the least controversial point.

When I was there they added "Landing a product" as perf criteria as opposed to "Launching a product" and they added some lip service towards maintenance tasks being perfable which is a reflection of the problems I laid out.

I don't know you or your situation and there are always exceptions (e.g. Bram Moolenaar, of course, and others not as famous) but in my experience the more tenure an engineer had the worse they were. The best engineers I've met in my career were ex-Googlers who were only there for a few years (some of them became Xooglers while I was there).

My assertion is that generally speaking the people who stay are the ones who don't see the problems in the system because they don't have the talent, experience, or perspective OR they have other priorities in their life (raising a family) and Google makes it easier for them.

What I encountered was that many long time engineers just weren't aware of what else was out there, the advances in the state of the art, and how things could be better because they were cozily ensconced within the Google ecosystem for so long. It's an incredibly ossified environment.

I don’t know how many people you worked with closely in two years, but I strongly suspect it’s not enough to properly conclude that “the more tenure an engineer had the worse they were”.

I’ll point out the irony of having this discussion on this post. Many of the Go team engineers have a long tenure, but the author wanted to attribute “good” things only to “not Google” influences.

Yes, the promo system has issues. Yes, there are widely held beliefs about it. But not all widely held beliefs are accurate: there’s usually some truth, but as always, it’s complicated.

Yes, there are some echo chamber issues. But engineers are much more aware of the outside world that you’re implying.

I just think your assertions are pointlessly mean by virtue of being overly broad (in terms of who and what). I like to see specific criticisms of any company, even if backed by an anecdote, because you can learn something.

What’s anyone’s takeaway supposed to be here?

Personally I am not a fan of Go so I can't speak to that.

However, conditioned on Go existing and someone using it, the category of problems he's describing with the tooling are familiar.

To your point about engineers being more aware of the outside world, in my experience this only held for new engineers and the ones that try to bring in new practices tend to get shut down or pushed out. See: https://twitter.com/ThomasBurleson/status/128390216922628096...

Seeing this was so ironic because of all the engineers at Google, Rob actually came and gave a talk to our team about NgRx and he was one of the few engineers I encountered that really got engineering. Having him come give a talk to our team was like a breath of fresh air. I have no doubt there was some insane political BS he was subjected to and forced to leave.

As far as my assertions being "mean" because they are overly broad, the nature of speaking about anything requires some degree of generalization which I've tried to couch (and you're aware that I have). What a silly argument.

Another concrete example I can give you is that the people who run the Angular team also own support for Typescript at Google and they disabled .tsx support for Typescript (literally just a compiler flag that does simple desugaring) despite a ton of protest from a lot of teams using it. They did that to kill off and discourage React (which many people want to use) to consolidate political power. I had many private messages with new engineers that were upset when they got shut down for asking if they could use React. Obviously these people were trying to bring in practices from outside of Google.

The takeaway is whatever people want it to be.

Why would six years as an individual contributor be enough to make sweeping assertions about an entire company when two years is not?

googthrowaway's experience more closely matches my experience at Google, fwiw, but it's certainly the case that your experience depends on which org you're in. My org had a notoriously incompetent VP running things and it hemorrhaged staff to companies like Apple and Microsoft.

You missed the point: I didn’t make any sweeping generalizations. I’m advocating against that. The only generalization I made is that the existing generalization about anti-engineering is hooey.

And I don’t know why you’re assuming I’m an IC; I didn’t say that either.

I don’t have any problems with people sharing their specific personal experience. I have a problem when people start claiming good engineers are “rare” — you’re just insinuating bad things about tens of thousands of people you have never even met.

As a meta comment I will say that the rhetoric you're using is representative of the kinds of rhetoric you see on the internal mailing lists in case anyone reading whose never worked at Google wants to get a taste of what that's like. It literally reminds me of being back at Google.

>Not all of their engineering culture is like this.

Sure. I'll grant you Junio; he seems like a cool guy.

The rest of google though? Google's engineering culture is by and for google. They're not doing the rest of us any favors.

Googlers need to admit that. Not to me, but to themselves.

I'm seriously astonished by the depth of these Freudian analyses of the dark underbelly that is Google's "engineering culture", and how everything bad with the world can be linked to ...

... a meaningless decision to have a transparent proxy in some network path some free code takes on its way to you?

>a meaningless decision

If it's so meaningless, now that Drew has complained they can just make the alterative the default for their software right? Right? It is MEANINGLESS afterall.

When faced with a decision, someone chose the option that took extra operational expenses to keep services online. If you're going to call that a meaningless, then you've either a huckster or have got quite a lot to learn my friend.

Exactly! It's so meaningless they shrugged and flipped a switch when asked to do so in a single blog post. Try that feat with any policy decision google actually does care about!

I feel like Junio gets to be exempt from Google engineering culture because of his unique position.

They might be if they were true, but they're not: the only thing that was broken about sr.ht was that the links to the source code didn't work, but other than that it worked fine. The other sites mentioned like codeberg.org work just fine today, just without those links (a minor feature I almost never use). The whole "it needs meta tags" thing is also not true, I don't know where he got that from.

Quite a few points in this article are highly misleading.

codeberg.org only works with `go get` etc because they do have the meta tags set up.

The only way for a non-hardcoded host to work would be for the import path to contain ".git", ".hg", etc -- which is so ugly pretty much nobody does that.

Ah sorry, you're correct. I checked but forgot about the "?go-get=1" parameter it adds.

The entire thing is a bit hacky, but as mentioned in other comments godoc.org started as an independent project outside of Google and pkg.go.dev built on what was already in place. Was that the right decision? I don't know, I haven't looked at the matter and possible problems in-depth; all I do know it's far more nuanced than "Google being bad at engineering".

All of the parts of the engineering culture that are publicly visible seem like this.

This is the same author who wrote https://news.ycombinator.com/item?id=23966778 and also had some very one-sided things to say about Google.

I forecast a lot of HN upvotes :)

Personally I don't find the fact, that a corporation built something out of their own interest surprising at all.

I don't understand what this comment is saying about Hacker News or Drew DeVault. Are the points any less valid just because they do not praise Google? And just because something is unsurprising does not mean that it is good or acceptable, or that we should not urge them to do better.

>Personally I don't find the fact, that a corporation built something out of their own interest surprising at all.

It's not surprising, but it is concerning given that Google is the steward of the joint interests of all Go users.