alt Hacker NewsLessons from 14 years at Google
Comments
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.
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-...
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.
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.
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/
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.
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.
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.
Thanking the author for "13. The work that makes other work possible is priceless - and invisible."
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.
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.
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.
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.
> 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.
Best part of the article?
> but coordination costs grow geometrically
Using geometrically instead of exponentially! Thank you!!! :-D
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 :/
Lots of good stuff here. Literally none of it required working at Google to learn.
> Abstractions don’t remove complexity. They move it to the day you’re on call.
Gold.
> 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.
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
Reading this makes me so happy I'm not at google anymore
Interview voice:
- How do you actually grow being in one company for 14 years?
> 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”
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.
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.
Biggest lesson is you will get mass fired. So look for whats best for you, because you are the only one who can?
Holy molly! This was a treat to read and should be mandatory to every senior and even management.
That's a solid set of lessons. My favorite is that Software doesn't advocate for you, people do.
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.
This is why AI won’t suddenly fully replace a software engineer.
> Focus on what you can control. Ignore what you can’t.
That's why I left Google for HFT. Much better life.
> 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.
Insightful take on career progress. Most engineers don't talk about this.
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.
#12 is so simple yet so true. Great list thanks for sharing.
Wish I'd read this before I started at Google.
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.
very good thoughts. learned a lot of these lessons the hard way over the last 20 years.
Thank you for sharing this. Well articulated.
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.
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
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.
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.
> 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
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