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

171–180 of 319 posts

Re: Software Engineering at Google (2017)

#171

Post by rodorgas »

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…

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.

Re: Software Engineering at Google (2017)

#172

Post by alexandercrohde »

>>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 stated so matter-of-factly.

Re: Software Engineering at Google (2017)

#173

Post by zozbot123 »

rodorgas wrote: post #171
sytelus wrote: post #91

Earlier quoted context omitted.

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…

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.

Re: Software Engineering at Google (2017)

#174

Post by bsvalley »

hknd wrote: post #168
bsvalley wrote: post #157

Other than the 20 percent free time, compensation and offices, the engineering culture at Google doesn’t seem to have anything special based on this well written pdf. It is in fact very similar to other large tech companies. Just in case you were still wondering what really attracts great engineers.

I think it attracts a lot of great engineers that they can (mostly) work on something which is used by billions of users. You can basically improve the life of 1B ppl by writing code. Also: having a FAANG company in your CV makes it super easy join any other tech company.

Reality is that most of the engineers at Google don't work on google search nor google map. They work on "smaller" projects that don't necessarily reach billions of users. It doesn't change the fact that everything has to be engineered in order to work for a large amount of users, true, but do you really get that reach? nope unless you're in a very hot and selective team at G.

Also, your statement is valid for companies like Facebook, Uber, Apple, Amazon, etc. It is not a valid argument anymore in my opinion. But I totally get your point.

Re: Software Engineering at Google (2017)

#175

Post by bsvalley »

yifanl wrote: post #159
bsvalley wrote: post #157

Other than the 20 percent free time, compensation and offices, the engineering culture at Google doesn’t seem to have anything special based on this well written pdf. It is in fact very similar to other large tech companies. Just in case you were still wondering what really attracts great engineers.

I'm not sure what you could do to improve engineering culture beyond making your office a little bit nicer without starting to take away from life outside the office.

You can innovate in many different areas. For example code reviews, CI/CD pipelines, sharing knowledge across the organization. It seems that Google as a pretty solid engineering culture but it doesn't really innovate much like a lot of other large tech companies. Standards are meant to be broken.

Re: Software Engineering at Google (2017)

#176

Post by throwawaymath »

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 your example? The google.com search interface rarely changes (logo notwithstanding), but what do we have to go on for how often search infrastructure or processing code changes?

Re: Software Engineering at Google (2017)

#177

Post by shereadsthenews »

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.

Re: Software Engineering at Google (2017)

#178

Post by thetechlead »

hknd wrote: post #169
thetechlead wrote: post #81

Earlier quoted context omitted.

Yes.

Dropbox started in python (and is still using it a lot) ...and we all know how horribly they failed.

Whether a startup will succeed has nothing to do with the language used. Google started with Python and TikTok with PHP (wtf). However when you start, go with the better choice since every line of code becomes a liability later.

Re: Software Engineering at Google (2017)

#179

Post by zozbot123 »

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…

> Instead of understanding why things are the way it is, they fantasize about how they can one up original authors and claim their own hero title.

Hell, if they really care about claiming that hero title, why not spend that effort to understand and refactor the parts of the code that were initially hard to deal with. What you wrote above is a distillation of what a "tech bro", "Type-A player", ego-based culture looks like. It is the opposite of true professionalism.

Re: Software Engineering at Google (2017)

#180

Post by gradys »

lexpar wrote: post #163

The protocol buffers stuff seems pretty cool. At my last job (small web dev shop), we had constant headaches over the class definitions of endpoints changing and some js file not having its model updated to correspond. I thought we should be writing XML files that both ends could be reading in - we never got up the political will to make that big change though. https://developers.google.com/protocol-buffers/

Yep, protocol buffers are like a cross-language type system for the data that moves between systems with the side benefit of compact serialization. They're awesome and definitely a big productivity boost above a certain scale.
Post reply on HN