Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

531–540 of 732 posts

Re: Lessons from 14 years at Google

#531

Earlier quoted context omitted.

This says a lot as relating to the rise of AI and the fear of job loss. There's going to be displacement in areas we can't predict, but overall it might very well just lead to leveling up the entire workforce.

> it might very well just lead to leveling up the entire workforce. How could that possibly work? At some point I could see white collar work trending down fast, in a way that radically increased the value of blue color work. Software gets cheaper much faster than hardware. But then the innovation and investments go into smart hardware, and robotics effectiveness/cost goes up. If you can see a path where AI isn't a o…

Craftsmen will have a resurgence, that's probably a 'leveling up' in terms of resilience against AI takeover. There's just no way of automating quite a few of the physically effective crafts.

Re: Lessons from 14 years at Google

#532
post #494

Earlier quoted context omitted.

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.

Not at all. Most people can be super happy with less than the average tech salary (at a point where they don't feel they need more if it comes at the expense of work life balance, time with family, job satisfaction, etc).

I’ll never understand this WHY X - BECAUSE Y - WELL Y IS TOO MUCH, Z IS MORE THAN ENOUGH comment trifecta. Obviously a lot of people are not super happy, otherwise they wouldn’t kiss asses and play politics to get more money.

Re: Lessons from 14 years at Google

#533
post #107

I feel like the best lesson in here wasn’t numbered, but in the opening statement: > the longer I’ve stayed, the more I’ve realized that the engineers who thrive aren’t necessarily the best programmers - they’re the ones who’ve figured out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity. I have been banging on about this for _years_. I’ve seen engineers much smarter…

I manager that invites people in meeting based on how obedient they are, is a bad manager. Multiplied by the number of reports. Fix that.

I didn’t mention obedience, I mentioned pleasantness. Not sure what you’re on about with reports either. You ok?

Re: Lessons from 14 years at Google

#534

> 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 is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly. Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.

Re: Lessons from 14 years at Google

#535

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…

Yeah the bar for competent is surprising hard to hit. A human being that shows up on time and it's reliable, doesn't have a problem with drugs or alcohol, or has a sick family member and just needs an advance. Good help is hard to find!

I understand the rest, but an otherwise capable person with a sick family member does not clear the bar for competent? Saddening if that’s where we are as a society.

Re: Lessons from 14 years at Google

#536
post #407

Earlier quoted context omitted.

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.

I often chuckle when (our) animations may have more complex math that consume more resources than the awaited logic/call that they gate.

Re: Lessons from 14 years at Google

#537

Earlier quoted context omitted.

Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. I think there are multiple reasons for this, but they are mostly overlapping with preserving internal power structures. PM's don't want anecdotal user evidence that their vision of the product is incomplete. Engineering managers don't want user feedback to undermine perception of quality and derail "i…

Engineers have a perception that most other roles are lesser and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where…

Agree that this can be an issue but to clarify, I was finding bugs or missed outages, not gathering feature requests or trying to do product dev. Think "I clicked the button and got a 500 Server Error". I don't think random devs should try and decide what features to work on by reading user forums - having PMs decide that does make sense as long as the PM is good. However, big tech PMs too often abstract the user base behind metrics and data, and can miss obvious/embarrassing bugs that don't show up in those feeds. The ground truth is still whether users are complaining. Eng can skip complaints about missing features/UI redesigns or whatever, but complaints about broken stuff in prod needs their attention.

Re: Lessons from 14 years at Google

#538

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.

I think it depends on the team.

Some teams I’ve been in, we could go “this is shit, we must be doing this wrong” and we’d go back to the drawing board without blinking.

Other teams, just getting _something_ going, even if it was garbage, was a enormous achievement, and saying it was bad and that we should start again would be a recipe for disaster.

Re: Lessons from 14 years at Google

#539

Earlier quoted context omitted.

Well, the 101 idiom comes from US education, it's a reference to the introductory course. Part of the problem with anti-abuse work is that there's no course you can take and precious little inter-firm job hopping. Anti-abuse is a cost of business so you don't see companies competing over employees with experience like you do in some other areas like AI research. So it's all learning-by-doing and when people leave, th…

I seem to recall sitting in weekly abuse team meetings where one of the metrics was the price of a google account on the black market. So at least some of these things were tracked and not just by one individual.

Yes, I think me and the other guy I referred to started that practice ;)

Re: Lessons from 14 years at Google

#540

Earlier quoted context omitted.

Yeah the bar for competent is surprising hard to hit. A human being that shows up on time and it's reliable, doesn't have a problem with drugs or alcohol, or has a sick family member and just needs an advance. Good help is hard to find!

I understand the rest, but an otherwise capable person with a sick family member does not clear the bar for competent? Saddening if that’s where we are as a society.

It’s hard for some people to understand that situation until they are in it. Unfortunately.

Totally agree with you.

Post reply on HN