Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering at Google (2017)

arxiv.org

Post reply on HN
Print view View original

191–200 of 319 posts

Re: Software Engineering at Google (2017)

#191

Post by draw_down »

shereadsthenews wrote: post #177
dekhn wrote: post #147

I was the maintainer of a third-party library used by thousands of dependent applications at Google. I have to admit, I still have not seen on the outside a system that allows me to change the version of numpy, and know that thousands of dependent applications either work or break, within an hour of making my change. Being able to write and use a mapreduce with a high level of confidence that my code would continue t…

People who like multirepos are always saying how easy it is to pin dependencies but like you I haven’t seen anyone doing it right since I left Google. The monorepo third-party system works well in practice. Ps thanks for getting scipy into third_party all those years ago.

What’s really strange is how many people in that recent monorepo discussion were advocating for it in the context of a small org. I’ve only encountered monorepo in a large org, where I’m pretty convinced it’s more efficient than the alternative.

Re: Software Engineering at Google (2017)

#192

Post by steelframe »

webmaven wrote: post #76
scarface74 wrote: post #41

Earlier quoted context omitted.

My experience is that the difference in raises between an employee that got an “Exceeds Expectations” and one that “Meets Expectations” isn’t significant enough to be worth wasting the time worrying about it. The best way to make more money is to change jobs. Google may be different.

Well, if you exceed expectations, doesn't that mean you didn't set your goals high enough?

At Google you are expected to exceed expectations.

But seriously, you are evaluated against the role description (software eng? product mgmt?) and your level. If you exceed expectations consistently over several review cycles, you are encouraged to apply for a promotion.

The goal is to get you promoted into a role and level where you can consistently meet expectations.

Re: Software Engineering at Google (2017)

#193

Post by wolco »

alexandercrohde wrote: post #184
throwawaymath wrote: post #176

Earlier quoted context omitted.

Is it possible most software at Google is not Chrome, Gmail, Search, Youtube, Analytics, Android or Documents? Also do you work at Google? If you don't, you might not be able to perceive all the changes to those applications on the backend. The user interface may change at a more constrained pace, but it can still be true that most backend code is in a constant state of revision. For example, what defines "Search" in…

Let me be clear (and I don't work at google). I'm not saying google doesn't spend a lot of engineering time doing rewrites. I'm saying if google DOES spend a lot of the engineering time of its 20,000 engineers doing rewrites that is BAD by all measures. Maybe it would explain how a company with 1,000 startups worth of "top-talent" engineers could not produce any new functionality in the last 5 years though (small exc…

This is a good point worth exploring. If google has 1000 startups worth of talent (which is another point worthdiscussing) the corporate structure has clearly slowed down new functionality or new product ideas. It seems like it is 1000 times harder at google which levels the playing field.

Re: Software Engineering at Google (2017)

#194

Post by fergus_google »

weinzierl wrote: post #49
majikandy wrote: post #45

Earlier quoted context omitted.

Make the changes smaller and more valuable and do it on trunk.

This should always be Plan A but in my experience it is not always possible. Think of untangling dependencies between a large number of components as an example.

Untangle one dependency at a time.

Re: Software Engineering at Google (2017)

#195

Post by Teknoman117 »

dekhn wrote: post #147

I was the maintainer of a third-party library used by thousands of dependent applications at Google. I have to admit, I still have not seen on the outside a system that allows me to change the version of numpy, and know that thousands of dependent applications either work or break, within an hour of making my change. Being able to write and use a mapreduce with a high level of confidence that my code would continue t…

Are you allowed to share if the internal repository a custom version control system or is it one of the open source ones?

Re: Software Engineering at Google (2017)

#196

Post by jessmay »

alexandercrohde wrote: post #184
throwawaymath wrote: post #176

Earlier quoted context omitted.

Is it possible most software at Google is not Chrome, Gmail, Search, Youtube, Analytics, Android or Documents? Also do you work at Google? If you don't, you might not be able to perceive all the changes to those applications on the backend. The user interface may change at a more constrained pace, but it can still be true that most backend code is in a constant state of revision. For example, what defines "Search" in…

Let me be clear (and I don't work at google). I'm not saying google doesn't spend a lot of engineering time doing rewrites. I'm saying if google DOES spend a lot of the engineering time of its 20,000 engineers doing rewrites that is BAD by all measures. Maybe it would explain how a company with 1,000 startups worth of "top-talent" engineers could not produce any new functionality in the last 5 years though (small exc…

Imagine trying to bash Google developers when your personal website is Wordpress based and is still fucked and runs on an expired certificate in 2k19

Re: Software Engineering at Google (2017)

#197

Post by steelframe »

commandlinefan wrote: post #170
matwood wrote: post #106

Earlier quoted context omitted.

> Did you fix a major fuckup in some legacy component? What if that legacy component was no longer in use? Is there some bigger picture in play? I've been at bad companies before, so I understand being cynical. But, having people just do whatever they feel like also does not work. From the outside it looks like Google has quite a bit of this, so they are clearly trying to get people on some path. The messaging app si…

> What if that legacy component was no longer in use? He was actually assigned by his manager to investigate the problem. Source: am a programmer.

All of life is a series of negotiations. Those who can negotiate more effectively come out ahead. This is true whether you are discussing your compensation when joining a new company or whether you are hashing out what you work on.

If your manager asks you to do something, ask them how the thing they are assigning will help advance your career. Ask the manager how -- if you deliver on what they ask -- they will go to bat for you when they are sitting in the room with their peers justifying your evaluation score. Be willing and able to simply state, "I don't know how you can expect me to spend my time and energy on something that won't help me advance my career." If your manager can't understand or respect that, then that's great! You have a clear warning sign that it's time to fire your manager.

Re: Software Engineering at Google (2017)

#199

Post by izacus »

fouronnes3 wrote: post #112
skj wrote: post #89

Earlier quoted context omitted.

It's not like we (I am a Googler) email patch files around. Everything is integrated into the system. You create a CL (change list), it automatically gets a number. People can review it, test it, or fork it (make a new CL using your CL as a starting point) as much as they want, all from that CL number.

So basically it's a branch?

Think of a CL like a Pull Request that has (and can only have) a single commit.

It's visible in code review UI, has a description, has tests run on it, it can be merged by other people and it can be referenced from anywhere. Eventually it's merged into the head or dropped.

Re: Software Engineering at Google (2017)

#200

Post by pjc50 »

shereadsthenews wrote: post #177
dekhn wrote: post #147

I was the maintainer of a third-party library used by thousands of dependent applications at Google. I have to admit, I still have not seen on the outside a system that allows me to change the version of numpy, and know that thousands of dependent applications either work or break, within an hour of making my change. Being able to write and use a mapreduce with a high level of confidence that my code would continue t…

People who like multirepos are always saying how easy it is to pin dependencies but like you I haven’t seen anyone doing it right since I left Google. The monorepo third-party system works well in practice. Ps thanks for getting scipy into third_party all those years ago.

> The monorepo third-party system works well in practice.

It's worth noting that this is only viable at Google because they don't use git. Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive.

I see conflicting reports over whether google use Perforce or something proprietary called "piper"?

Post reply on HN