22 ms·

Lessons from 14 years at Google

• kayo_20211030 10mo ago
  Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true. The two that stand out are > Novelty is a loan you repay in outages, hiring, and cognitive overhead. and > Abstractions don’t remove complexity. They move it to the day you’re on call. as a warning against about being too, too clever.
  • pcurve 10mo ago
    Agreed. Not just engineers, but basically everyone involved in creating products including designers and PMs. Every single bullet point here is gold.
  • gdulli 10mo ago
    There's rarely a bullet point advantage that some new language or tech stack can offer me that would outweigh ten years of observation of how a familiar setup behaves in production, such that the space of unknown unknowns is reduced to almost nothing.
    • simonw 10mo ago
      My personal rule is that the new technology stack item needs to either make is possible for me to build something that I couldn't have built without it, or needs to provide a productivity boost significant enough to overcome the productivity lost by straying from the more familiar path - even harder for team projects where multiple people need to learn the new component.
      • kayo_20211030 10mo ago
        Yeah. I'm in agreement there. I guess that it's an application of The Law of Least Surprise for a future developer (who might actually be me, which it often is)
  • imiric 10mo ago
    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.
    • doublerabbit 10mo ago
      Mood. As someone who normally leaves after two years because the opportunity never raises to what was offered in the job spec these really don't for for me these bullet points as well wouldn't work for office culture in the EU. 15 Years worth of jobs and none gel. I'm a contractor now which feels more me. I have a contract length, don't have to deal with red tape political bullshit. Turn up, do work and leave when contract had ended.
      • willi59549879 10mo ago
        If you can easily acquire new projects and are happy with what you do, that can be very nice. I would probably fail at selling myself
        • doublerabbit 10mo ago
          I've never needed to sell myself. $corp will advertise needing a contractor and you apply as usual. If you have the skills and experience you tend to get hired. The only difference is you don't get job security, pension or any perks. But you do get a lump sum though. Where you can then decide what's best.
    • gosub100 10mo ago
      And google wasn't founded by people who just kept their heads down and employed the simplest, most direct solution to the problem. If they had done that, google search would have been done on a super-fast server or mainframe using an RDBMS.
  • morshu9001 10mo ago
    Google still suffers the most from not understanding those two. Probably more than other companies.
    • moffkalast 10mo ago
      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.
      • morshu9001 10mo ago
        GCP has had some multi-region outages
• apsurd 10mo ago
  The writing is excellent. Very correlated with the quality of the message I'd imagine.
  • spiralcoaster 10mo ago
    It is very heavily filled with LLM-isms. The writing is bland AI output.
    • apsurd 10mo ago
      how do you know? in the first item, LLMs don't use incomplete sentence fragments? > It’s seductive to fall in love with a technology and go looking for places to apply it. I’ve done it. Everyone has. But the engineers who create the most value work backwards: they become obsessed with understanding user problems deeply, and let solutions emerge from that understanding. I suppose it can be prompted to take on one's writing style. AI-assisted, ok sure, but hmm so any existence of an em-dash automatically exposes text as AI-slop? (ironically I don't think there are any dashes in the article) EDIT: ok the thread below, does expose tells. https://news.ycombinator.com/item?id=46490075 https://news.ycombinator.com/item?id=46490075 - yep there's definitely some AI tells. I still think it's well written/structured though. > It's not X... it's Y. That one I can't unsee.
      • croemer 10mo ago
        And have a look at the bio: https://addyosmani.com/bio/ https://addyosmani.com/bio/ > His story isn’t just about writing code, but about inspiring a community to strive for a better web. And perhaps the most exciting chapter is still being written, as he helps shape how AI and the web will intersect in the coming decade. Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come.
  • rvz 10mo ago
    The blog-post is AI generated or at least AI assisted.
• firefoxd 10mo ago
  They are pretty insightful. Particularly this one: > 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. I have my own version of this where I tell people that no amount of good advice can help you make a blank page look better. You need to have some published work before you can benefit from any advice.
  • fuzzythinker 10mo ago
    Disagree. There's levels to this. Not all bad pages are better than blank ones. Ones that harms user data or worst is worst than blank pages.
  • rapidfl 10mo ago
    It is good only if the whole team believes it. If the team mates have a different mindset, they see it as half baked or hacky. And if there is ever some bad feedback, they just use it as a "I told you so" and throw you under the bus.
    • sowbug 10mo ago
      If your self-esteem is sufficiently resilient, you can exploit the same human tendencies behind Cunningham's Law (the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer). Check your crappy end-to-end proof of concept into the team repository, and your teammates will be so horrified and outraged that they'll fix it faster than any sprint could have planned.
      • rapidfl 10mo ago
        yeah there are ways, but is it good for your career lol Also the one person who has to review it before checking in needs to be resilient too
    • songodongo 10mo ago
      Bad feedback can be more helpful than good and is often the only type of feedback a product gets. And you may not have received that feedback if you didn’t ship. It’s better to get that information early.
• nickcw 10mo ago
  I like this one > At scale, even your bugs have users. Something I discovered the hard way over many years of maintaining rclone. Fixing a bug has consequences and there are sometimes users depending on that bug! xkcd: https://xkcd.com/1172/ https://xkcd.com/1172/
  • baal80spam 10mo ago
    Thank you for your work on maintaining rclone! It is a wonderful and very underappreciated piece of software.
  • davidw 10mo ago
    It's a good one: but it's also good to see that most of these are applicable to all kinds of organizations, not just "Google Scale" places.
  • davelee 10mo ago
    I know this as Hyrum's Law (which also comes from a Googler): "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
• ThrowawayR2 10mo ago
  > "Writing forces clarity. The fastest way to learn something better is to try teaching it." Something that seems lost on those using LLMs to augment their textual output.
  • NitpickLawyer 10mo ago
    > You can edit a bad page, but you can’t edit a blank one.
    • ThrowawayR2 10mo ago
      Ideally, yes, but the final result of LLM assisted textual output by many users shows that they often have neglected the editing part just as much as they have neglected the writing part.
      • paulpauper 10mo ago
        Airplane meme: you only see the bad LLM or obviously LLM-assisted writing.
      • AnimalMuppet 10mo ago
        My father-in-law did a fair amount of editing back in the day (on paper, with red pencil/pen). He said that, when you saw something that had "blood" (red) all over it, that meant it was good. When things are bad enough, it becomes hard even to edit it. It may not be just that people don't edit LLM output. It may be that the stylistic blandness is so pervasive, it's just too much work to remove. (Yeah, maybe you could do it. But if you were willing to spend that kind of effort, you probably wouldn't have an LLM write it in the first place.)
  • aprilthird2021 10mo ago
    This article is partly LLM generated or edited, fairly certain
    • paulpauper 10mo ago
• simonw 10mo ago
  I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/ https://boringtechnology.club/ Likewise, "Abstractions don’t remove complexity. They move it to the day you’re on call." made me think of this 23 year old classic from Joel Spolsky, the Law of Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
  • jiggawatts 10mo ago
    My former boss had a rule of “One novel thing per project”. This was both an upper and lower limit, which ensured that he was “always learning”. I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.
    • BurningFrog 10mo ago
      That actually sounds brilliant!
    • zelphirkalt 10mo ago
      That's fine ... only have to size your projects accordingly!
  • JuniperMesos 10mo ago
    > I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/ https://boringtechnology.club/ I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.
• trescenzi 10mo ago
  > At scale, even your bugs have users. First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee the software was ready before they’d even stood up from their desk! The moral of the story, and the quote, isn’t that you shouldn’t improve things. Instead it’s a reminder that the software you’re building doesn’t exist in a PRD or a test suite. It’s a system that people will interact with out there in the world. Habits with form, workarounds will be developed, bugs will be leaned for actual use cases. This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.
  • jacquesm 10mo ago
    For close to a decade my business revolved around a common bug in both Microsoft and Netscape, the dominant browsers of the day. With every release we were thinking 'this time they'll fix it' and that would have caused us some serious headaches. But they never did!
    • Donald 10mo ago
      I was curious what the commenter's business was, and found this post about HTTP protocol latency: https://jacquesmattheij.com/the-several-million-dollar-bug/ https://jacquesmattheij.com/the-several-million-dollar-bug/
      • Lammy 10mo ago
        What a cool guy https://jacquesmattheij.com/domains-for-sale/ https://jacquesmattheij.com/domains-for-sale/
• xnx 10mo ago
  Nothing novel, but all true, well expressed, and worth repeating. This should be part of every CS curriculum. #2 and #14 are tough pills to swallow. It's not enough to be right, or even have a long track record of being right. You usually have to convince others that it was their idea all along, but still advocate for yourself at performance review time.
• api 10mo ago
  The biggest one that resonates with me is that cleverness is overhead. My #1 issue with mid level engineers is that they like complexity and find complexity fun and interesting. An experienced engineer knows that complexity is irritating and frustrating and that a simple solution is harder and superior. A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. If you are good you will do this a few times in your whole career.
  • elktown 10mo ago
    > A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. Well put. Chasing "How simple can we make this?" is a large part of what makes this job enjoyable to me. But it's perhaps not a good career advice.
    • api 10mo ago
      Yeah, "resume driven development" is a second major force pushing complexity that I didn't mention. People want to be able to get experience with as many buzzwords and technologies and stacks as they can for obvious personal self interest reasons. The incentive is real. A great programmer who does a great job simplifying and building elegant maintainable systems might not get hired because they can't say they have X years experience with a laundry list of things. After all, part of their excellence was in making those things unnecessary. It's a great example of a perverse incentive that's incredibly hard to eliminate. The net effect across the industry is to cost everyone money and time and frustration, not to mention the opportunity cost of what might have been had the cognitive cycles spent wrangling complexity been spent on polish, UI/UX, or innovation. There's also a business and VC level version of this. Every bit of complexity represents a potential niche for a product, service, or startup. You might call this "product portfolio driven development" which is just the big brother of "resume driven development."
      • elktown 10mo ago
        Again, very well put. It often becomes a chain-reaction as well.
• unlimit 10mo ago
  I am going to file this line > If you win every debate, you’re probably accumulating silent resistance.
  • ronbenton 10mo ago
    That one makes me uncomfortable, which is a bad sign...
    • edonhametsu 10mo ago
      I'd say it's a good sign – at least now you're aware it might be happening. A worse sign would be thinking you're definitely not that sort of personality; you'd be accruing silent resentment from both being loud _and_ clueless.
  • deleted 10mo ago
    [deleted]
  • sseagull 10mo ago
    This is one of the Five Dysfunctions of a Team (fear of conflict, caused by absence of trust). Highly recommend the book. https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea...
  • matwood 10mo ago
    Sun Tsu said you have to either give your opponent an out or completely destroy them. I’ve always said that you can only skin a sheep once but can shear them over and over. Or to be more blunt, it’s better to be effective than right. It’s about keeping the bigger/long term goals in mind. That means relationships and being an asshole.
  • sublang 10mo ago
    [dead]
• geodel 10mo ago
  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.
• igtztorrero 10mo ago
  Great post, Years following Addy. I wonder know how he manages his time, in addition to being a leader at Google, and writing such a valuable blog.
  • sefrost 10mo ago
    Unsure why this comment appears to be downvoted! I have followed him for a long time and learned a lot too. I always wonder the same thing about the “tech influencers” and I’d love to know more about how they structure their days. I find it difficult recently to sit down and complete a meaningful piece of work without being distracted by notifications and questions. In the last year this has been exacerbated by the wait time on LLMs completing. I would love to know how top performers organise their time.
• ethagnawl 10mo ago
  14 years? Wild. I remember when Addy came into the scene hot with a new jQuery tutorial (what seemed like) every few days. To be clear, that's not a knock despite how it may read in 2026.
• sublimefire 10mo ago
  I’d agree on most of these but the biggest value in such a list is for the writer to actually put it on paper. You have to reflect on multiple aspects in your career and synthesise those. Reading them is close to useless, like scanning a page full of news, it all just evaporates once you start your daily work routine. The best suggestion would probably be to try and write such a list yourself IMO.
  • frgturpwd 10mo ago
    It also does not help that this has ChatGPT writing signature all over it. :)
• suralind 10mo ago
  Thank you for sharing this. Well articulated.
• GuB-42 10mo ago
  > At scale, even your bugs have users Also known as ossification. It is a term most often heard in the context of network protocols, but it applies more generally to every system where users depend on unspecified behaviors and even bugs. Reading about HTTP/3 and QUIC is interesting in that aspect. I first didn't understand the insistance on encryption. Turns out it is not just security and privacy, but by encrypting everything that is not strictly necessary for proper transport, you make it impossible for any "middlebox" to make assumptions they shouldn't make. I think similar approaches can be used by APIs. Never expose more than what is specified, treat the ability to access internal state as a bug, not because it is secret, but because if users start relying on it, internal changes that shouldn't break anything will.
  • venkyvb 10mo ago
    Similar to Hyrum 's Law for APIs
• adamnemecek 10mo ago
  > Abstractions don’t remove complexity. They move it to the day you’re on call. Then they are bad abstractions. I get where he is coming from, but the entire field is built on abstractions that allow you to translate say a matmul to shuffling some electrons without you doing the shuffling.
• croemer 10mo ago
  I clicked through to the bio and am super confused. Third person, extremely long, lots of pictures with CEOs and smelling of LLM writing. Here's a sample: > His story isn’t just about writing code, but about inspiring a community to strive for a better web. And perhaps the most exciting chapter is still being written, as he helps shape how AI and the web will intersect in the coming decade. Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come. https://addyosmani.com/bio/ https://addyosmani.com/bio/
  • nostrademons 10mo ago
    He led Chrome DevRel for many years - if you were learning about new web platform technologies circa 2010-2015 you probably ran across his writing. The bio is cringe, but the important thing to realize about these professional-networking bios is that they are sales pitches, intended to sell a person (and specifically, their experience and connections) to a large corporation who will pay them even more money. An ordinary person, with ordinary authentic emotions, is not the intended audience. They're specifically selling to people whose job is to deal with bullshit.
  • bakugo 10mo ago
    The linked post itself also reeks of LLM writing (negative parallelisms in every other paragraph). But sadly, it seems like this is just the new standard for highly upvoted front page posts.
  • youngtaff 10mo ago
    Reading that bio makes you wonder if anyone else works at Google…
  • cube00 10mo ago
    Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come. And modest too.
• jimmyl02 10mo ago
  Usually there are nuggets of wisdom in lists shared like this but I feel like every lesson shared here has immense value. > "remain skeptical of your own certainty" > "Model curiosity, and you get a team that actually learns." These are two lessons that typically require battle scars to learn. For such big ideas to be summed into two sentences is pretty remarkable and puts to words lessons I wish I knew how to share. Amazing article, thanks for sharing!
  • DougN7 10mo ago
    I was going to skip the article until I read your comment, and wow! You’re totally right - my hard won understanding is there, including things I sort of knew but couldn’t put into words before. Going to share this with my adult kids.
  • naijaboiler 10mo ago
    same usually, i read this and see this some flawed or hackneyed tripe. But these ones are actually true and anyone who has had a long career and led people and product will resonate with many of them.
• lklkllko 10mo ago
  [flagged]
  • rvz 10mo ago
    Some people just want to be remembered for the "engineering" / "social engineering" they did, while others what to be remembered for being employee of the month for 10+ years at the company. Both are a complete waste of time. It's more impressive if you bootstrapped your own company to millions instead of chasing false praise, engaging in employee politics and being employee #470293 at big company. But I predict you will get the same thing with those at the big AI companies.
• ronbenton 10mo ago
  >Abstractions don’t remove complexity. They move it to the day you’re on call. Damn that's a real one. Nothing like struggling through a bunch of indirection to figure out what the heck a clever abstraction was supposed to do
• deleted 10mo ago
  [deleted]
• nemo1618 10mo ago
  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. Insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance. Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. I'm so tired bros
  • spiralcoaster 10mo ago
    Thank you for doing this. It allowed me to skip reading the article altogether immediately knowing it is AI generated slop. Usually I'm a little ways into it before my LLM detector starts going off, but these "This isn't X. It's Y." phrases are such a dead giveaway.
  • papacj657 10mo ago
    So glad I’m not the only one that noticed that. There’s some really solid insights here, but the editing with AI to try to make up for an imperfect essay just makes the points they’re trying to convey less effective. The lines between what is the author’s ideas and what is AI trying to finish a half or even mostly baked idea just removes so much of the credibility. And it’s completely counter to the “clarity vs cleverness” idea and the just get something out there instead of trying to get it perfect.
  • aprilthird2021 10mo ago
    It's just so disrespectful. I put my time in reading this. You (author) couldn't put some time into reading this once over before publishing? The points are generally good too, which is why the AI slop tone bothers me even more.
    • 10mo ago
• misterchocolat 10mo ago
  that was an amazing read
• blibble 10mo ago
  seems the real lesson would be to not spend 14 years at google
  • paulpauper 10mo ago
    I'm sure he made a killing though
    • mgrat 10mo ago
      It isn't just that he made a killing — Osmani helped conceive a broader vision of blogging as a fusion of human in the center writing and AI agents.
      • croemer 10mo ago
        Or to say it in his own words: "Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come." source: https://addyosmani.com/bio/ https://addyosmani.com/bio/
        • blibble 10mo ago
          > and that legacy will be felt for a long time to come yes, the legacy of polluting the internet with unlimited "AI" slop to the point it became useless
        • tuananh 10mo ago
          it's a bit weird to talk about yourselves in third person
        • nchmy 10mo ago
          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!
• johnmwilkinson 10mo ago
  > 4. Clarity is seniority. Cleverness is overhead. Clarity is likely the most important aspect of making maintainable, extendable code. Of course, it’s easy to say that, it’s harder to explain what it looks like in practice. I wrote a book that attempts to teach how to write clear code: https://elementsofcode.io https://elementsofcode.io > 11. Abstractions don’t remove complexity. They move it to the day you’re on call. This is true for bad abstractions. > The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. (Dijkstra) If you think about abstraction in those terms, the utility becomes apparent. We abstract CPU instructions into programming languages so we can think about our problems in more precise terms, such as data structures and functions. It is obviously useful to build abstractions to create even higher levels of precision on top of the language itself. The problem isn’t abstraction, it is clarity of purpose. Too often we create complex behavioral models before actually understanding the behavior we are trying to model. It’s like a civil engineer trying to build a bridge in a warehouse without examining the terrain where it must be placed. When it doesn’t fit correctly, we don’t blame the concept of bridges.
  • kenferry 10mo ago
    I agree with you re: abstraction - one of the author's only points where I didn't totally agree. But also worth noting that whenever you make an abstraction you run the risk that it's NOT going to turn out increase clarity and precision, either due to human limitation or due to changes in the problem. The author's caution is warranted because in practice this happens really a lot. I would rather work with code that has insufficient abstraction than inappropriate abstraction.
    • johnmwilkinson 10mo ago
      Broad strokes: absolutely. The practical reality gets tricky, though. All programming abstractions are imperfect in some regard, so the question becomes what level of imperfection can you tolerate, and is the benefit worth the cost? I think a lot of becoming a good programmer is about developing the instincts around when it’s worth it and in what direction. To add to the complexity, there is a meta dimension of how much time you should spend trying to figure it out vs just implement something and correct it later. As an aside, I’m really curious to see how much coding agents shift this balance.
• huflungdung 10mo ago
  [dead]
• joshribakoff 10mo ago
  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.
  • magicalist 10mo ago
    > 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 https://news.ycombinator.com/item?id=46477966
• AndrewKemendo 10mo ago
  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
  • DenisM 10mo ago
    The fact that people don’t learn from the older books is somewhat annoying, but rewriting them makes sense precisely because people will likely trust it more. Software engineers are prone to novelty bias. Thats in contrast to some other demographic groups who very much prefer ancient texts.
    • AndrewKemendo 10mo ago
      Well both of them are wrong because they can’t walk the middle path
  • dasil003 10mo ago
    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.
• cmrdporcupine 10mo ago
  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.
  • mji 10mo ago
    Maybe OP learned these things precisely because he saw the consequences of them not being done
• maximgeorge 10mo ago
  [dead]
• green_wheel 10mo ago
  #12 is so simple yet so true. Great list thanks for sharing.
• MinimalAction 10mo ago
  > If you win every debate, you’re probably accumulating silent resistance. This is very true in personal lives as well.
  • petermcneeley 10mo ago
    This is actually slave morality: https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality According to Nietzsche, masters create morality; slaves respond to master morality with their slave morality. Unlike master morality, which is sentiment, slave morality is based on ressentiment—devaluing what the master values and what the slave does not have. As master morality originates in the strong, slave morality originates in the weak. Because slave morality is a reaction to oppression, it vilifies its oppressors
• lukasb 10mo ago
  Wish I'd read this before I started at Google.
• Scubabear68 10mo ago
  > 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.
  • deleted 10mo ago
    [deleted]
  • einsteinx2 10mo ago
    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
• ThinkBeat 10mo ago
  > First do it, then do it right, then do it better. Get the ugly prototype in front of users. Great, give users something that messy, horrible and not fully functional. Customer who spend big for production environments are exploited to "be the outsourced QA"
  • morshu9001 10mo ago
    It's ok if the users are internal
• drnick1 10mo ago
  > 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?
  • lionkor 10mo ago
    > 1. The best engineers are obsessed with solving user problems.
• hansmayer 10mo ago
  Not looking to dismiss the authors long tenure at a major tech company like Google, but the first point kind of stuck like a sore thumb. 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. Every single one of their services is a pain to use, with unnecessary steps, clicks - basically everything you are trying to do needs a click of sorts. Recently I was writing an e-mail and noticed I misspelled the e-mail address of the recipient, which I rarely do. So, I should just be able to click the address and edit it quickly, right? Wrong - now you have a popup menu and inside of it you have to search for "edit e-mail" option. Most of the rest of his lessons while valuable in their own right, are not something I would put under the headline of "after X years at <insert-major-tech-company>", as they do not quite seem to be that different from lessons you pick up at other companies ? I´d more interested to hear about how the culture was impacted when the bean-counters took over and started entshittifying the company for both the users and the employees too.
  • embedding-shape 10mo ago
    > If the Google culture was at all obsessed about helping users It's worth noting that Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer working on a product shipped to users. It might be useful to keep that in mind as you read through what his lessons are, because they're surely shaped by the positions he held in the company.
    • hansmayer 10mo ago
      Ah, I see. I did notice it looked a bit too long-winded and fluffy for a developer-written text.
    • vcsuspect 10mo ago
      [dead]
    • drewda 10mo ago
      Fair point. "User" as developer rather than "user" as person clicking buttons in Gmail, Google Maps, etc, etc
• j3s 10mo ago
  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.
  • bencornia 10mo ago
    I got the same feeling. The writing is too punchy.
  • joduplessis 10mo ago
    oh shit. actually, yea
  • throwaway132448 10mo ago
    I’m stunned at the reception this is receiving, it’s LinkedIn-tier slop.
    • pritambarhate 10mo ago
      May be because you are not familiar with Addy Osmani and his work. He is known for his very high quality performance optimisation work for web for almost a decade now. So anything he has read, edited and put his stamp of authority on is worth reading.
      • throwaway132448 10mo ago
        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.
    • 10mo ago
• bmink 10mo ago
  > Bias towards action. Ship. …The quest for perfection is paralyzing. Unfortunately for users this is more often used as an excuse to ship buggy / badly done software.
• jama211 10mo ago
  I feel like the best lesson in here wasn’t numbered, but in the opening statement: > the longer I’ve stayed, the more I’ve realized that the engineers who thrive aren’t necessarily the best programmers - they’re the ones who’ve figured out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity. I have been banging on about this for _years_. I’ve seen engineers much smarter than me and who write much better code fall afoul of this too. Being personable and easy going and insightful for one hour in a meeting can do more for your reputation within a company than a month of burning yourself out completing more tickets than anybody else. I really wish more people understood this. At the end of the day, a manager or a project director who _wants_ you to join a meeting just because you’re a joy to be around and you may have some insight, shows you’re more valued than the best coder on the team if they’re a pain to bring into a meeting because they’re hard to talk to.
  • GoToRO 10mo ago
    I manager that invites people in meeting based on how obedient they are, is a bad manager. Multiplied by the number of reports. Fix that.
    • jama211 10mo ago
      I didn’t mention obedience, I mentioned pleasantness. Not sure what you’re on about with reports either. You ok?
• deleted 10mo ago
  [deleted]
• cletus 10mo ago
  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-google-s-data-driven-insights-on-high-performing-teams https://www.aristotleperformance.com/post/project-aristotle-...
• jackblemming 10mo ago
  This sounds like an accumulation and reiteration of other peoples ideas and blogs, barely changing or adding anything. Fair, but I was interested in the author’s own ideas or how those ideas they’re reiterating matter within the context of Google.
• joeyguerra 10mo ago
  lgtm
• lofaszvanitt 10mo ago
  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.
  • cube00 10mo ago
    17. Your network outlasts every job you’ll ever have. Maybe you're not allowed a personality after you unlock peak outlasting networking.
    • lofaszvanitt 10mo ago
      Pluribus effect :).
• riazrizvi 10mo ago
  This is a good list. Original, evidence to me that the author is the real deal.
  • imiric 10mo ago
    There's hardly anything original here. These are regurgitated points you'd see in any article of this type. In fact, your favorite LLM can give you the same "lessons" from its training data.
    • Gigablah 10mo ago
      Your favorite LLM can probably reproduce this entire discussion thread so what’s the point, right?
• throwaway132448 10mo ago
  The first paragraph reads like LinkedIn slop, so I scanned the rest of the titles - they indicate that the rest of the article reads the same.
• bigcloud1299 10mo ago
  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.
  • spicyusername 10mo ago
    So teach your kids to kiss ass and play poltiics. Or to stay far away and do something useful with their lives.
    • euifii 10mo ago
      This is what I really don’t get about these types of folks. Do they really want to remember their life’s work as “kissing ass and playing politics”? I get the “work to live” and all that, but you’re basically tossing away half your life…for what, money? How much money do you need!?
      • H8crilA 10mo ago
        You need to have the right personality. Either actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort. We don't get to choose our personalities, though some limited modifications are possible - see treatments for personality disorders, for example.
        • BLKNSLVR 10mo ago
• joduplessis 10mo ago
  > 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.
  • websiteapi 10mo ago
    > 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?
    • joduplessis 10mo ago
      > are quickly catching up. If you were Yahoo a few years before Google it would sound the same.
      • websiteapi 10mo ago
        the writing was already on the road w.r.t to user mindshare among normies. I see no evidence of the same happening with fast mail. why would anyone switch from gmail to fast mail other than privacy, which regular people couldn't care less about?
        • joduplessis 10mo ago
          Privacy, as well as overall product experience. Btw, I didn't just mention Fastmail.
  • gosub100 10mo ago
    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?
• deleted 10mo ago
  [deleted]
• tsoukase 10mo ago
  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.
• lazarus01 10mo ago
  excellent article and appreciate the author sharing his perspective which is very valuable. For me the main lesson is, don't let your ego develop from success. Any human is vulnerable to narcissism. It is an interesting phenomenon, where you can originate as a humble person who becomes successful, only to lose your great qualities, when your identity changes. With success you attract different people in your life who may be attracted only to your success and who don't have the stones to confront you on your bs. Developing healthy self awareness comes from surrounding yourself with people that love you, but are not afraid to keep you honest if you do something out of character.
• RomanPushkin 10mo ago
  Interview voice: - How do you actually grow being in one company for 14 years?
• foobarian 10mo ago
  Best part of the article? > but coordination costs grow geometrically Using geometrically instead of exponentially! Thank you!!! :-D
  • dullcrisp 10mo ago
    Yes this is an exponentially better word choice!
• dcminter 10mo ago
  > 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?
• richtersand 10mo ago
  GREAT ARTICLE!
• gosub100 10mo ago
  It's frustrating to read this advice, which to me can be summarized as "don't think too hard, dumb it down, keep it simple, be a people-person" and then look at their hiring process full of advanced data structures and algorithms. Why hire top tech talent if you just need to keep a simple vibe and not over-think clever solutions?
• d--b 10mo ago
  > 1. The best engineers are obsessed with solving user problems. A little bit of sarcasm here: “well there probably isn’t a lot of great engineers at google then”
• capr 10mo ago
  I don't believe any of this.
• RobRivera 10mo ago
  Number 14 really speaks towards the subtle difference between being domineering in conversation and genuinely a sme in an area with little overlap in other people's domain knowledge. I feel like being extremely transparent in explaining the rationale and to a degree teaching really reinforces that boundary. If you get to a point of silent resentment 'debt' in spite of efforts to empathise, consider perspective, and provide clarity, then you have a collaboration problem on the other end. How you choose to address that is dependent on your political capital, and sometimes you need to accept it. Young me naively believed people were like rational automatons who would speak up when appropriate, not take thinga personal, and aspire to the true north that I aspired to as a colleague, and that is no baseline for a healthy collaboration.
• seawsurf 10mo ago
  >Your job isn’t forever, but your network is. I'm very suspicious of this working in the modern technological age. Even in university I'm feeling this: it is hard to create a bond with real friends, but extremely easy to regress to anonymity and become a loner.
• qwertyforce 10mo ago
  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
• deleted 10mo ago
  [deleted]
• andyjohnson0 10mo ago
  > 15. When a measure becomes a target, it stops measuring. This is Goodhart's law - "When a measure becomes a target, it ceases to be a good measure" [1]. [1] https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
  • xmddmx 10mo ago
    Right, this annoyed me too - it was stated w/o attribution as if novel. What is the name of the law when someone writes a think piece of "stuff I've learned" and fails to cite any of it to existing knowledge? Makes me wonder if (A) they do know it's not their idea, but they are just cool with plagiarism or (B) they don't know it's not their idea.
    • euifii 10mo ago
      [dead]
    • chaboud 10mo ago
      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.
• bschmidt25000 10mo ago
  [dead]
• masondunn 10mo ago
  > Focus on what you can control. Ignore what you can’t. That's why I left Google for HFT. Much better life.
  • einpoklum 10mo ago
    Where you can serve corporate interests more directly and with less overhead? (:shrug:)
• neilk 10mo ago
  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.
  • tmcz26 10mo ago
    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.
• seattle_spring 10mo ago
  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.
• charlieyu1 10mo ago
  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.
• Sephr 10mo ago
  This feels somewhat hypocritical coming from Addy. Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts. I cannot accept his apology until he actually syndicates it with his followers. Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best code is the code you never had to write.", and "14. If you win every debate, you’re probably accumulating silent resistance." 1. https://addyosmani.com/an-apology-to-eli/ https://addyosmani.com/an-apology-to-eli/
  • rester324 10mo ago
    Thanks for sharing, I found the blogpost hypocritical even without knowing about this
  • zhouzhao 10mo ago
    Jesus, bro. Let bygones be bygones. How long is this ago? It's just code. And what the code did, is not even fundamental. It's not like you cured cancer.
    • dclowd9901 10mo ago
      I tend to see my code in these terms as well, it's not dear to me. But I'd never presume to tell someone how to feel over having their work stolen (and I'm using that term because that's how I'm sure Mr Grey felt).
      • nchmy 10mo ago
        just because people think or feel things, doesn't make those things valid (and certainly not prudent)
  • 0______0 10mo ago
    FWIW, the actual apology is well written.
    • 10mo ago
• bschmidt25000 10mo ago
  [flagged]
• timzaman 10mo ago
  Reading this makes me so happy I'm not at google anymore
• bschmidt25010 10mo ago
  [dead]
• bschmidt25013 10mo ago
  [dead]
• keeda 10mo ago
  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.
• titzer 10mo ago
  > 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. > First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. You’ll learn more from one week of real feedback than a month of theoretical debate. > Momentum creates clarity. Analysis paralysis creates nothing. I've met Addy and I'll be generous, but strong disagree here, and this really shows a huge blind spot in how software is being developed today that hurts everyone. There aren't two extremes between "theoretical debate" and just shipping the first crap you can slap together. Software engineering will never become a real discipline when industry keeps ignoring the lessons of every other field of engineering: gather some requirements first. Want to know what users want? How about asking them? What about doing some research on what tools they are using now (or not) and finding out what's wrong with them. What about doing a user study? What about analyzing competing and previous products? How about then drawing up a list of things that say what the thing will do? You can keep the list short, sure. Build a prototype (maybe for internal use)? Sure. No need to have every piece of functionality there. But there's an enormous blind spot here I'd be remiss to point out. Back in the shrink-wrapped software days, back when products took months and sometimes years to develop, man, people really planned out what they were going to build! And I'm not just romanticizing that era--there was a lot that could go wrong, and many misses--but tons of software developed in that manner sticks with us today, not just the designs and usage patterns, but big chunks of the code too. It's not all legacy cruft; people actually thought about what they wanted to build, and then laboriously built and tested it--with crappier tools, longer build times, and many disadvantages like huge teams, crappier communication, and a whole lot less computational power. There are other things in this list that are good advice, but I felt like this cannot possibly be the whole truth to 14 years of experience. In other words, please don't just ship your crap to us the first time it functions.
• etamponi 10mo ago
  > 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?
• asim 10mo ago
  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.
  • deleted 10mo ago
    [deleted]
• soorya3 10mo ago
  This first 3 hit me very hard, 1. The best engineers are obsessed with solving user problems. I think this problem is rooted in early education: students learn languages, frameworks, and tools first without understanding what problems they actually solve. Once engineers have experience building a few products for users, they begin to understand what matters to the user. 2. Being right is cheap. Getting to right together is the real work. - Sadly most of the arguments are won by either someone in power or experience. Right decisions are made with consensus. You build consensus during creative process and leverage power and experience during crisis. 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one. - Every decision is a risk management. The smart people convert higher risk into lower risk. Most people struggle here to take the risk because of the fear of failing and just waste time arguing, debating and winning over each other.
  • dartharva 10mo ago
    The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started.
    • FridgeSeal 10mo ago
      I think it depends on the team. Some teams I’ve been in, we could go “this is shit, we must be doing this wrong” and we’d go back to the drawing board without blinking. Other teams, just getting _something_ going, even if it was garbage, was a enormous achievement, and saying it was bad and that we should start again would be a recipe for disaster.
    • afro88 10mo ago
      But that is still better than nothing at all, which is the point. The people you want (or want to be) are the engineers who are smart and experienced enough to get a first draft down that is pretty much right without a long drawn out process of figuring out the best way to do X, Y and Z with all the lengthy ADRs, discussions, debates, POCs, revisions etc. over and over again. That may be necessary if you don't have people in the room who know what they're doing and have the intuition through deep experience to choose good tools, patterns and abstractions at the start. Begin closer to the target, rather than far away and iterate to it.
• mahirsaid 10mo ago
  Insightful take on career progress. Most engineers don't talk about this.
• RagnarD 10mo ago
  Thought occurred to me to throw this at ChatGPT 5.2: Given the article at https://addyosmani.com/blog/21-lessons/ https://addyosmani.com/blog/21-lessons/, find a short list of points which summarizes and touches on all of his lessons Answer: Here’s a short “umbrella list” that still covers all 21 lessons (each bullet is doing a lot of work on purpose): - Start with the user, not the toy. Get unreasonably concrete about real user pain (tickets, observation, “why” drills), and let solutions fall out of that—otherwise you’ll build complexity to justify a preconceived answer. - Engineering is a team sport: alignment beats being right. The job is getting to “right” together: create shared understanding, reduce misalignment (the real cause of “slow” teams), avoid “winning” debates into silent resistance, use metrics carefully (they get gamed), and design process to reduce uncertainty rather than produce paperwork. - Ship early, then iterate—clarity over cleverness. Bias to action: drafts and MVPs teach faster than armchair perfection. Write code and docs that are obvious at 2am during an incident, not “impressive.” And treat novelty as debt you repay in ops/hiring/cognitive overhead—spend your “innovation tokens” where you’re uniquely paid to innovate. - Do less: deletion is a superpower (and often the fastest optimization). Prefer “code you never wrote” (or work you removed) over clever additions. Many performance wins come from removing unnecessary computation, not adding fancy machinery. - Respect scale and failure: compatibility, migrations, and leaky abstractions are the real product. At scale, even bugs become dependencies; deprecations are migrations with empathy/tooling/time. Abstractions don’t erase complexity—they postpone it until on-call—so keep a working mental model of what’s underneath. - Make your impact legible and invest in compounding. Code doesn’t advocate for you—people do—so communicate outcomes, not just activity. Use writing/teaching to force clarity and deepen your own understanding; treat “glue work” as deliberate, bounded, and visible. Build psychological safety by saying “I don’t know.” Maintain relationships because your network outlasts any job. And manage your career like compound interest: protect time, practice deliberately, turn scar tissue into reusable playbooks.
  • bendmorris 10mo ago
    The fixation with AI really harms the signal-to-noise ratio on HN lately. The author of this article very clearly used an LLM to generate much of it, which makes it read like the clickbait you see a ton of on LinkedIn. Then a commenter posts an LLM-generated bullet list summary of the LLM-generated article, which really adds nothing to the discussion. Ultimately the author had some simple ideas that are worth sharing and discussing, but they're hidden behind so much non-additive slop.
• dusted 10mo ago
  > Abstractions don’t remove complexity. They move it to the day you’re on call. Gold.
• oaiey 10mo ago
  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
• DavidPiper 10mo ago
  > 13. The work that makes other work possible is priceless - and invisible. > Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. ... The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact. Timebox it. Rotate it. Turn it into artifacts ... make it legible as impact, not as personality trait. I see my own experience in this, but I don't think he's identified the problem correctly. Timeboxing, rotating, etc, is easy. Convincing management that it is as important as non-glue work and therefore worth allocating your time for it is the hard part. And if you can't do that, you end up stuck in the situation described. The other option is to just let things fail of course, but then you have to convince both management AND the rest of your team to do this, otherwise someone else will just pick it up between the cracks too.
• MarkSweep 10mo ago
  This and the other top story on HN right now ( I charged $18k for a Static HTML Page) [0] make it clear the the most important thing as a software developer is jumping through hoops and being agreeable. It does not matter if it makes sense to you. I’ve come to accept that I can’t always predict what is actually valuable for the business and should just go with the flow and take their money. The leetcode-style interview selects for this by presenting as an arbitrary hoop you have to jump through. [0]: https://news.ycombinator.com/item?id=46469877 https://news.ycombinator.com/item?id=46469877
• deadbabe 10mo ago
  Some people think clarity means abandoning language idioms and writing simple code that a first year computer science student could understand and follow. If you do this, your team will write verbose, repetitive code, and put more emphasis on procedures instead of data structures and how they change over time. Use the language features to write powerful concise code that really takes some skill and expertise in the language to understand. Force your team to become more skilled, don’t stoop down to the lowest common denominator. In time, this code will become as easily understood as any other simple program. And when shit breaks down at 2 AM, you do nothing, because your code is clever enough to handle problems itself. But don’t obfuscate.
• lfliosdjf 10mo ago
  Biggest lesson is you will get mass fired. So look for whats best for you, because you are the only one who can?
• xthe 10mo ago
  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.
• Verlyn139 10mo ago
  most generic advice oat
• ChuckMcM 10mo ago
  That's a solid set of lessons. My favorite is that Software doesn't advocate for you, people do.
• danieltanfh95 10mo ago
  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.
• harrylove 10mo ago
  Love love love this. So much wisdom I wish I’d had 30 years ago. Here’s the tl;dr in my opinion, with my own paraphrase: > Approach [life] with curiosity and generosity, not transactional hustle. Everything else essentially follows.
• badmonster 10mo ago
  [dead]
• jv22222 10mo ago
  > Novelty is a loan you repay in outages If you personally build all (or most) of the stuff, you are in an extreme vertical integration benefit situation. You can make huge system wide changes in ways that would not be possible without having done so much novel work.
• knorke 10mo ago
  very good thoughts. learned a lot of these lessons the hard way over the last 20 years.
• deleted 10mo ago
  [deleted]
• edg5000 10mo ago
  > Before you build, exhaust the question: “What would happen if we just… didn’t?” Well said! So many times I have seen great products slide down. If they just froze the features and UI, and just fixed performance, compatibility and stability issues for years, things would be better. (this applies to any company). Many programs I use are years old. They are great programs and don't need constant change! Updates can only make it worse at that point (minus critical security issues, compatbility, performance regressions)
• ptdorf 10mo ago
  Holy molly! This was a treat to read and should be mandatory to every senior and even management.
• utbabya 10mo ago
  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.
• jsrozner 10mo ago
  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.
  • lionkor 10mo ago
    It just reads like a very expensive AI which is very well prompted. I would love to interview him without his phone to see if he can reproduce even 5 of these points. I'm sure he's a super capable, experienced, and extremely well spoken person. There is no excuse of AI writing outside of writing that pays your bills.
• thayne 10mo ago
  > Abstractions don’t remove complexity. They move it to the day you’re on call. As someone who has been on call a lot, this is only true for bad or incomplete abstractions. When you are on call (or developing) you can't possibly know everything about the system. You need abstractions to make sense of what is going on, how the system as a whole works, and know which parts to hone in on when things go wrong. And it is extremely useful to have standard ways of changing configuration for things like timeouts, buffer sizes, etc. in a central place.
  • oftenwrong 10mo ago
    I don't think it's meant to be a point against abstraction or a point against complexity. I think it's widely understood that abstraction is part of how advancement is made in our practice, as well as in other disciplines. I have taken this saying to be an observation that there is almost always possible failure beneath the façade provided by the abstraction. Therefore, yes, you avoid having to let that complexity enter your brain, but only when the abstraction is holding. Beyond that point, often after pages are sent, you will still have to engage with the underlying complexity. A proactive measure following from this idea would be to provide support in or alongside your abstractions for situations where one must look under the bonnet.
• z3t4 10mo ago
  I agree to both 3) and 8) but I find it a dilemma that if you don't get it perfect the first time, you will waste thousands of man-hours for everyone to upgrade even though it only took you 10 minutes to release the new version.
• ChiNutri20 10mo ago
  [dead]
• YouAreWRONGtoo 10mo ago
  [dead]
• deleted 10mo ago
  [deleted]
• lionkor 10mo ago
  What a mediocre article. Its just enough for people to agree and nod and go "wow yeah true!!" while offering almost zero value to people who don't already agree. These are not useful to juniors. Yes, almost all of this is true and well said, but it offers no additional value. It's like a smell test: Show this article to engineers and those who disagree with lots of points should be given a senior mentor. These points are really good, but they often miss context and further info and caveats. I would have liked if the Author just added a little bit more content. Like, for example, the point about "Being right is cheap. Getting to right together is the real work". Yes, it's certainly true that a decision made in agreement is better than one that isn't. However, how do you get there? Does everyone else give up their (weakly held, according to the article) opinions? I would argue it should be acceptable for your opinions to hold, to be factually based, and still to not align with the final decision made. Any respectable engineer should be fine with this. > Your code doesn’t advocate for you. People do. It depends on how much code you output relative to others, for example, and how performance is measured, how much time is actually spent in meetings (and how much of that is wasted or could-have-been-an-email). I've been told at a previous job that the quality and amount of code I output made them reconsider their entire salary- and bonus-structure (and they did restructure it but by the time it went into effect I had gotten a better offer and left). I just had more programming experience than most other developers there (through open source and my own projects), even though I was junior to most of them. Your code can advocate for you, and so can your general output, your contributions, etc. It's not all politics in all companies, though I'm sure the author's point applies at FAANG. Furthermore, I don't know if this point results in actionable advice for juniors, for example. To not bother writing good code? To not bother with doing the best you can? To not honing your skill and instead go to public speaking courses? I'm not sure. Good-ish article, just not enough novel substance IMO, and reads a bit like AI slop. Also choked on this: > Colleagues often remark on Osmani’s humility and generosity despite his fame in the field.
• scotty79 10mo ago
  Main lesson from 14 years anywhere should be don't spend more than two years at one job. Because otherwise you start thinking that politics matters.
• lasgawe 10mo ago
  These lessons should be learned by every junior engineer and shared with every other engineer. I agree with the point, “Your network outlasts every job you’ll ever have,” that you mentioned. I literally know developers who aren’t actually good at what they do, but they always manage to find another job.
• ph4evers 10mo ago
  This is why AI won’t suddenly fully replace a software engineer.
• aydin212 10mo ago
  #3 hit hard. You can edit a bad page, but you can't edit a blank one. I've wasted weeks overthinking architecture for things I'd never built. Shipping something ugly and learning from real feedback taught me more than any amount of planning. Also #6 is underrated. Early on I thought good work speaks for itself. It doesn't. Took me years to realize decisions happen in rooms I'm not in. If no one can explain your impact when you're gone, it doesn't exist. Thanks for sharing this.
• misja111 10mo ago
  Your post is absolutely golden and it doesn't apply only at Google. I can't remember seeing so many deeply true statements together in one post. I'm sure many here will start to contest some of them but with enough experience they will also realize that the points were true.
• mnmnmn 10mo ago
  [dead]
• vysakh0 10mo ago
  This resonates a lot. The shift from "was I right?" to "does this actually help people?" changes everything. I've found that the engineers who got promoted fastest weren't always the smartest problem solvers, they were the ones who genuinely cared about the end outcome. The hardest part is that user focus is sometimes at odds with technical cleanliness. You can ship something inelegant but useful, or elegant but slightly off from what people need. Most orgs mess this up by choosing elegance.
• swyx 10mo ago
  > 17. Your network outlasts every job you’ll ever have. i mean, addy has literally been at google 14 years, i think internal network has outweighed the external one here
• erkanerol 10mo ago
  My favorite is the first one, "The best engineers are obsessed with solving user problems." and what I hate about it is that it is super hard to judge someone's skills about it without really working with him/her for a very long time. It is super easier said than done. And it is super hard to prove and sell when everybody is looking for easily assessable skills.
  • strgcmc 10mo ago
    This is why (flawed though the process may be in other ways), a company like Amazon asks "customer obsession" questions in engineering interviews. To gather data about whether the candidate appreciates this point about needing to understand user problems, and also what steps the candidate takes to try and learn the users' POV or walk a mile in their shoes so to speak. Of course interview processes can be gamed, and signal to noise ratio deserves skepticism, so nothing is perfect, but the core principle of WHY that exists as part of the interview process (at Amazon and many many other companies too) is exactly for the same reason you say it's your "favorite". Also IIRC, there was some internal research done in the late 2010s or so, that out of the hiring assessment data gathered across thousands of interviews, the single best predictor of positive on-the-job performance for software engineers, was NOT how well candidates did on coding rounds or system design but rather how well they did at the Customer Obsession round.
• river_otter 10mo ago
  The quote "Sorry this letter is so long, I didn't have the time to write a shorter one" (Mark Twain, Blaise Pascal, lots of debate) sticks with me over the years. I appreciated the several points from Addy supporting this idea: when writing code has never been easier and faster, it takes even more time to make sure that the code being written is truly useful and necessary.
• bborud 10mo ago
  Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time. YES! And sometimes that stranger is you, 6 months down the line.
• MORPHOICES 10mo ago
  [dead]
• teleforce 10mo ago
  >The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected This one is golden, it should be framed and put in every engineer's office. >Your network outlasts every job you’ll ever have. Networking is the real human currency, period.
• PeterAnderson 10mo ago
  17. Your network outlasts every job you’ll ever have. Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades. They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years. Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle. When the time comes to move on, it’s often relationships that open the door. Thanks! I used to think writing code was the easiest and most enjoyable thing in the world. Interacting with people? That’s always been the hard part. Guess it’s high time I changed my mindset now.
• AtNightWeCode 10mo ago
  Very good. I agree with most of it. One thing I disagree with is "The senior engineers I respect most have learned to trade cleverness for clarity, every time.". This sounds like the anti-pattern "design for lowest competence" or similar. This is a big trap. A little bit of magic is often better than clarity. Junior devs should learn to follow the rules and how things work without the actual need for deeper understanding.
• daxfohl 10mo ago
  These all jibe with my 25 years of experience (only one at google though). I'll add: * Don't work "off the clock", no matter how strong the urge: There's nothing managers hate more than surprises. Even good ones! If you've got some idea to work on, discuss it and get buy-in early. If you're spending a lot of your own time on something, that means it's probably low-value and you subconsciously know it, or it's stepping on somebody else's toes, or it's something that you're the only one who cares about. Once you're done, all your manager is going to say is "why were you doing that instead of <other higher priority thing>", and if it creates a bug or user complaint or anything else, you'll be on the hook. Save your creativity for personal projects. * Get fast feedback. This kind of relates to the above, but more generally, iterate quickly at every scale. If testing your changes takes more than one button click and a couple seconds, whether compile time, staging deployment time, etc., fix it. Find out how others are automating their dev flows. A tiny bit of improvement here cascades greatly. Get fast feedback on designs: don't spend a ton of time writing a long doc and waiting for approval; send out a 1-paragraph summary or whatever you think the minimum is, get signoff, get done and move on. Do document, but don't overdo it. Get fast feedback on ideas; don't wait until code review time to find out that the team was planning a different direction. Yes, this does kind of suck if you're naturally introverted and prefer just coding, but it's part of the job. * Set an extremely low bar for each day, but meet it. We aren't all superstars all the time. There'll be times when you're burnt out or blocked by something you really don't want to deal with, and making progress can seem overwhelming, so "I'll just surf the web for a while" turns into all day, which can turn into all week or all month of excuses about how little progress you're making, and the anxiety and guilt becomes more overwhelming than even the work. Avoid this by setting an easily achievable goal: a couple lines of code, a quick chat with someone who might know how to unblock one thing, whatever. That way you're not letting the anxiety build, you're not waking up the next day in the same state that you were the previous day, you at least have something to talk about during standup, and it's one less thing to deal with. Oftentimes it creates some momentum, and turns into a fully productive day! But be okay if it doesn't: the goal is just to get that one thing done, and anything else is purely optional: sometimes it's good to have an off day to recharge, so long as you're not starting the next day in the exact same position.
• liaomaos 10mo ago
  Clarity is seniority. Cleverness is overhead. - On a consulting project where the client was building a 5000 user plus application. They had an amazing architect, know all the best frameworks and had implemented that on the project. Issue is, only he understood the framework (even though it's documented on github) and it costed the developers more time to understand the framework than if the code was a little "dumber". Then he left for a better role for his career as he should. Because of that, the devs and new architects abandoned the framework and built new things around it and now the old framework is "tech debt".
• michaelcampbell 10mo ago
  Lots of good stuff here. Literally none of it required working at Google to learn.
• bprasanna 10mo ago
  Thanking the author for "13. The work that makes other work possible is priceless - and invisible."
• inadequatespace 10mo ago
  > 16. Admitting what you don’t know creates more safety than pretending you do. > Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode. It's interesting to contrast this with Sean's statement here www.seangoedecke.com/taking-a-position/ > At that point, you need to take a position, whether you feel particularly confident or not. > If you don’t, you’re forcing people with less technical context than you to figure it out themselves To square the circle, I think the lesson is hide uncertainty to higher-ups, but don't to peers/ other ICs. Of course, the challenge is that often, unfortunately, both the manager and the other ICs are in the same meeting. Probably this is one justification of one reason why I hate meetings that include managers.
• Snowfield9571 10mo ago
  Is this AI? It reads like a conglomerate of hacker news career articles. Am I the only one seeing this?