Lessons from 14 years at Google • Hacker News Board

Re: Lessons from 14 years at Google

#601

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

dartharva wrote: post #401

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.

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.

Re: Lessons from 14 years at Google

#602

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

astrange wrote: post #425

TacticalCoder wrote: post #73

Earlier quoted context omitted.

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.

You probably wanted a low thread priority/QoS setting. The OS knows how to run threads such that they don't heat up the CPU. Well, on modern hardware it does anyway.

The OP did say this was circa 2010. So we're talking 15 years ago.

Re: Lessons from 14 years at Google

#603

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

If upvoting doesn’t require justification neither should downvoting.

But let me try to express why people disagree. Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be.

The “brick-laying” part of software isn’t the hard part. Depending on want to analogise as “brick-laying” in software, that part could automated. Push to main and the deployment pipeline runs tests, makes sure things are working and voila! You have a new “house”. If its ugly or falls apart in software, easy , just revert to the previous version and its like nothing happened. Client wants a try different layout, it can be done affordably.

Most of the time in software engineering you don’t know exactly how to do something, there is always a degree of discovery, experimentation and learning involved. Heck the client probably isn’t expressing what they want clearly enough, and probably will at some point change their mind. Thus interacting with clients and customers is valuable.

Re: Lessons from 14 years at Google

#604

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

rahimnathwani wrote: post #546

Aurornis wrote: post #110

Earlier quoted context omitted.

> 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 One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk. I assume…

The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. Imagine you like writing code, and someone automates that part of the job so you have to spend more of your time reviewing PRs and writing specs...

I don’t even have to imagine it, you just described my job now that we have LLMs.

Re: Lessons from 14 years at Google

#605

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

nchmy wrote: post #406

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.

Oh my god. I have never seen an about/bio page even half as gross and cringey as his.

https://addyosmani.com/bio/

It's so obscene that it seems like it's a parody

> Colleagues often remark on Osmani’s humility

LOL! Who writes these things about themselves with a straight face?!

It also shows that taking credit for others' work is 100% his MO.

> Osmani’s team created Workbox, a set of libraries for generating service worker scripts that handle caching and offline functionality with minimal fuss. Workbox simplified what used to be a complex task of writing low-level code to intercept network requests.

No, Jeff Posnick (who I suppose technically was on addy's team) created workbox and it has been basically abandonned since he left Google. Or was it Sundar Pichai's team who made workbox? Or does Brendan Eich deserve the credit?

I have to assume the rest of the bio, and his career, has been built off of usurping credit. He always rubbed me the wrong way, and this vindicates that sense.

What a psychopath!

Re: Lessons from 14 years at Google

#606

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

toxik wrote: post #562

yobbo wrote: post #392

Earlier quoted context omitted.

> It is by far the most useful skill to have in workplace. This might be defacto true in most workplaces, but defending "politics over competence" boils down to "I deserve the rewards from other people's work". People oppose it because it is morally wrong, not because they think it is an inaccurate description of reality.

You say that as if politics is optional. It isn't, decisions need to be made and politics is the process of making those decisions: who decides, and why. In academia, for example, there is less politics because the publishing system sort of becomes the decision process. You apply with your ideas in the form of papers, the referees decide if your ideas are good enough (and demonstrated well enough) for the wider audie…

With this understanding of academia, you are perfectly suited to doing software development for them, because if you think there is "less politics" in academia, you are being foolish.

Academia is notorious for politics, especially around tenure and grants, scholarships, etc.

Publication politics are just a small part of that, but even there, working out which name goes in what order of the authorship of the paper is political.

Re: Lessons from 14 years at Google

#607

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

[dead]

Re: Lessons from 14 years at Google

#608

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

Jean-Papoulos wrote: post #513

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…

>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. While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineerin…

If it’s impossible to understand users problems then something has gone horribly wrong.

Re: Lessons from 14 years at Google

#609

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

This list really stands out because it treats engineering as more than just producing correct code. It focuses on producing clarity that others can build on. The idea that clarity matters more than cleverness isn’t about style. It’s about reducing risk when someone else has to fix or extend the code at an odd hour. That’s often the difference between technical efficiency and the contribution a team can reliably depend on.

Re: Lessons from 14 years at Google

#610

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

AlotOfReading wrote: post #447

matvore wrote: post #405

Earlier quoted context omitted.

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…

Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy: chrt -i 0

  > Obviously the proper solution is to adjust your system thermal management / power targets,

My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway.

I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.