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

611–620 of 732 posts

Re: Lessons from 14 years at Google

#611

Post by tonyedgecombe »

vbezhenar wrote: post #354
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…

One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.

I had that on my very first project. I couldn’t understand why the people on site were so hostile to me. Afterwards I was talking to the salesman about this and he told me they were all fired when the project went live.

Re: Lessons from 14 years at Google

#612

Post by einpoklum »

Sprotch wrote: post #518
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.

It’s not politics over competence. It’s getting things done in the real world

(Every gang leader and dictator ever): That's right!

Re: Lessons from 14 years at Google

#613

Post by Orphis »

kiwijamo wrote: post #279
dijit wrote: post #240

Earlier quoted context omitted.

> I’d take [teams] over Google Meets What? Why? Honestly your entire comment is almost exact polar opposite to how I feel. GCP Makes total sense if you know anything about systems administration, Google docs is limited for things like custom fonts (IE; not gonna happen) but it's simple at least and I can give people a link to click and it's gonna look the same for them. But, honestly, the Teams one is baffling. I can…

I've used Meet a few times for video calls and I was amazed at how poorly it worked given the amount of resources Google has at their disposal. I've never had a good video call on Meets. I've had a few Meet calls where over time the resolution and bitrate would be reduced to such a low point I couldn't even see the other person at all (just a large blocky mess). Whereas Teams (for all its flaws) normally has no major…

As someone who worked on Meet at Google, it seems that it could have been networking to the datacenters where the call is routed from, some issues with UDP comms on your network which triggered a bad fallback to WebRTC over TCP. Could also have been issues with the browser version you used.

Since Teams is using the very old H264 codec and Meet is using VP8 or VP9 depending on the context, it's possible you also had some other issues with bad decoding (usually done in software, but occasionally by the hardware).

Overall, it shouldn't be representative of the experience on Meet that I've seen, even from all the bug reports I've read.

Re: Lessons from 14 years at Google

#614

Post by rswail »

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?

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

Re: Lessons from 14 years at Google

#615

Post by RamblingCTO »

embedding-shape wrote: post #124
RamblingCTO wrote: post #109

Earlier quoted context omitted.

And material UI is still the worst of all UIs. Had the pleasure of rolling out a production oauth client ... jesus christ. Only worse is microsoft in UX. You don't want me to use your services, do you?

> And material UI is still the worst of all UIs I'm not sure how that got approved either, but at least we now know what would happen if a massive corporation created a UI/UX toolkit, driven only by quantitative analytics making every choice for how it should be, seemingly without any human oversight. Really is the peak of the "data-driven decisions above all" era.

What makes me wonder even more: why is this still in place? Someone must've noticed themselves when using it

Re: Lessons from 14 years at Google

#616

Post by einsteinx2 »

Scubabear68 wrote: post #86

> 1. The best engineers are obsessed with solving user problems. The author lost me right here. Not because he’s wrong about this in general - he is not. But it seems to not be any kind of differentiator at Google. Maybe the opposite is true- make it as screwed up as physically possible, then make it a little worse, then release it - that seems a lot closer to the lesson Google engineers learn. As long as you are “fi…

Technically he said these are lessons he learned after working at Google, not that Google was necessarily doing these things. If we’re being generous maybe he learned this by counter example haha

Re: Lessons from 14 years at Google

#617

Post by intended »

lazylizard wrote: post #552
rahimnathwani wrote: post #546

Earlier quoted context omitted.

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

efficiency is the enemy of employment, no?

There’s many praises to sing about efficiency, (and I don’t take your 1 liner as a position against it). That said, efficiency, job creation, and underemployment overlap quite a bit.

There’s far more scientists, programmers, and doctors today than farmers and stablehands.

At the same time, people who lost manufacturing jobs to automation and outsourcing, did not get jobs with equivalent pay and growth.

Human brains do not get retrained very easily, and so every technological revolution is a boon to those who grasp it, and a challenge for those who invested their time in skills no longer in demand.

Re: Lessons from 14 years at Google

#618

Post by vysakh0 »

This resonates a lot. The shift from "was I right?" to "does this actually help people?" changes everything. I've found that the engineers who got promoted fastest weren't always the smartest problem solvers, they were the ones who genuinely cared about the end outcome.

The hardest part is that user focus is sometimes at odds with technical cleanliness. You can ship something inelegant but useful, or elegant but slightly off from what people need. Most orgs mess this up by choosing elegance.

Re: Lessons from 14 years at Google

#619

Post by sd9 »

einsteinx2 wrote: post #604
rahimnathwani wrote: post #546

Earlier quoted context omitted.

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.

I believe that was the point

Re: Lessons from 14 years at Google

#620

Post by _heimdall »

wafflemaker wrote: post #467
vbezhenar wrote: post #354

Earlier quoted context omitted.

One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.

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…

Why do the laws exist if its better for (almost) everyone involved? Without the laws why would people not do it that way if its the better approach?
Post reply on HN