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

421–430 of 732 posts

Re: Lessons from 14 years at Google

#421

Post by drnick1 »

fwip wrote: post #317
haunter wrote: post #193

Earlier quoted context omitted.

Because if you don’t like the UX you just edit the source code yourself and make it better /s /s but I wish it wasn’t because a lot of FOSS evangelists have this mindset (here on HN too)

More seriously - open source software is resistant to enshittification. It's obviously not a panacea, but the possibility of forks (or just the user deciding not to update), combined with the difference in profit motive, tends to result in software that respects the user. (Taken holistically, the UX of software does not just mean the UI, or the moments when you are using the software. It also includes the stability o…

This. The only real risk with open source is that a (fairly niche) project is discontinued/abandoned, and you can't find binaries anymore for it anymore (and you don't have the skills to build it yourself). But this happens to proprietary software all the time (see killedbygoogle.com).

Re: Lessons from 14 years at Google

#422

Post by brunoborges »

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

Re: Lessons from 14 years at Google

#423

Post by hyperadvanced »

jaredsohn wrote: post #357
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…

Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things. If you just implement product tickets you'll probably get replaced by LLMs.

It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago

Re: Lessons from 14 years at Google

#424

Post by astrange »

ehnto wrote: post #407
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 trus…

This is one reason UIs have animations added, the kind that technical users like to complain about or remove. By making things feel more physically grounded they prevent users from getting lost and confused and give them more intuition about things.

In your case you could show more intermediate values, graph things, etc.

Re: Lessons from 14 years at Google

#425

Post by astrange »

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.

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.

Re: Lessons from 14 years at Google

#426

Post by astrange »

BLKNSLVR wrote: post #373
H8crilA wrote: post #350

Earlier quoted context omitted.

You need to have the right personality. Either actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort. We don't get to choose our personalities, though some limited modifications are possible - see treatments for personality disorders, for example.

> actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort Ie. Somewhat serious mental disorders as requisite for leadership. I wonder how we got onto this darkest timeline?

If it's adaptive it's not a disorder.

Re: Lessons from 14 years at Google

#427

Post by anon84873628 »

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

Well you can "work to live" in a nice big house, with a nanny, eating steaks, flying business class to ski in the alps or scuba in the Galapagos... I think it takes a lot of money before you feel like you don't need more money.

Re: Lessons from 14 years at Google

#428

Post by astrange »

anonymars wrote: post #95
sdenton4 wrote: post #84

Earlier quoted context omitted.

When you're not shipping, you're not learning from users. As a result, it's easy to build working, correct, performant code which doesn't fit what anyone actually needs.

I think you can also learn from users when they complain en masse about the current atrocious state of software quality. But I guess that doesn't show up in telemetry. Until it does. Looking at you, Microsoft!

You can't learn from this because users always complain no matter what.

The trick is they just complain about the last thing they remember being bad, so it's a good sign when that doesn't change, and it's bad if they start complaining about a new thing.

Re: Lessons from 14 years at Google

#429

Post by kamranjon »

euifii wrote: post #418
kamranjon wrote: post #399

Earlier quoted context omitted.

You posted the code to a public blog page, with no attribution in the code or request of attribution from others, no license, and seemingly intended to share it freely with the world. Then you got an apology, and a second apology. I'm confused about what you think you're owed? The explanation makes perfect sense, the headers were obviously just copied with no malicious intent. What is it that is still bothering you a…

> no license, and seemingly intended to share it freely with the world No license means you don’t intend to share it “freely”, since you didn’t share any rights. By default, you don’t own things people shared on the internet just because it’s there. That being said I’ve even seen people with licenses in their repos who get mad when people used their code, there’s just no telling and it’s best to just treat random sou…

I'm curious if you would have the same opinion about code shared on stack overflow?
Post reply on HN