Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

Post reply on HN
Print view View original

641–650 of 732 posts

Re: Lessons from 14 years at Google

#641

Post by aws_ls »

j3s wrote: post #96

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…

Yep. I too felt that. The insights seem genuine. But probably fell into the temptation to use LLM to structure. I feel increased cognitive load with numbered lists, thanks to LLM.

Re: Lessons from 14 years at Google

#642

Post by SJMG »

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

What a great comparison; I've never thought of it this way. It's obviously not perfect since the automation is so temperamental shall we say, but this does give me more empathy for the countless workers whose jobs have been re-natured by technology.

Re: Lessons from 14 years at Google

#643

Post by botanrice »

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

I question this every single day. Constantly the argument arises that if I played politics and ass-kissed, I might receive more opportunities to create bigger impact to help people / entertain people / provide some valuable service or product. Yet it feels painful to have to self-promote (even if framing it as "documentation of your work").

It is akin to musicianship in a sense. How many of the absolutely, obscenely, most talented musicians have you come across in completely obscured settings? At the pub, the hole-in-the-wall jazz club in a C-tier city, deep on the internet with 13 plays on SoundCloud. But we all know that pop music doesn't necessarily reward technical musicianship.

It's similar in life & career.

Re: Lessons from 14 years at Google

#644

Post by cm2012 »

mangamadaiyan wrote: post #590
cm2012 wrote: post #408

Earlier quoted context omitted.

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

Tell us you've never worked in a faang without telling us.

It doesnt work in faang either, which is why they are wildly slow to produce software. They can just print money when running at 10% efficiency.

Re: Lessons from 14 years at Google

#645

Post by nickjj »

rswail wrote: post #588
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…

Worked on public transport ticketing (think rail gates and stuff) with contactless last 30 years, when guys would tell me that the software was "ready", I'd ask: > Is it "stand next to the gates at Central Station during peak time and everything works" ready? We were working on the project from a different city/country, but we managed to cycle our developers through the actual deployments so they got to see what they…

> "People travel on public transport to get somewhere, not to interact with the ticketing system."

I really like this line because it applies to so many things we build.

Public transport is an interesting one because it applies to so many things. If you need to use it but can't depend on it, it's a huge stress creator and time waster. Suddenly you need to pad times by hours to ensure you don't miss your appointment.

Notice the words there, "miss appointment" and not "miss bus or train". The outcome is what matters, not the transport mechanism.

Or, maybe you're traveling in a foreign country. Having every car in the metro display the line in a digital way showing the previous stops, current location and next stops in English is huge for eliminating doubt. Having the audio in multiple languages and clear is important too because maybe you're sitting down and everyone is standing in front of you so you can't see the display clearly. Having a non-digital map as a backup on the wall in case there's a hardware failure is a good idea too.

Thinking "no one needs any of that waste because they can just use their phone" is the wrong mode of thinking. Maybe there's no service because you're underground or maybe that person's eSIM isn't hooked up yet or isn't working. These are real problems.

The travel experience outcome in the grand scheme of things matters a lot. It could mean having a smooth trip or a questionable experience. It could be the difference between recommending the country to your friends and family or not. Suddenly it affects tourism rates at a global scale. Maybe not a lot, but it has an impact.

Re: Lessons from 14 years at Google

#646

Post by pif »

zwnow wrote: post #544
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…

Yup same story here, also warehouse optimization. I was the reason the employees got new scanners and oh my... the scanners didn't have a physical keyboard. Now all the 50yo+ would have to aim on a touch display which is apparently impossible. Also we had to introduce some fixed locations and storage placement recommendations. Our storage workers almost revolted. After a few months it settled though.

Yous story is not about optimization: it is about change imposed to people who did not request it, nor felt the need of it.

Re: Lessons from 14 years at Google

#647

Post by pif »

Aurornis wrote: post #110
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…

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

Mandatory reference: https://thedailywtf.com/articles/Classic-WTF-The-Indexer

Re: Lessons from 14 years at Google

#648

Post by ghaff »

rswail wrote: post #614
throwaway2037 wrote: post #503

Earlier quoted context omitted.

Wiki ( https://en.wikipedia.org/wiki/Linux_kernel_version_history#O... ) tells me that version 2.4 was released in early 2001. That is a long time ago. Most of the commercial world was running SunOS, Solaris, HP-UX, or AIX. So is it fair to say that the Linux kernel has been "quality" for 25 years now?

2001 was immediately post dotcom crash and so all the people that had bought into the Sun "the network is the computer" were tossing out expensive E4Ks, and getting cheap intel servers to survive. HP-UX and AIX were already legacy. Linux 2.4 was when it hit critical mass because of the publicity of the dotcom boom and it was like what was left after the "tide went out and the market found out who was swimming naked".

Certainly. The 2.4 kernel and IBM embracing Linux at around that time pretty much made all proprietary Unix legacy.

The desktop took longer with less well-defined transition points and, arguably, MacOS with its BSD foundations (and command line option) ended up being a good alternative for a lot of the non-Windows crowd--though Windows is still dominant as a desktop/laptop OS. (Windows/Azure are, of course, still major in backend corporate environments as well.)

Re: Lessons from 14 years at Google

#649

Post by red-iron-pine »

rincebrain wrote: post #519
wafflemaker wrote: post #467

Earlier quoted context omitted.

In Norway there's laws for that, but other places do it even without them. You just retrain the person to do something else. He might take a job of a temp that was hoping to get a fast contract (instead of a few weeks at a time during trial period). Other than that, it's good for the person (not losing job) but also for the company - you get a tried person with good work ethics that comes on time. It's not zero cost…

A lot of places in the US are not, in my experience, that intelligent about hiring people. Or, say rather, the externalities of the cost of hiring are not imposed on the people choosing to fire, directly, so they can say they "improved efficiency" by firing someone, and then the people trying to find reliable labor do not experience any improvement that might have been available by migrating the person.

agreed. the "lump of labour" fallacy is a thing -- the idea that there are always more bodies and that it's trivially easy to hire, train / get up to speed, and work them.

in practice hiring and firing is expensive and often very risky. Bjorn the office worker may now be redundant and have a room temperature IQ but he's shown he'll show up on time, sober, and is liked by his coworkers enough, so throwing $5k to retrain him may be a far, far smarter investment then blowing $7k to hire a rando for another position...

Re: Lessons from 14 years at Google

#650

Post by ghaff »

throwaway2037 wrote: post #503
ghaff wrote: post #155

Earlier quoted context omitted.

It did in the early days, especially up until 2.4 which was generally considered the first enterprise-ready kernel version. (You can argue about whether the old "enterprise-capable" definitions still applied but they were a benchmark for a lot of people.) Of course, lots of ancillary stuff too in userspace and outside the kernel related to filesystems and the like.

Wiki ( https://en.wikipedia.org/wiki/Linux_kernel_version_history#O... ) tells me that version 2.4 was released in early 2001. That is a long time ago. Most of the commercial world was running SunOS, Solaris, HP-UX, or AIX. So is it fair to say that the Linux kernel has been "quality" for 25 years now?

Quality by the standards at the time or at least a good value for most purposes. Yes.
Post reply on HN