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

201–210 of 319 posts

Re: Software Engineering at Google (2017)

#201

Post by mcguire »

Novashi wrote: post #162
emperorcezar wrote: post #153

Earlier quoted context omitted.

> Bug fixes and incremental features will generally not get you promoted for good reasons. This is exceptionally bad, but sadly true. If you have an engineer who can unblock teams and fix issues in an hour that others take a week or cannot fix at all, they are gonna jump ship if they can't be recognized. At that point you've lost a valuable resource.

Recognition is stupidly cheap. If I can do that without it being a fluke, they’d better bump my salary.

Would you settle for a certificate?

Re: Software Engineering at Google (2017)

#202

Post by detaro »

pjc50 wrote: post #200
shereadsthenews wrote: post #177

Earlier quoted context omitted.

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

AFAIK they used perforce in the past and then built their own later.

Re: Software Engineering at Google (2017)

#203

Post by alexhutcheson »

pjc50 wrote: post #200
shereadsthenews wrote: post #177

Earlier quoted context omitted.

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

This paper has details and history regarding Perforce and Piper: https://ai.google/research/pubs/pub45424

Re: Software Engineering at Google (2017)

#204

Post by hknd »

Teknoman117 wrote: post #195
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?

It is, like most of the tools in Google/Facebook/..., a custom solution. These companies need their custom solution because of their scale.

Re: Software Engineering at Google (2017)

#205

Post by anonymouzz »

pjc50 wrote: post #200
shereadsthenews wrote: post #177

Earlier quoted context omitted.

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

Afaik it's a custom system with download-and-cache-on-demand.

Note that there's nothing forbidding you from writing a virtual git filesystem that fetches objects from some centralized repo as files are open()ed. Git on cloud steroids.

Re: Software Engineering at Google (2017)

#206

Post by pacala »

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.

Pinning dependencies is easy, and gets one stuck on Java 1.3 and IE 6. Since the library maintainer doesn't know it broke dependent code, the dependent code will be unlikely to have a smooth upgrade path. It's just a matter of having the luxury of picking up a time to pay the cost of dependency upgrades. Which cost may be high in a world where your dependencies also pin dependencies, likely at different versions.

The underlying assumption it that the project will fold in 2 years anyways, so one may get away with never doing dependency upgrade.

Re: Software Engineering at Google (2017)

#207

Post by zozbot123 »

pault wrote: post #188
lugg wrote: post #9

Earlier quoted context omitted.

I frequently find myself drastically refactoring code to understand it. I don't commit those changes because it's not worth the effort to justify the cleanup to people who treat these rules as gospel. Apparently me spending half a day reading code is no big deal but cleaning it up is a waste of time. Shrug.

I often see some bit of code, or a dependency in a project that I think is over engineered and too complex and start rewriting; first I get something basic working, then I discover some edge case, then another, and another, and eventually I realize that I have reimplemented the original code. It always makes me feel silly, but at the same time those have been the best learning experiences I've ever had.

The proper response to that is to actively document these edge cases (within the original code) so that they don't get missed as the code is maintained in the future.

Re: Software Engineering at Google (2017)

#208

Post by mcguire »

sagichmal wrote: post #146
sytelus wrote: post #116

Earlier quoted context omitted.

There are always good technical reasons to rewrite things but the reason quoted by the parent i.e. devs not “feeling” ownership and won’t work on code wholeheartedly unless it’s their code - those reasons are evil.

No. Absolutely wrong. A sense of ownership and responsibility over a codebase is fundamental and essential to proper stewardship and maintenance of that code, and refactoring and rewriting is the most effective way to inculcate that feeling. Sometimes it’s not always feasible, and sometimes it’s not necessary, but the end state is essential. Group or shared ownership of code is a manager’s wet dream but pragmatically…

Once upon a time, there was a core software engineering principle of "egoless programming". I'm glad we've thrown that piece of idiocy out the window.

Re: Software Engineering at Google (2017)

#209

Post by zrobotics »

zozbot123 wrote: post #173
rodorgas wrote: post #171

Earlier quoted context omitted.

It’s not a physiological problem, it’s a technical problem. They do it so they work gets easier. It’s much easier to write code than to read code.

> It’s much easier to write code than to read code. The fact that "write-only code" is apparently considered a part of sensible software-engineering practice speaks volumes about what their technical culture is like more generally. One would think that code should be much easier to read and survey than it was to write.

But even something like a CS101 assignment takes longer to read than to write, at least for me. This is a common enough starement that I assume I'm not alone.

In fact, I'll often sketch out a block diagram or some pseudocode if I'm having trouble grokking something I'm reading just to help me get into the proper mindset. I agree this is a problem with the current state of the field, but I haven't seen any good solutions, only hacks and workarounds.

Re: Software Engineering at Google (2017)

#210

Post by pacala »

pjc50 wrote: post #200
shereadsthenews wrote: post #177

Earlier quoted context omitted.

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

FWIW, there is [used to be?] a git interface for the centralized monorepo. Really handy for managing multiple dev braches at the same time.
Post reply on HN