Earlier quoted context omitted.
> If a small number of shareholders reap all the profits It's not greater profits but lower costs (and prices) that matter here.
Lower costs only translate into lower prices if sufficient competition is there. That is not true for many markets
Lessons from 14 years at Google
491–500 of 732 posts
Re: Lessons from 14 years at Google
#492Thought occurred to me to throw this at ChatGPT 5.2: Given the article at https://addyosmani.com/blog/21-lessons/ , find a short list of points which summarizes and touches on all of his lessons Answer: Here’s a short “umbrella list” that still covers all 21 lessons (each bullet is doing a lot of work on purpose): - Start with the user, not the toy. Get unreasonably concrete about real user pain (tickets, observation…
Ultimately the author had some simple ideas that are worth sharing and discussing, but they're hidden behind so much non-additive slop.
Re: Lessons from 14 years at Google
#493Earlier quoted context omitted.
> If a small number of shareholders reap all the profits It's not greater profits but lower costs (and prices) that matter here.
Lower costs only translate into lower prices if sufficient competition is there. That is not true for many markets
Would you rather sell one widget for $1000 or 1000 widgets for $10? Does the answer depend on costs?
Re: Lessons from 14 years at Google
#494Earlier quoted context omitted.
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
#495Re: Lessons from 14 years at Google
#496> 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…
Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore.
The IBM PC was frustrating to many hardware engineers, as too much software relied on timing loops and delays in the original design, which made it difficult to make the hardware go faster.
Re: Lessons from 14 years at Google
#497Earlier quoted context omitted.
I was curious what the commenter's business was, and found this post about HTTP protocol latency: https://jacquesmattheij.com/the-several-million-dollar-bug/
What a cool guy https://jacquesmattheij.com/domains-for-sale/
Yeah that's not gonna work nowadays.
>DOWNLOADWEBCAM.COM
Is that like Download More RAM?
>BROWSEHN.COM
Hey, I'm browsing that place right now!
>MUZICBRAINZ.COM
This sounds 100% legit no virus softpedia guaranteed.
Re: Lessons from 14 years at Google
#498Re: Lessons from 14 years at Google
#499> 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 spent good amount of time cleaning up 15 year old codebase and removed almost 10MB of source code files which was being part of production build and it was never used. This helped reduce the build time.
I thought I'd get appreciated from everyone in the team, but it was never acknowledged. In fact my PM was warried and raised an alarm for regression. Even though I was 100% confident that there would not be any regression, the QA and PM got annoyed that I touched a working software and they had to do extra work.
I then posted on LinkedIn about this achievement to get my share of appreciation. :)
Re: Lessons from 14 years at Google
#500> 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 negative responses from clients were instant. Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore. The IBM PC was frustrating to many hardware engineers, as too much software re…
Many people decided to improve this with a semiconductor voltage regulator, which would nail the output at 5V. But the instruments wouldn't work! The problem turned out to be the instruments relied on the noisy 5V to "unstick" the needles on the instruments.
So the electronics guys had to add a "noise" circuit to the voltage regulator circuit.
P.S. Watch an old aviation movie, where the pilot getting ready to fly would tap the instruments to unstick them.