Summarizer

This is huge advice for people who want to climb a given career ladder. The overwhelming majority of organizations will say they want you focused on real user problems, but actually want you to make your boss (and their boss) look good. This usually looks more like clearing tasks from a list than creating new goals. At Google there are both kinds of teams.

Tell us you've never worked in a faang without telling us.

The other argument about this is whether or not an SWE is a fungible resource. When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another. We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.

LoL managers.

No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either. You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".

I was told at university that every software system is a socio-technical system. Keeping a mental note of that fact has helped me throughout my career.

No, that's HR justifying its existence. Plus that's for higher stature service based roles, not warehouse logistics. It's also mostly bullshit. Teams work because they have the right combination of skills, both personal and technical, high EQ and IQ, leadership and ownership. Whether or not you fall backwards into a team's arms or have to participate in childish games is not relevant.

15 years in leadership worked at 3 jobs lead major transformations at retail where nearly 100B of revenue goes through what i built. Ran $55-$100M in a yearly budget… over 300 FTEs and 3x contractors under my or my budget,…largest retailer in google at that time…my work influenced GCP roadmap, Datastax roadmap, … much more all behind the scenes…. besides your capabilities and ability that had to be there to get you in those positions - but once you are in those positions - only that mattered is politics and asskissing. I know so many people smarter than me, always stayed lower b/c they didn’t know how to play politics. Only reason i never got higher was I didn’t know how to play politics and kiss ass any more or any better. The top people are all who kissed each others ass and looked out only for their cohort (e.g. people who were in same positions as them in early 2013). So teach your kids to kiss ass and play poltiics.

> actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort Ie. Somewhat serious mental disorders as requisite for leadership. I wonder how we got onto this darkest timeline?

It isn't the highest paying path in life, but this is what I chose as well. Working for small companies with good people is infinitely better than working at massive companies with decent people. No matter how many good intentions there are, the politicking is utterly exhausting and unfulfilling. Then again, I'm the kind of person who moved to the countryside to get away from the city life, so YMMV.

Sometimes. Sometimes it's just bullshit . Learn the lingo, the language, the proper way of posturing and the correct way to shirk responsibility and that's what matters in certain orgs. I sound really bitter, but I'm not, I'm actually quite good at the game and I've proven that, I just don't really like the game because it doesn't translate into being able to take pride in what I've done. It's all about serving egos. Your own and others. Every french multinational I've worked for is entirely built on this.

You're not wrong. You're just missing the thing people are complaining about: The existence of people who succeed in pushing for inferior solutions, and managing to leave before it becomes clear (which can take years in a large company). My previous company is in a bad position and many such folks are finally being outed. But it takes lots and lots of screwing up before the fat is trimmed.

> Some companies will pay a bigger price than others. The problem is that typically a large company has one or a few golden geese. They can milk it for a long time because of an existing moat. The moat keeps shrinking, but it can sometimes take a decade or two for others to catch up.[1] That's plenty of time for such folks to make a career of playing politics well without contributing much. Lots of people at that company left before things went bad and are poisoning other companies. [1] Just look at Google and search. Or Microsoft and Windows. Or even Microsoft and Internet Explorer.

> The top people are all who kissed each others ass and looked out only for their cohort (e.g. people who were in same positions as them in early 2013). So teach your kids to kiss ass and play poltiics. After more than 20 years in big tech, I agree, this is basically it. Your work can only get you so far. If it makes you feel any better, you can reframe politics as 'people systems' and work on optimizing the relationships in the system. Or whatever. But the gist of it is to find a powerful group and try to become a member of that group.

Thats sociopathy in corporate world. Big companies have often 20-40% of such individuals, ie finance has way more (as I see daily) and concentration rises as you rise up in ranks. The thing is - you don't have to play that game. Sure, you will miss some promotions to largely meaningless titles, much more stress and pressure in such work, and a bit of money but in most companies the money is not worth it (ie work 50% more to get 20% more compensation, in net income rather 10% more since extra income will be hit with high marginal tax bracket in most countries). But main reason is - what you do 40+ hours weekly for decades (and especially how you do it) seeps back in into you even if you actively try to prevent that. Is it really worth tainting your personality permanently with more sociopathic behavior and thinking, with subsequent negative effect on all personal relationships and even things like personal happiness? I am old enough to see these trends among peers, they are very gradual but once you know what to look for, rather obvious. When poor such a deal is easy to rationalize since poverty can be crippling, but once beyond that quality of life should be top priority, we are here for rather short time. Otherwise most probably regrets happen later, just listen well to old folks what they are proud of and what not so much.

Tell that to Facebook's Metaverse team

feels LLM assisted, at the very least. > The skill isn’t being right. It’s entering discussions to align on the problem > clarity isn’t a style preference - it’s operational risk reduction > The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate > This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone > The problem isn’t that engineers can’t write code or use AI to do so. It’s that we’re so good at writing it that we forget to ask whether we should. > This isn’t passive acceptance but it is strategic focus > This isn’t just about being generous with knowledge. It’s a selfish learning hack "Addy Osmani is a Software Engineer at Google working on Chrome and AI." ah, got it.

I’m stunned at the reception this is receiving, it’s LinkedIn-tier slop.

This kind of thinking is how you get cults of personality. If he puts his name to this kind of slop, I’ve probably not missed much.

I liked that one, too, but for an additional reason. Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install the version of the PageReader™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ toolchain to their version). And so on. All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google.

ridiculous. > Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop what have you shipped? paying sees literally hundreds of thousands of dollars a year to ship out fledged out software that no one wants is exactly why Stadia lasted both way too long and got cancelled anyway. figuring out what is useful is the hardest problem. if anything that's Google's biggest problem, not shipping fast enough, not iterating fast enough.

Yeah if only Google shipped more crap software that they then go onto cancel, their software would be so much better!!!!!

The problem is I've worked at at least 5 companies that professed a strong "bias for action" and it nearly always meant working nights and weekends to ship broken things that ultimately hurt the user and then moving on to the next big leadership project to do the same thing again, never looking back. The exception of course would be when leadership finds it's broken in 5 months and complains about poor engineering practices and asking why engineers can never get things right. I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality. This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!"

Read it carefully. He's not saying that these are all common values or practices at Google. He's saying he learned those lessons while working at Google. Despite the metaphor of a "lesson", a "lessons learned" post is almost never about something the author was explicitly told. It was something that you had to learn from experience, or at best from informal advice. Where you had to swim against the flow of your circumstances. I neither think Osmani means to say that Google is _against_ these lessons. Every organization as big as Google has a lot of accumulated wisdom that will help you. These are just the things which remain hard, and some of which are even harder in a large organization.

I say that in most of my past experiences I learned how to NOT do something, so when facing a similar scenario, I’d do them differently.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock" When I worked on user facing stuff (Maps, Gmail, Accounts) I regularly read the public user support forums and ticket queues looking for complaints, sometimes I even took part in user threads to get more information. What I learned was: • Almost nobody else in engineering did this. • I was considered weird for doing it. • It was viewed negatively by managers and promo committees. • An engineer talking directly to users was considered especially weird and problematic. • The products did always have serious bugs that had escaped QA and monitoring. In theory there were staff paid to monitor these forums, but in practice the eng managers paid little attention to them - think "user voice" reports once a quarter, that sort of thing. Partly that's because they weren't technical and often struggled to work out whether a user complaint was just noise or due to a genuine bug in the product, something often obvious to an engineer, so stuff didn't get escalated properly. This general disconnection from the outside world was pervasive. When I joined the abuse team in 2010 I was surprised to discover that despite it having existed for many years, only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team. He gave me his logins and we quickly discovered spammers had found bugs in the accounts web servers they were using to blow past the antispam controls, without this being visible from any monitoring on our side. We learned many other useful things by doing this kind of "abuser research". But it was, again, very unusual. The team until that point had been dominated by ML-heads who just wanted to use it as a testing ground for model training.

Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. I think there are multiple reasons for this, but they are mostly overlapping with preserving internal power structures. PM's don't want anecdotal user evidence that their vision of the product is incomplete. Engineering managers don't want user feedback to undermine perception of quality and derail "impactful" work that's already planned. Customer relations (or the support team, user study, whatever team actually should listen to the user directly) doesn't want you doing their job better than they can (with your intimate engineering and product knowledge). And they don't want you to undermine the "themes" or "sentiment" that they present to leadership. Legal doesn't want you admitting publicly that there could be any flaw in the product. Edit: I should add that this happens even internally for internal products. You, as a customer, are not allowed to talk to an engineer on the internal product. You have to fill a bug report or a form and wait for their PMs to review and prioritize. It does keep you from disturbing their engineers, but this kind of process only exists on products that have a history of high incoming bug rate.

It’s oblique but this puts me in mind of an old adage I recently heard about war: Of 100 men, one should be a warrior, nine should be soldiers, and 90 shouldn't be there at all. I think this is true of software developers too: only in companies, the 90% don’t really know they shouldn’t be there and they build a whole world of systems and projects that is parallel to what the company actually needs.

this and I speak as one of the 90%

I think he has a point. These power structures exist for some good reasons as well. The opposite thing (engineers engaging directly with customers) can eventually lead to customer capture of your engineering org. You shouldn't have a small group of existing, noisy customers directly driving your engineering to the detriment of other existing or future customers. Microsoft had customer capture institutionally: the existing big corporate customers were all that mattered. It lead to rebooting Windows CE into Windows Mobile way too late to make a difference, for example. But it also meant that backwards compatibility and the desire to ship Windows XP forever were sacred cows. There are also nasty games that can be played by soliciting negative feedback for political advantage. Dysfunction can exist with any structure. It's probably best that there's some small amount of direct user feedback as well as the big formalized feedback systems, at least so that one is a check for the performance of the other. If the user engagement team says everything is good, but there are massive Reddit threads about how horrible the product is to work with and the engineers know it could be better, it's time for engineering to start addressing the issues alongside feedback to the user engagement teams.

Poor leaders gonna lead poorly.

Theres another thread on HN at the moment about legislation being written by industry and rubber stamped by law makers. What hit me about this discussion and that one is that there's a lot of self interest out there with very little scrutiny or auditing. It boils down to that basically. If we want to fix problems at the top there needs to be independent auditing, reporting and consequence for people that do the wrong thing. But we all know thats not going to happen so buckle up and learn to live with broken laws and broken software.

"10. In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency. The engineers who stay sane and effective zero in on their sphere of influence. You can’t control whether a reorg happens. You can control the quality of your work, how you respond, and what you learn. When faced with uncertainty, break problems into pieces and identify the specific actions available to you. This isn’t passive acceptance but it is strategic focus. Energy spent on what you can’t change is energy stolen from what you can." ------------------------ Point 10 makes it sound like the culture at Google is to stay within your own bailiwick and not step on other people's toes. If management sets a course that is hostile to users and their interests, the "sane and effective" engineers stay in their own lane. In terms of a company providing services to users, is that really being effective? User interests frequently cross multiple bailiwicks and bash heads with management direction. If the Google mindset is that engineers who listen to users are "weird" or not "sane"/"effective", that certainly explains a lot.

I love reading this insights in a corp structure. Especially the sociological aspect of it (like "• It was viewed negatively by managers and promo committees."). Thanks a lot.

Well, the 101 idiom comes from US education, it's a reference to the introductory course. Part of the problem with anti-abuse work is that there's no course you can take and precious little inter-firm job hopping. Anti-abuse is a cost of business so you don't see companies competing over employees with experience like you do in some other areas like AI research. So it's all learning-by-doing and when people leave, the experience usually leaves with them. After leaving Google the anti-abuse teams at a few other tech companies did reach out. There was absolutely no consistency at all. Companies varied hugely in how much effort and skill they applied to the problem, even within the same markets. For payment fraud there is a lot of money at stake so I'd expect eBay would have had a good team, but most products at Google didn't lose money directly if there was abuse. It just led to a general worsening of the UX in ways that were hard to summarize in metrics.

The beancounter takeover was after you left. 2014 Google and 2019 Google were completely different companies.

Having only ever worked for startups or consulting agencies, this is really weird to me. Across 6 different companies I almost always interfaced directly with the users of the apps I built to understand their pain points, bugs, etc. And I've always ever been an IC. I think it's a great way to build empathy for the users of your apps. Of course, if you're a multi billion dollar conglomerate, empathy for users only exists as far as it benefits the bottom line.

Thanks for sharing your valuable insights. I am quite surprised to learn that talking to customers was frowned upon at Google (or your wider team at least). I find that the single most valuable addition to any project - complementary to actually building the product. I have a feeling a lot of the overall degradation of software quality has to do with a gradual creep in of non-technical people into development teams.

Xoogler here. When you get to a company that's that big, the roles are much more finely specialized. I forget the title now, but we had someone who interfaced with our team and did the whole "talk to customers" thing. Her feedback was then incorporated into our day-to-day roadmap through a complex series of people that ended with our team's product manager. So people at Google do indeed do this, they just aren't engineers, usually aren't product managers, frequently are several layers removed from engineers, and as a consequence usually have all the problems GP described.

PM is a fake job where the majority have long learned that they can simply (1) appease leadership and (2) push down on engineering to advance their career. You will notice this does not actually involve understanding or learning about products. It's why the GP got that confused reaction about reading user reports. Talk to someone outside big company who has no power? Why?

> Google UX is decent and the author was not trying to comment on UX as a thing at Google. Interesting, so he was not, contrary to the blog title, writing on the basis of his 14 years of experience at Google?

I am not sure I follow - is he, or is he not, writing about his experiences from 14 years at Google? The title suggests he does, yet you suggest that he does not?

His learnings from 14 years at Google. Surely we've all learned things working for employers or with engineers that don't do a thing well. In 14 years he probably also experienced great engineers come and go and start other successful businesses they very likely did not run exactly like Google.

This is almost certainly not the case. The larger the company the more change is viewed as a negative. Yes people may hold titles to do the things you describe but none are empowered to make change.

More seriously - open source software is resistant to enshittification. It's obviously not a panacea, but the possibility of forks (or just the user deciding not to update), combined with the difference in profit motive, tends to result in software that respects the user. (Taken holistically, the UX of software does not just mean the UI, or the moments when you are using the software. It also includes the stability of the software over time, including whether or not you are able to reject new versions whether you do not like.)

This. The only real risk with open source is that a (fairly niche) project is discontinued/abandoned, and you can't find binaries anymore for it anymore (and you don't have the skills to build it yourself). But this happens to proprietary software all the time (see killedbygoogle.com).

You can learn something at a company by observing it’s weaknesses as well as strengths

> wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse UX? Google doesn't even bother helping folks locked out of their Gmail accounts. For people who use Android (some 3bn), that's like a digital death sentence, with real-world consequences. It is almost comical that anyone would think Google is customer-focused, but might if they were being paid handsomely to think otherwise, all the while drinking a lot of kool-aid. https://news.ycombinator.com/item?id=36024754 The top comment there is from a Xoogler which sums it up nicely: The thing is that at scale your edge cases are still millions of people. Companies love the benefits that come from scale, like having a billion people use their service, but they never seem to be capable of handling the other parts that come with it :( Google rakes in $100bn a quarter; that's $1bn every day.

> 1. The best engineers are obsessed with solving user problems. The author lost me right here. Not because he’s wrong about this in general - he is not. But it seems to not be any kind of differentiator at Google. Maybe the opposite is true- make it as screwed up as physically possible, then make it a little worse, then release it - that seems a lot closer to the lesson Google engineers learn. As long as you are “first” and shipped it. Then get promoted, move on and meanwhile your crap code eventually gets the axe a decade later.

Technically he said these are lessons he learned after working at Google, not that Google was necessarily doing these things. If we’re being generous maybe he learned this by counter example haha

Google still suffers the most from not understanding those two. Probably more than other companies.

Have they ever had an outage in recent years though? Pinging 8.8.8.8 is the gold standard of making sure there's internet in my book.

GCP has had some multi-region outages

Eh, sure. But at the same time lessons aren't learned by reading what someone else has to say. They're learned by experience, and everyone's is different. An engineer with "14 years at Google" hardly makes them an expert at giving career advice, but they sure like to write like it does. This type of article reads more like a promotion piece from self-involved people, than heartfelt advice from someone knowledgeable. This is evident from the author's "bio" page: written in 3rd person, full of aggrandizing claims of their accomplishments, and photos with famous people they've met. I'm conditioned to tune out most of what these characters have to say. If this is the type of people who excel in Big Tech, it must be an insufferable place to be.

Reading that bio makes you wonder if anyone else works at Google…

Seems reasonable. Many points maybe more applicable Google/Google-like companies. With layoffs and overall job shortages a lot of workplaces are having a cake and eating it too. They demand fast delivery and taking shortcuts (calling it creative thinking ) and once things blow up directly due to shortcuts put blame on developers / testers for taking shortcuts and compromising quality in the process.

I don't know if there's a named law, but the word for not knowing and believing that something remembered is a novel idea is "cryptomnesia". Knowing that you know something by teaching is Feynman's method of understanding. Basically, on scanning, I don't particularly disagree with the content of the post. However, treating these things (many of which regularly show up here on HN) as being due to "14 years at Google" is a little misplaced. But, hey, it's 2026, CES is starting, and the hyperbole will just keep rocketing up and out.

> The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected. > The engineer who starts with a solution tends to build complexity in search of a justification. I do agree this is a good point, I just find it funny that it comes from "staying 14 years at Google". This is literally the reason why I left Google first, and Meta second. Finding simple solutions will get you absolutely nowhere in a place like those. You have to find complex solutions with a lot of stakeholders, alignment, discussions, escalations... Why ship one button if you can ship 100 and get you, your team and your manager promoted in the process?

> In large organizations, decisions get made in meetings you’re not invited to, using summaries you didn’t write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you’re not in the room, your impact is effectively optional. Very true in large organisations. But... in a company whose stated mission is to " organize the world's information and make it universally accessible and useful " ... this feels like a failure. When a truly data driven company manages to quantify impact by more than the volume of hot air emitted :) then it's going to eat the world. Perhaps it's for the best that nobody does that?

> Addy Osmani is a Software Engineer at Google working on Chrome and AI Thanks for all the spyware in Chrome ig? And for many inane design decisions that favor usability over privacy and security?

Funny that there’s nothing to learn from working for an evil company, other than: keep your head down and don’t ask hard questions :/

Aren't #2 and #14 mostly the same point? And they seem to indicate a rather unhealthy cultural dynamic. Amazon's "Disagree and commit" is a much healthier dynamic than "Pretend to agree and then silently sabotage." I think there's a valid middle ground in finding a path that works well for everybody, but this does not seem to be the right way. I wonder if this is a common thing at Google because I recall another interview (can't find now, I think in the context of WebRTC??) from many years ago where an engineer proudly described how he conspired against a major technical decision because it didn't align with his personal preferences. I was a bit shocked to see someone admit something like that so publicly.

I think part of the importance of being a senior engineer is not spreading hype through the industry. This appears to be the guy who just posted all over social media that they just got Claude and redid a year long project in a week, followed by tweets from his eng team clarifying its just “demo” grade.

> This appears to be the guy who just posted all over social media that they just got Claude and redid a year long project in a week It would take less time than it did to write this comment to look it up and see that these are two different people. Google engineer [Jaana Dogan] says Claude Code built in one hour what her team spent a year on https://news.ycombinator.com/item?id=46477966

This is good. I worked at google and lasted less than 2 years. Many other things happening in that time - came in via acquisition, worked on backend for that, dad died, transitioned teams, etc. But I was 27-28 and couldn't really navigate that world after my first job at a startup. In some ways, I wish I'd found a way, but in other ways, I know it wasn't meant to be. It's a good list, if you want to do 10 years at Google or elsewhere, internalise that list and it's lessons.

There are many big bosses under the Google CEO that lead hordes of developers to specific targets-to-meet. Eventually they prioritise their bonuses and the individual goals deviate with every iteration. So the quality will diminish continuously.

I am 70% sure this is partially ai generated. It is furthermore hard to believe that the engineers are working for the users, given that google’s primary activities today are broad enshittification of their products. Because of these two things I did not make it past point 4.

I'm going to pick out 3 points: > 2. Being right is cheap. Getting to right together is the real work > 6. Your code doesn’t advocate for you. People do > 14. If you win every debate, you’re probably accumulating silent resistance The common thread here is that in large organizations, your impact is largely measured by how much you're liked. It's completely vibes-based. Stack ranking (which Google used to have; not sure if it still does) just codifies popularity. What's the issue with that? People who are autistic tend to do really badly through no fault of their own. These systems are basically a selection filter for allistic people. This comes up in PSC ("perf" at Meta, "calibration" elsewhere) where the exact same set of facts can be constructed as a win or a loss and the only difference is vibes. I've seen this time and time again. In one case I saw a team of 6 go away and do nothing for 6 months then come back and shut down. If they're liked, "we learned a lot". If they're not, "they had no impact". Years ago Google studied the elements of a successful team and a key element was psychological safety. This [1] seems related but more recent. This was originally done 10-15 years ago. I agree with that. The problem? Permanent layoffs culture, designed entirely to suppress wages, kills pyschological safety and turns survival into a game of being liked and manufacturing impact. > 18. Most performance wins come from removing work, not adding cleverness One thing I really appreciated about Google was that it has a very strict style guide and the subset of C++ in particular that you can use is (was?) very limited. At the time, this included "no exceptions", no mutable function arguments and adding templtes had an extremely high bar to be allowed. Why? To avoid arguments about style issues. That's huge. But also because C++ in particular seemed to attract people who were in love with thier own cleverness. I've seem some horrific uses of templates (not at Google) that made code incredibly difficult to test for very little gain. > 9. Most “slow” teams are actually misaligned teams I think this is the most important point but I would generalize it and restate it as: most problems are organizational problems. At Meta, for example, product teams were incentivized to ship and their impact was measured in metric bumps. But there was no incentive to support what you've already shipped beyond it not blowing up. So in many teams there was a fire and forget approach to filing a bug and forgetting about it, to the point where it became a company priority to have SLAs on old bugs, which caused the inevitable: people just downgrading bug priorities to avoid SLAs. That's an organizational problem where the participants have figured out that shiping is the only thing they get rewarded for. Things like documentation, code quality and bug fixes were paid lip service to only. Disclaimer: Xoogler, ex-Facebooker. [1]: https://www.aristotleperformance.com/post/project-aristotle-...

This article can be summarized as: description of doing software development in a sizeable enterprise not a startup. From where I know: living and breathing like it for the last 19 years

I hate that he is right. It speaks deeply about how broken the incentives are for humanity and labour and why AI will ultimately destroy jobs, because AI won't need to deal with all the sacred rituals around politics and control and human management. For each stupidity that we worship just to "preserve company culture", we step into the inevitable doom like having a Google principal engineer worship Opus on X like it's the first time they went to prom and saw someone hot. It is sickening and it is something we have internalized and we will have destroyed ourselves before we settle on the new culture of requesting excellence and clarity beyond the engineers who have to deal with this mess.

Reading this makes me so happy I'm not at google anymore

Biggest lesson is you will get mass fired. So look for whats best for you, because you are the only one who can?

Here's the lessons all ex-Google colleagues I've worked with have brought with them to their new jobs: 1. Use Bazel for everything. Doesn't matter that the documentation sucks and it's unbelievable bloat for smaller companies: use it anyway. Use it for everything. 2. Write things from scratch. Need a protobuf parser in C? Just write one up instead of using any of the battle-tested open source options. 3. Always talk down to frontend engineers and treat them as lesser/ not real engineers. Real engineers are backend engineers. Frontend is so easy that they can do a perfectly fine job if needed. Make sure to use Bazel for all frontend builds. 4. Did I mention Bazel? It's the solution to all problems for all companies.

> Focus on what you can control. Ignore what you can’t. That's why I left Google for HFT. Much better life.

As much as we meme about it internally, one of my favourite things about AWS was the leadership principles. I always worried I've became cult like biased. Seeing how these converge to similar great ideas is a relief. IMO the most common denominator among all these is trust, in order for many of these to work. From policy setting at strategic level, hiring, to tactical process refinement, the invariant must always be building an environment and culture of trust. Which isn't trivial to scale.

> 1. The best engineers are obsessed with solving user problems. Complete bullshit. Sorry, but the reason why people use Google is because of the ecosystem + value proposition. Google Drive & Calendar are some of the most outdated pieces of SaaS software that only gets used because of the greater ecosystem they live in - and price. They (along with the other Google products) are also some of the poorest designed user interfaces online. Let's cut the crap for once here. If I were Google I would be worried because companies like Fastmail, Notion & Proton are quickly catching up.

> If I were Google I would be worried because companies like Fastmail, Notion & Proton are quickly catching up. lol do you honestly think Google is worried about Fastmail, Notion or Proton?

> are quickly catching up. If you were Yahoo a few years before Google it would sound the same.

Thats a poor characterization to choose 2 of the least talked about apps from that company. Also your response to the claim "the best engineers do X" is logically flawed. Maybe google doesn't use their "best engineers" to build out those cherry-picked examples? maybe they used them for Search or infrastructure or something else?

google has a lot more products besides the 2 you picked. Some of them are wildly successful, even. Maybe they use their "best engineers" on the more successful products?

A lot of lessons from Google are really lessons from a historically unique monopoly era that no longer exists. Useful context, but dangerous to treat as timeless advice.

Wish I'd read this before I started at Google.

Worked at an AI training company for a few months. Enshittification is real. Idiots who never deserved to be here coming up with new policies every week, sometimes twice a week. Absolutely spineless when receiving nonsense from the client which is one of FAANG but will screw colleagues with no remorse.

it's sad that startups become corps and decay. this article is the perfect illustration, from the bio, to the llm slop content of the article. Just sad it has to be this way

It's funny that I agree with most or all of these principles but don't feel like my 10 years at Google accord with most of this. I wouldn't say I learned these things at Google, but learned them before (and a bit after) and was continually frustrated about how many of them were not paid attention to at Google at all? Incentive structure inside Google is impaired. I do think Google engineering culture does bias against excessive abstraction and for clean readable code and that's good. But acting in the user's interest, timely shipping, etc... not so much.

Maybe OP learned these things precisely because he saw the consequences of them not being done

This has to be the 50th or 100th version of this article that repeats the same thing Every single point in this article was already explicitly described between roughly 1968 and 1987: Brooks formalized coordination cost and the fallacy of adding manpower in The Mythical Man-Month Conway showed that system architecture inevitably mirrors organizational communication structure in 1968 Parnas defined information hiding and modularity as organizational constraints, not coding style, in 1972 Dijkstra *repeatedly warned* that complexity grows faster than human comprehension and cannot be managed socially after the fact None of this is new, reframed, or extended here; it is a faithful re-enumeration of half-century-old constraints. These lists keep reappearing because we refuse to solve is the structural one: none of these constraints are enforceable inside modern incentive systems. So almost like clockwork somebody comes out of nowhere saying hey I’ve I’ve observed these things that are consistently documented in history of organizational management and specifically computing and software management look at this list. It’s so Exhausting

Yeah but what do you want to do about it? The engineers I see making these mistakes day-to-day are not going to connect the dots if I just point them to the seminal writings. Heck, half of their complaints are of the same form as yours: if only the majority of [engineers, colleagues, stakeholders] were aware of [A, B, C principles] then we could avoid repeating [X, Y, Z failures]. Yeah it's exhausting, life is exhausting, and it doesn't inherently get better with knowledge and experience as the gap to the lowest common denominator only increases; the only balm I've found is focusing on what I can control.

Well for starters I literally organized our company and all engineering around Conway‘s law and it’s working great That’s like the absolute bare minimum you can do, it’s trivially easy and solves a good half of these “problems.”

Seems like the author had lost his personality during that 14 years trying to appease the strange people at the top or figure out the allpermeating bs they force on people.

Oh my god. I have never seen an about/bio page even half as gross and cringey as his. https://addyosmani.com/bio/ It's so obscene that it seems like it's a parody > Colleagues often remark on Osmani’s humility LOL! Who writes these things about themselves with a straight face?! It also shows that taking credit for others' work is 100% his MO. > Osmani’s team created Workbox, a set of libraries for generating service worker scripts that handle caching and offline functionality with minimal fuss. Workbox simplified what used to be a complex task of writing low-level code to intercept network requests. No, Jeff Posnick (who I suppose technically was on addy's team) created workbox and it has been basically abandonned since he left Google. Or was it Sundar Pichai's team who made workbox? Or does Brendan Eich deserve the credit? I have to assume the rest of the bio, and his career, has been built off of usurping credit. He always rubbed me the wrong way, and this vindicates that sense. What a psychopath!

Although little note at the very end explains why: > This note is in response to emails from Eli Grey to Chrome leadership from October, 2023 In other words, he wrote this because he was forced to.

seems the real lesson would be to not spend 14 years at google

Oh my god. I have never seen an about/bio page even half as gross and cringey as this. It's so obscene that it reads like a parody > Colleagues often remark on Osmani’s humility LOL! Who writes these things about themselves with a straight face?! It also shows that taking credit for others' work is 100% his MO. > Osmani’s team created Workbox, a set of libraries for generating service worker scripts that handle caching and offline functionality with minimal fuss. Workbox simplified what used to be a complex task of writing low-level code to intercept network requests. No, Jeff Posnick (who I suppose technically was on addy's team) created workbox and it has been basically abandonned since he left Google. I have to assume the rest of the bio, and his career, has been built off of usurping credit. He always rubbed me the wrong way, and this vindicates that sense. What a psychopath!