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

661–670 of 732 posts

Re: Lessons from 14 years at Google

#661

Post by wafflemaker »

_heimdall wrote: post #620
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…

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?

Norway has very strict pro-workers laws in general, it's just one facet of them. One Norwegian explained it to me like that: in the late '60 when Norwegian oil industry started developing, workers realized that they can incur great losses on the companies if they organize/unionize and strike together. They used that as a leverage to both change their contracts (to include paid sick leave and such) and also get better working conditions (Norwegian platforms have both better safety and on platform to on land ratio).

And later other trades did the same. Some of the things in contracts trickled down to the law. But still some laws apply only to companies where at least a certain % (is it 50%?) are unionized.

The general picture is more or less like that, but please verify the details.

Re: Lessons from 14 years at Google

#662

Post by AlotOfReading »

matvore wrote: post #610
AlotOfReading wrote: post #447

Earlier quoted context omitted.

Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy: chrt -i 0

> Obviously the proper solution is to adjust your system thermal management / power targets, My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway. I did solve thi…

    The proper solution for non-technical people is to ask the expert to fix it
This isn't something the developer has any meaningful control over. Scheduling policy is the responsibility of the host system, running faster usually consumes less power, and the developer has no way to know when an operation will kick in the undesirable fans because it depends on what else the system is running. The best they can do is a checkbox that runs the old code or adding sleep calls instead

Re: Lessons from 14 years at Google

#663

Post by anthonypasq »

dclowd9901 wrote: post #371
naijaboiler wrote: post #259

Earlier quoted context omitted.

we are human being interacting with other human beings. what you call "kissing ass" is just learning to influence and work with other humans. It is by far the most useful skill to have in workplace. But don't worry. continue your disdain of it, includeing calling it negative names, and watch your career stagnate.

I've literally never had the thought of "how do I influence other people." Why is that considered a valuable skill? It just sounds like a nicer version of "manipulation".

trying to make a convincing argument about anything is "influencing" people. its manipulation if you are trying to convince someone of something you know benefits you more than the person.

Re: Lessons from 14 years at Google

#664

Post by [deleted] »

mattacular wrote: post #413
simonw wrote: post #10

I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/ Likewise, "Abstractions don’t remove complexity. They move it to the day you’re on call." made me think of this 23 year old classic from Joel Spolsky, the Law of Leaky Abstractions: https://www…

Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)

[deleted]

Re: Lessons from 14 years at Google

#665

Post by abdullahkhalids »

_heimdall wrote: post #620
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…

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?

Many laws solve the problem of high initial cost dissuading globally good actions. Laws forcing everyone to buy insurance, for example. It's very easy to see that where such laws don't exist, almost no one buys insurance, making everyone worse off.

This is also an example of the same kind of law.

Re: Lessons from 14 years at Google

#666

Post by PeterAnderson »

17. Your network outlasts every job you’ll ever have. Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades.

They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years.

Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.

When the time comes to move on, it’s often relationships that open the door.

Thanks! I used to think writing code was the easiest and most enjoyable thing in the world. Interacting with people? That’s always been the hard part. Guess it’s high time I changed my mindset now.

Re: Lessons from 14 years at Google

#667

Post by hnlmorg »

dijit wrote: post #240
hnlmorg wrote: post #221

Earlier quoted context omitted.

I hate Microsoft with the passion of a thousand burning stars, yet even I still think Google products have worse UX than their Microsoft counterparts. MS Teams is definitely terrible. But I’d take that over Google Meets. Google Docs isn’t even remotely as good as Office 365. And Azure, for all its many faults, is still less confusing than GCP. Thankfully I seldom have to touch either other these companies half-baked…

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

Because it’s a low bitrate micky mouse toy.

MS Teams might have its issues (and let’s be clear, i agree there are a great many issues) but it has most, if not all, of the Enterprise features you need from a video conferencing suite.

Whereas Google Meets feels more like a cut down toy you’d give to your grandparents.

It’s the same thing with Google Docs. They’re technically impress for the era they were launched, but they’re stuck in the 2010s. Doing anything outside of the basics quickly becomes far far more frustrating than using O365.

Microsoft might write a lot of terrible software with some questionable design choices, but they understand enterprise uses far better than Google.

Even Google Workspaces is severely limited once your business grows beyond 50 people.

I guess if you only work in startups then Google might seem like an easy win. But for any business that’s more established, you just constantly run into huddles with Googles suite of software.

As for GCP, I’ve been burned too many times with their support processes. 7 days to approve a GPU quota. Account managers literally trying to steal business secrets (when I worked for an AI start up and Google were stagnating in the AI space). And so on and so forth. Though I’ve not been hugely impressed with Azure either; they constantly break managed services and ballsup scalability promises and then refuse to admit it until we present them with empirical evidence. It really feels like the best cloud engineers have left Microsoft (or maybe never joined?).

Re: Lessons from 14 years at Google

#668

Post by AtNightWeCode »

Very good. I agree with most of it. One thing I disagree with is "The senior engineers I respect most have learned to trade cleverness for clarity, every time.". This sounds like the anti-pattern "design for lowest competence" or similar. This is a big trap. A little bit of magic is often better than clarity. Junior devs should learn to follow the rules and how things work without the actual need for deeper understanding.

Re: Lessons from 14 years at Google

#669

Post by Foobar8568 »

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…

Thales?

Re: Lessons from 14 years at Google

#670

Post by [deleted] »

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…

[deleted]
Post reply on HN