I must be really awful at explaining my point or there's an awful lot of willful ignorance in this thread. Either way, something awful is going on.

Read carefully: the engineering culture of Google - it's practices, policies, principles, insiprations, and so on - did not make Go. The prior experiences of the Go authors, and a handful of specific and obvious influences, both of which are objectively not of Google, made Go. Google's engineering ethos does not get credit for Go, though maybe an argument can be made that their wallet gets credit. Personally, I don't agree with that, but it's beside the point.

The part that I don’t understand is: why does Google not get credit, in your opinion, for having built an engineering org from qualified people?

Google hired the engineers who made Go. A company’s engineering ethos is the combined ethos of its engineers. The Golang developers are engineers who Google hired.

To attempt to draw a metaphor: if I operated an auto repair shop, and I wanted my shop’s “ethos” to be “we do high-quality repairs on cars”, one of the primary ways to do that would be to hire smart, already-experienced mechanics. And it would seem strange to me if people wrote blog posts saying that the work of those mechanics didn’t count towards my “ethos” because they were already good at their jobs; that’s why I hired them!

As a tangential comment, phrases like “Read carefully” seem extraneous, as does the accusation of “an awful lot of willful ignorance”. They just serve as jabs at the other commenters here.

Go was principally made by 3 people, whose resumes basically justified being allowed to work at their discretion (this last bit is conjecture, but I would be surprised to be proven wrong). If Ken Thompson has a manager at Google that has any influence whatsoever on Ken's work, then Google's culture is more broken than I thought. The rest of Google is over 100,000 engineers who have managers, team leads, and much more rigid policies and workflows than I imagine the Go designers were ever subjected to during the development of Go. This is the engineering ethos to which I refer, not the system to which the Go designers where subject.

So: Google gave a chair and a desk to a few talented people who applied experience and influences from entirely outside of Google to designing a programming language. In my book, Google doesn't get credit for that, and their engineering culture definitely doesn't get credit for that - it was barely involved, if at all.

FWIW I am an ex-Googler and I agree with you. The principal authors of Go are not really Googlers in the sense that other "mere mortals" are. Their engineering skills, practices, and decisions are not informed or subject to the strictures of the wider culture at Google.

To help me understand, can you give an example of the kind of stricture that applied to other engineers but not to the Golang core team?

Rob Pike and Ken Thompson have Sundar as their manager (I saw this at least with other Google Fellows) and don't go through perf in any real sense if they actually do have a perf process which I doubt they do. They do whatever they want and set their own agendas. At Google seniority is revered. It's very strict in that sense so I literally cannot imagine someone "overruling" or mounting any serious opposition to Pike or Thompson on anything.

Edit: They're not actually fellows it's been pointed out but high ranking ICs like that do have a lot of respect within Google and are treated deferentially, especially famous ones just based on my own experience with high ranking ICs.

> Rob Pike and Ken Thompson have Sundar as their manager

This isn't true (and I don't believe it's ever been true).

> I saw this at least with other Google Fellows

This also isn't true in general, there are no Google Fellows that report directly to Sundar. Not to mention that neither Ken nor Rob is a Fellow.

> and don't go through perf in any real sense

Why do you believe this to be true? Many people of similar stature (VPs are approximately equivalent to Google Fellows, and there are tons of VPs) have a real perf process, although it doesn't quite resemble the one you or I would have.

If you mean that he has no incentive to "play perf games", then that's true only insofar as they don't want to advance, which is true for the average Google engineer starting at L4 or L5.

> At Google seniority is revered.

This hasn't been my experience at all, I've had quite reasonable experiences pushing back against my directors and questioning my VPs.

I’m not sure I understand your examples. You note that they don’t go through any sort of performance review process, but your subsequent sentence suggests you don’t really have visibility into whether that’s the case? And then you point out that as senior engineers, you can’t imagine anybody opposing things they say.

Do you have an actual example of ways in which their treatment by Google differs from other engineers? These seem like conjecture about what their work experience is like.

I'm attempting to offer you some insight in good faith. I can't offer you a mathematical proof of this so I'm not sure what you're looking for. If you insist on asserting that Google Fellows are treated the same as other engineers then I'm not sure what to tell you. Holding that view would call into question exactly why they had that title but I'm not you and I don't hold that view.

I’m asking for an anecdote or some other practical example of a time that you or another Google engineer had a policy or “stricture” applied to you, and that policy or stricture or procedure didn’t apply to a Fellow. I don’t expect there to be a mathematical proof, but I was curious for something that wasn’t conjecture about what people assume their work environment is like.

Regarding being a Fellow: finding out that people respect senior engineers and take into consideration their past experience isn’t shocking, or an example of the rules not applying to them. Similarly, if you told me that a head chef at a restaurant has more impact on the menu than a line cook, it wouldn’t be an indication that the rules don’t apply to head chefs, or that nobody cares about their performance. And nobody would make claims that restaurant’s menu didn’t reflect their “ethos” because it was designed by an experienced head chef.

It's been pointed out by someone who still has access to the internal org chart that they're not actually fellows so the point is kind of moot with respect to that. I assume they're distinguished engineers but I'm not sure.

I actually do think that Go in its adoption by Google is a reflection of Google engineering values. I still don't think that someone who comes in to Google at the level that the Go creators came in would have the same experience as someone who came in entry level cut their teeth moving up through Google but that's just my perspective. A lot of people I met had only been at 1 or 2 other companies before Google (my TL had actually been at Google his whole professional life) and a lot of their opinions about engineering were shaped by how Google did things.

It seems like you’re making a couple of key assumptions about what the work environment looks like for the core Golang dev team, and then extrapolating from there to exclude them from your definition of Google’s “ethos”.

Separately, the idea that a manager having influence on a good engineer’s work is “broken” is one I don’t understand.

But I think, based on this comment thread, it’s unlikely we’re going to reach a consensus.

> if I operated an auto repair shop, and I wanted my shop's "ethos" to be "we do high-quality repairs on cars", one of the primary ways to do that would be to hire smart, already-experienced mechanics. And it would seem strange to me if people wrote blog posts saying that the work of those mechanics didn't count towards my "ethos" because they were already good at their jobs; that's why I hired them!

FWIW, that doesn't seem strange to me. Hiring smart, already-experienced mechanics is a input to your ethos; presumably you hope that they will make the shop's culture better-suited to doing high-quality repairs. A example of a output of that culture would be if you also hired young, inexperienced mechanics, and they learned (presumably from their aforementioned seniors) to do high-quality repairs and went on to be the next generation's smart, already-experienced mechanics.