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

181–190 of 319 posts

Re: Software Engineering at Google (2017)

#181

Post by steren »

alexandercrohde wrote: post #172

>>Most software at Google gets rewritten every few years. >> This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s resources. However, it also has some crucial benefits that are key to Google’s agility and long-term success. Uh... No? Chrome, gmail, search, youtube, analytics, android, documents all usually have 2 or 3% functionality changes each year. What a ludicrous proposition stat…

New features is different from software change. A UI might stay identical while the entire software is rewritten.

Re: Software Engineering at Google (2017)

#182

Post by fergus_google »

why_only_15 wrote: post #30
Radim wrote: post #5

Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."

This is interesting to me because something like this only works if there are lots of tests and they can be run after every change. If you rewrite code constantly and potentially create new bugs by e.g. not understanding edge cases previous developers put in, then this isn't feasible. With a focus on testing this becomes practicable.

It's common for code at Google to be rewritten without reusing most of the existing tests -- instead, new tests are written for the new code. Yes, this risks not understanding edge cases. But not all of those edge cases are still important.

Re: Software Engineering at Google (2017)

#183

Post by commandlinefan »

seanmcdirmid wrote: post #156
sethammons wrote: post #136

Earlier quoted context omitted.

Or find a good company. I've worked hard and gone from mid level (actually slightly lower) to principal over several years at the same, growing company. My responsibilities have drastically changed over time towards greater impact and my pay is nearly 3x from where I started.

The same could simply be accomplished with good people management. A good 10X people manager is worth their weight in gold.

> A good 10X people manager

I've worked for a few. In my experience they end up getting pushed out by the bureaucracy after a few years.

Re: Software Engineering at Google (2017)

#184

Post by alexandercrohde »

throwawaymath wrote: post #176
alexandercrohde wrote: post #172

>>Most software at Google gets rewritten every few years. >> This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s resources. However, it also has some crucial benefits that are key to Google’s agility and long-term success. Uh... No? Chrome, gmail, search, youtube, analytics, android, documents all usually have 2 or 3% functionality changes each year. What a ludicrous proposition stat…

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 exception of AI)

Re: Software Engineering at Google (2017)

#185

Post by addicted »

dharmab wrote: post #123
yjftsjthsd-h wrote: post #99

Earlier quoted context omitted.

Just do one thing at a time? Today, I am working on X; my commits are for X, and details are in the commit message.

That breaks as soon as you have to interrupt working on Nice To Have Feature X to working on Inportant Bugfix/CVE Y.

How often does that happen to an individual developer though?

Once a month? In an averagely well run company even that may be towards the higher end.

Should your entire development strategy be based on a once a month occurrence?

Re: Software Engineering at Google (2017)

#186

Post by collyw »

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…

Bollocks. There are tons of people doing maintenance programming on code that they didn't write.

Re: Software Engineering at Google (2017)

#187

Post by makewavesnotwar »

sytelus wrote: post #91
Radim wrote: post #5

Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."

If you have engineers with physiological problem of “not invented here”, you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told almost exact same words as “reason” to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other o…

This.

Trying to make the software "theirs" seems to be an issue at Google, at least with their open source software and has seemed to have lead to it being less reliable.

For example, Angular Material v1 was one of the most complete and stable front-end packages on the market a few years ago. Then, back in 2017 the lead developer for the project was replaced with a new dev.

This new dev then went about assigning every issue and pull request to himself, modifying or rejecting pr's that had previously been approved, closing issues that had in progress pr's as won't fix, locking discussions, and just generally breaking stuff. (I've personally had to peg my project to v1.4 because everything since 2016 has been a regression)

If you go to the Angular Material v1.x Github page today, you'll see the same dev on pretty much everything.

This isn't productive ownership as it prioritizes the engineer over the customer and has lead to a generally broken system from one of the most stable properties out there. Not to mention, these open-source projects are most people's first exposure to Google's code... Having them be unpredictable regarding the functionality of their software with little concern for users/contributors in the name of making their devs feel special seems like a bad model to learn from.

Re: Software Engineering at Google (2017)

#188

Post by pault »

lugg wrote: post #9
yakshaving_jgt wrote: post #8

Earlier quoted context omitted.

Thanks for highlighting this. To me it seems an important idea that contradicts conventional wisdom, similar in the way that most people over-encourage DRY, blind to the fact it increases coupling.

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.

Re: Software Engineering at Google (2017)

#189

Post by steelframe »

commandlinefan wrote: post #167
weavie wrote: post #33

Earlier quoted context omitted.

I had this when I worked at a large enterprise several years ago. If I recall correctly we had to state goals for each of 5 major categories and another set of 5 supplementary categories. The categories were things like - deliver customer value, enhance team work, collaborate well across teams and various other enterprise buzz words, I forget exactly.. As a coder, my goal was pretty much to write good code and avoid…

My first "goal-setting" experience (five jobs and 20 years ago) was like this: upper management would define company-wide goals (that ended up being incredibly vague) and their direct reports would define their own goals that supported the company-wide goals, and their direct reports would define _their own_ goals, ad nauseum, until it finally trickled all the way down to me, the lowly programmer. So I took it seriou…

Sounds like that was a classic case of confusing "lag measures" with "lead measures." I'd suggest to anyone in a situation with a manager who tries to over-focus on lag measures to explicitly bring up the concept with them.

https://navelmarketing.com/2013/04/16/lead-measures-vs-lag-m...

Re: Software Engineering at Google (2017)

#190

Post by steelframe »

scarface74 wrote: post #41
MeteorMarc wrote: post #2

"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?

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.

Google is indeed different. While you might not find the delta in compensation for one performance review cycle to be worth the effort, employees with a track record of exceeding expectations can expect to come out significantly ahead of where they would be if they had only met expectations.
Post reply on HN