Lessons from 14 years at Google • Hacker News Board

Re: Lessons from 14 years at Google

#401

Post by dartharva » Mon, Jan 05, 2026, 2:20 AM UTC

soorya3 wrote: post #337

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 toget…

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.

Re: Lessons from 14 years at Google

#402

Post by fragmede » Mon, Jan 05, 2026, 2:20 AM UTC

ohso4 wrote: post #358

0______0 wrote: post #312

Earlier quoted context omitted.

FWIW, the actual apology is well written.

If you run it through originality.ai, you'll see that bits of it are his writing, some is mixed and some is just ai. This blog post everyone is discussing is also written with ai.

lol you believe that site for more than a second?

Re: Lessons from 14 years at Google

#403

Post by danieltanfh95 » Mon, Jan 05, 2026, 2:22 AM UTC

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.

Re: Lessons from 14 years at Google

#404

Post by dartharva » Mon, Jan 05, 2026, 2:24 AM UTC

firefoxd wrote: post #5

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.

The problem with this approach is that once you've started with a "bad" draft and enough people have signed on, you're locked in to its trajectory and can't do foundational rewrites even if you were within the feasible window. It'll just end up being a bad product overall.

Starting right is important.

Re: Lessons from 14 years at Google

#405

Post by matvore » Mon, Jan 05, 2026, 2:24 AM UTC

TacticalCoder wrote: post #73

trescenzi wrote: post #13

> 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, turnin…

Craziest I got was users complaining their laptops were getting too hot / too noisey because I correctly parallelized a task and it became too efficient . They liked the speed but hated the fans going on at full speed and the CPU (and hence the whole laptop) getting really warn (talking circa 2010). So I had to artificially slow down processing a bit as to not make the fans go brrrrr and CPU go too hot.

If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)

This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.

Re: Lessons from 14 years at Google

#406

Post by nchmy » Mon, Jan 05, 2026, 2:24 AM UTC

Sephr wrote: post #287

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 cod…

addy rubs me the wrong way more often than not, but you really gotta let this go friend.

Re: Lessons from 14 years at Google

#407

Post by ehnto » Mon, Jan 05, 2026, 2:26 AM UTC

trescenzi wrote: post #13

> 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, turnin…

I worked on some software that provided results to some calculations to general web users, not experts. The calcs were done in miliseconds.

We had to introduce an artificial delay of ~30 seconds to make it seem like it was taking a while to calculate, because users were complaining that it was too fast. They either didn't believe we really did the calcs, or they thought the system must have broken so they didn't trust the results.

Re: Lessons from 14 years at Google

#408

Post by cm2012 » Mon, Jan 05, 2026, 2:26 AM UTC

taklimakan wrote: post #198

trescenzi wrote: post #13

> 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, turnin…

Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefu…

I have never seen a pure ticket based / zero ownership approach ever work.

Re: Lessons from 14 years at Google

#409

Post by cherioo » Mon, Jan 05, 2026, 2:28 AM UTC

euifii wrote: post #206

spicyusername wrote: post #189

Earlier quoted context omitted.

So teach your kids to kiss ass and play poltiics. Or to stay far away and do something useful with their lives.

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!?

Because that's not how they perceive their works. Instead it is "advocating for one's own team and passion", "helping others advance their career", "networking and building long-term connections".

Re: Lessons from 14 years at Google

#410

Post by nchmy » Mon, Jan 05, 2026, 2:32 AM UTC

dclowd9901 wrote: post #362

zhouzhao wrote: post #307

Earlier quoted context omitted.

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.

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).

just because people think or feel things, doesn't make those things valid (and certainly not prudent)