Leaving Google

I personally prefer to be given brutal honesty. Overly polite people often annoy me because they hide information or they can't get to the point or their point is hidden within layers of wishy-washy mush that I need to correctly parse and then respond correctly to.

Politeness is absolutely necessary, and I hate seeing callous impoliteness in wider society (e.g. towards service workers).

I suspect I would severely struggle in a deeply polite society (stereo-typically Asian?). I can relax the most around very direct people (Dutch?).

I am continually stressed when dealing with anyone that absolutely needs politeness. Example 1: a very close friend who can be triggered by anything reminding them of their abusive ex. Example 2: a self-centred acquaintance that needs pandering (however isn't polite in return).

There's a balance - but it's hard to find. Perhaps I'm confusing two different dimensions, politeness and honesty?

Edit: This is a wishy-washy comment. Difficult topic, straight-jacketed conflict, interpersonal stuff that is hard to understand and talk about.

For at least some of the L7+ people I know who have left they weren't interested in growth (others I'm not certain). I know one person who left because they weren't able to get the VPs to greenlight their stuff and eventually got frustrated by it but I definitely know others who left because "continue to be a responsible steward for this large ecosystem that is important to Google's ongoing success" was no longer a viable path to sustained work (as opposed to promotion).

> Less hiring means fewer natural opportunities for growth.

IC's natural way of growth is to produce larger impact by solving harder problems, there are always hard unsolved problems which hold some business opportunities.

> may not have had a basis in reality.

I believe there is a lot of reality. As well as they gave a lot of brilliant co-workers which seems to have made it a great place to spin ideas. Also from stories too leader ship was at least open to listen to criticism in "thanks God it's Friday" meetings.

While from observing some friends the promotion play was always tough as well. If you wanted to be promoted you always had to use your 20% time "wisely" which for some meant to still work on the main project. For other to strategically work on a side project they could use for the promotion panel.

Today's Google seem to be fully focused on numbers, where a lot of the spirit is gone. Back in the days when I visited some friends working for Google we went to Google for breakfast or met at Google for dinner as it was just a good place to hangout. (Which motivated people to stay at Google for more than their regular hours) Nowadays it seem to be more of a workplace.

Maybe 30-40 years ago it was finance, but by 1996 with the Netscape IPO, it was clear to anyone coming out of school (as I was then) that tech was the future and finance was already old and tired after 15 years of dominance.

There was a mad rush between mid-1997 and mid-2001 to get into tech, then the dot-com bust happened, but that only lasted about 2 years before things ramped up again. That was 20 years ago.

Suggesting that the first decade of the web didn't flip the bit from finance to tech is ahistorical.

I mean even today, if you really want to make a ton of money in software, you're still targeting finance stuff. Not banks, but like HRT or similar.

I've always used the analogy of 90's Wall Street to explain the Tech industry behind the curtains. Our 2008 moment will be when society realizes AI is nothing but a tool for wealth transfer from what remains in the middle class to the top ultra wealthy.

We had a brief window in the mid 2010s when folks started to throw rocks at the tech buses where I thought people were starting to realize it. Around Bernie's presidential run - which makes sense because he preached wealth inequality. But somehow during COVID tech slithered back into everybody's good graces.

* I don't condone people throwing rocks at the buses for both the humanitarian reasons and the fact that few if any executive or social changes could result from that behavior. But it struck me as a microcosm of the prevailing sentiment towards technology workers.

As someone that mostly enjoys the Microsoft ecosystem, that isn't necessarly a good goal.

It has always seemed to me that level of strategic direction doesn't come from the CEO's brain, but from the big investors. The CEO's job is to execute what they want.

I wouldn't call Google the world's most powerful company. Saudi Aramco, for example, has more power.

For the most part, yes, yes you can.

Anyone at Google from 2005 to 2025 is a multi millionaire many times over based on stock value alone. Even a savant at squandering money would struggle to come out of 20 years at Google without unreasonable wealth.

It's possible for Ian to mean what he says, while also missing additional context (high net worth) that changes the perspective of the reader.

Russ Cox didn't leave. He's still on the Go team at Google, but he's stepped down from his position as tech lead.

Maybe they are safe from being laid off, though you never can tell [1]. But it does not mean they enjoy the tension, the demands, the disagreements, etc that likely crop up. At their position, they can afford to not put up with that, not hold onto the enviable salary, like many others doubtlessly and begrudgingly do.

[1]: https://nerdy.dev/ex-googler

Insulated by whom? Most of the old time sr Eng mgmt is either gone (replaced by oracle people, or people like them) or have shifted to that mode of operation.

Why would you think that? You still have management, you have to go through perf calibration and justify your performance. Engineering like most human profesional activities is a very social endeavor where you rely on the people that surround you and you always have people pressuring you to do something.

[delayed]

Sad and not surprising. Presumably when you are in the US with US sized total compensation this is even more of a problem. It is also a sign that the technical buffer layer (people like directors, VP, CTO) is not functioning well and also points to issues with company vision and roadmap.

I don't think it's wrong per se to suggest that Google should not be in the business of "Go" e.g. but presumably there are many other areas where similar technical expertise can be used in this size of company.

That said I've seen good people get stuck in large companies. They are put in a certain bucket and find it very hard to change. Sometimes leaving is the correct answer.

As someone who switched to Go in its early days (from C++) and had some interaction with the community (bugs, conventions etc.) it's a little sad but I think also just the way things go.

I have yet to see a thing made better by LLMs.

I've seen things with more impressive results, but then interlaced with garbage results. Far less reliable is the outcome.

Whether it's the now horrible pixel camera app, search results, or really anything else, it's all garbage

Meanwhile, yay!, let's use a billion times the compute.

If you are internal to Google, you can find his goodbye letter with a fair amount of additional detail. He chose not to make that additional detail public, so I won't either.

Indeed countless companies went under investing in tech, on various iterations of the exact things that later became enormously successful, e.g. iPhone. Success is only guaranteed in retrospect.

Yes. This was a weird case and I suspect that there was some internal politicking to enable Munich as the location to rebuild the team. I don't have any inside baseball on this, but pretty much every other case of "blow up the team and rebuild it elsewhere" I've seen in the past three years has been a move to a much lower cost region (India, Mexico, and Poland are big ones). The languages group has a bunch of people in Munich and several leaders there, which I suspect played a role in getting the team to be built in a mid cost region rather than a low cost region.

Still a mess and my understanding is that the AI portions of the company were none too happy given that the bulk of their development is done in python.

Why is it shocking? Big tech has thoroughly embraced layoffs and offshoring as a means to cut costs. Execs don’t care if it causes issues at the lower levels of the company. To them it’s just noise from the rabble. If it does cause an issue they’ll just call their buddies at the other Big Corp and work someplace else.

Welcome to big corp with Excel driven decisions, sorry, Google Sheets.

People sometimes know where they want to get, often that place can be described with buzzwords. They don't always know how to get there. Clueless managers often don't know how to get there, they might only have an inkling as to what are some of the properties of their desired state.

They will talk about that subset of things, they cannot do anything else for they are not aware of the how, much less the whole picture. Once the teams deliver a state with the desired and the unspecified and undesired properties, the team and the manager get angry.

Could it be possible, that overall impact of the decisions is clear to the upper management (but the language that is being used, masks the exploitative behavior/profit maximization). But that feels unlikely, if they just assign people to positions were they are not good fit.

The intent of the statement, at least every time I heard it, was to reflect how the difference between a bad workplace and a good workplace can often be how effective your direct manager is - at shielding their reports from bullshit they shouldn't have to deal with, at not micromanaging while still consistently delivering results, so on and so forth.

Yes, people leave jobs for all sorts of reasons, but your direct manager is the one who can most influence your workplace experience while also having a fundamental power imbalance by definition, and so is often the thing people are fleeing if they leave.

Microsoft was an amazing place to work for 10-15 years (in the late 90s and early 2000s) despite higher interest rates. I was there so I know it.

Buffers are there to deal with flow variances. What you are describing as the "ideal system" is a clockwork. Your async-awaits are meshed gears. For this approach to be "ideal" it needs to be able to uniformly handle the dynamic range of the load on the system. This means every part of the clockwork requires the same performance envelope. (a little wheel is spinning so fast that it causes metal fatigue; a flow hits the performance ceiling of an intermediary component). So it either fails or limits the system's cyclical rate. These 'speed bumps' are (because of the clockwork approach) felt throughout the flow. That is why we put buffers in between two active components. Now we have a greater dynamic range window of operation without speed bumps.

It shouldn't be too difficult to address testing of buffered systems at implementation time. Possibly pragma/compile-time capabilities allowing for injecting 'delay' in the sink side to trivially create "full buffer" conditions and test for it.

There are no golden hammers because the problem domain is not as simple as a nail. Tradeoffs and considerations. I don't think I will ever ditch either (shallow, preferred) buffers or channels. They have their use.

I agree with many of your points, including coroutines being a good abstraction.

The reality is though that you are directly fighting or reimplementing the OS scheduler.

I haven’t found an abstraction that does exactly what I want but unfortunately any sort of structured concurrency tends to end up with coloured functions.

Something like C++ stdexec seems interesting but there are still elements of function colouring in there if you need to deal with async. The advantage is that you can compose coroutines and synchronous code.

For me I want a solution where I don’t need to care whether a function is running on the async event loop, a separate thread, a coprocessor or even a different computer and the actor/CSP model tends to model that the best way. Coroutines are an implementation detail and shouldn’t be exposed in an API but that is a strong opinion.

So that fits, given that Go compiler, linker, assembler and related runtime are all written in Go itself.

You mean an OS kernel, like Java Real Time running bare metal, designed in a way that it can even tackle battleship weapons targeting systems?

https://www.ptc.com/en/products/developer-tools/perc

I wouldn’t include compilers in that list. A traditional compiler is a batch process that needs to be fast enough, but isn’t particularly latency sensitive; garbage collection is fine. Compilers can and are written in high-level languages like Haskell.

Interpreters are a whole different thing. Go is pretty terrible for writing a fast interpreter since you can’t do low-level unsafe stuff like NaN boxing. It’s okay if performance isn’t critical.