Lessons from 14 years at Google • Hacker News Board

Re: Lessons from 14 years at Google

#591

Post by rswail » Mon, Jan 05, 2026, 10:59 AM UTC

rictic wrote: post #450

elmomle wrote: post #434

Earlier quoted context omitted.

That's a highly idealized view that I hope we can agree doesn't completely jive with what we see in society today. If a small number of shareholders reap all the profits, the vast majority of the benefit from automation flows to them, and it's even possible for the lives of average people to get worse as automation increases, as average people then have less leverage over those who own the companies.

Inflation adjusted incomes are up in the US across the board. The affordability problem is largely the price of housing because it's illegal to build.

Incomes are up, but the expenses are up as well, especially with the upcoming changes in healthcare for people on the ACA.

Also any comparison of wage growth vs corporate profit growth over the last 30 years shows that wages have not kept pace with the increase in productivity.

So incomes are only just barely keeping up, when they should be booming.

Re: Lessons from 14 years at Google

#592

Post by einpoklum » Mon, Jan 05, 2026, 11:05 AM UTC

mattacular wrote: post #413

simonw wrote: post #10

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

Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)

If - to take a convenient example - I use a library sorting function instead of writing my own sorting code, it's true that I haven't removed the complexity of the work my program is doing: It sorts. But I have arguably reduced the complexity of my code.

Similarly, if I factor out some well-named function instead of repeating the same sequence actions in multiple places - the work to be done is just as complex, and I haven't even removed the complexity from my code, but - I have traded the complexity of N different pieces of code for 1 such piece plus N function calls. Granted, that tradeoff isn't always the right thing to do, but one could still claim that, often, that _does_ reduce the complexity of the code.

Re: Lessons from 14 years at Google

#593

Post by rswail » Mon, Jan 05, 2026, 11:06 AM UTC

eru wrote: post #515

elmomle wrote: post #434

Earlier quoted context omitted.

That's a highly idealized view that I hope we can agree doesn't completely jive with what we see in society today. If a small number of shareholders reap all the profits, the vast majority of the benefit from automation flows to them, and it's even possible for the lives of average people to get worse as automation increases, as average people then have less leverage over those who own the companies.

Everybody can be a shareholder in a publicly traded company. It's pretty easy. If you want to spin up some conspiracy theory about elites snatching up productivity gains, you should focus on top managers. (Though honestly, it's mostly just land. The share of GDP going to capital has been roughly steady over the decade. The share going to land has increased slightly at the cost of the labour share. The labour share it…

Everyone with excess disposable income can be a shareholder in a publicly traded company.

The oligarchy of the CxOs and boards and cross-pollination has led to concentration of the rewards of companies into the their hands, compared to 40 years ago.

All the productivity gains have not gone to labor, its predominately gone to equity and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.

The craziness of the USG borrowing to fund tax cuts is the ultimate example.

Re: Lessons from 14 years at Google

#594

Post by rswail » Mon, Jan 05, 2026, 11:10 AM UTC

brunoborges wrote: post #422

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…

> 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. You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".

Everyone in the team should have that.

Obviously at different levels of focus and completeness, but the Product Manager is supposed to be communicating in both directions and they rarely do, they just take the feature list and tick them off.

Telling the customer that they can't have something or it needs to be different and having their trust that you aren't doing it just to cut corners is what good Product Managers do.

Re: Lessons from 14 years at Google

#595

Post by rswail » Mon, Jan 05, 2026, 11:15 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…

Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements.

The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers.

It's up to the developers and designers to understand those constraints and make sure they are communicated back.

Re: Lessons from 14 years at Google

#596

Post by rswail » Mon, Jan 05, 2026, 11:19 AM UTC

anhner wrote: post #523

taklimakan wrote: post #198

Earlier quoted context omitted.

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…

It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day. Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make…

They should have a general idea of what they are building and why, in exactly the same way as a construction worker.

That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction.

Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.

Re: Lessons from 14 years at Google

#597

Post by rswail » Mon, Jan 05, 2026, 11:21 AM UTC

anhner wrote: post #523

taklimakan wrote: post #198

Earlier quoted context omitted.

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…

It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day. Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make…

The other argument about this is whether or not an SWE is a fungible resource.

When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another.

We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.

Re: Lessons from 14 years at Google

#598

Post by leoc » Mon, Jan 05, 2026, 11:26 AM UTC

simonw wrote: post #10

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

Like most of the things Spolsky says in that article it’s pretty dubious. Following it to its logical conclusion, presumably on-call debugging work be even easier if the software had been handwritten in assembler.

Re: Lessons from 14 years at Google

#599

Post by rswail » Mon, Jan 05, 2026, 11:26 AM UTC

Gigachad wrote: post #487

wahnfrieden wrote: post #387

Earlier quoted context omitted.

Why would the boss accept that? They automated the work to eliminate employee downtime. If the employees were upset to lose their chatting time then presumably they lack the agency to choose chatting over work duties when they’re unblocked. The only way to help them in that situation is to organize them

Because the 10 minutes of chatting has value too. Which is why corporations make you spend so much time on team building exercises and axe throwing.

No, that's HR justifying its existence.

Plus that's for higher stature service based roles, not warehouse logistics.

It's also mostly bullshit.

Teams work because they have the right combination of skills, both personal and technical, high EQ and IQ, leadership and ownership.

Whether or not you fall backwards into a team's arms or have to participate in childish games is not relevant.

Re: Lessons from 14 years at Google

#600

Post by nchmy » Mon, Jan 05, 2026, 11:30 AM UTC

croemer wrote: post #306

mgrat wrote: post #194

Earlier quoted context omitted.

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.

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/

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!