Software Engineering at Google (2017) • Hacker News Board

Re: Software Engineering at Google (2017)

#151

Post by brown9-2 » Fri, Jan 04, 2019, 2:25 PM UTC

weinzierl wrote: post #86

hknd wrote: post #67

Earlier quoted context omitted.

It's actually really easy to create a "patch", so people usually create small "patches" and send them to people if they need any feedback on those. A "patch" is actually just a commit (actually a changelist) which can be viewed, commented and edited in the browser based code review and IDE tool. Imho I find it much easier to get an url of a "patch" and comment on it inline, instead of having to checkout a branch etc.…

Thank you, I appreciate your effort to help me understand this better and our exchange helped me to make progress. One thing I infer from your answer is that it seems that there is an established process and dedicated tooling for working with patches at Google. I think a lot of my pain with patches stems more from the lack of process and lack of an agreement on formats and standards in my environment than from the us…

I think what you are missing is that Google's SCM has different concepts and terms than Git.

Google's system is derived from Perforce, which has the concept of a changelist (think: commit), which can be "pending" and stored on the server for review/cloning by other developers: https://www.perforce.com/perforce/doc.051/manuals/p4guide/07...

This allows you to share work without (in Git terms) pushing to master. Branches in Perforce-like systems tend to be more heavyweight and permanent (IIRC you have to branch an entire path of files, it is not the same as the Git concept of "branch" which is just a commit that points to another parent commit).

You can think of the system as enabling you, in Git terms, to create pull requests without the creation of an underlying branch.

Re: Software Engineering at Google (2017)

#152

Post by VikingCoder » Fri, Jan 04, 2019, 2:26 PM UTC

weinzierl wrote: post #25

jsty wrote: post #17

Earlier quoted context omitted.

You could also gate experimental code behind feature flags which aren't set in prod

I agree that feature flags can be a solution sometimes. The presentation and the paper I linked to in my question discusses this, but they also mention large-scale refactorings and this is where I don't see how feature flags can help. For example: How do they untangle a wad of code that is large enough that it takes longer than a few days and more than a single developer to get the code back into a state that is acce…

Try like hell to use dependency injection in the first place.

Re: Software Engineering at Google (2017)

#153

Post by emperorcezar » Fri, Jan 04, 2019, 2:26 PM UTC

klodolph wrote: post #143

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…

You can call it a psychological problem if you want but calling names is not a solution, nor does it really provide a good path to finding a solution. The labor market being what it is, people will leave steady jobs with good pay for more exciting work with riskier prospects and less pay. This happens all the time. Bug fixes and incremental features will generally not get you promoted for good reasons, we expect seni…

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

Re: Software Engineering at Google (2017)

#154

Post by zbentley » Fri, Jan 04, 2019, 2:27 PM UTC

thetechlead wrote: post #145

phonebucket wrote: post #128

Earlier quoted context omitted.

>Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load). A developer shouldn't have time to fix other people's bugs?

Unless you work on the project, report to the owner who has better knowledge of the code and ask them to fix. Otherwise you are not helping them but end up using their time teaching you how the code really works. Not good for the total productivity of the whole team.

The environment you're describing is more siloed than many 5000+-engineer companies I've worked at or read about. Which is concerning, given that you describe it as a startup.

Re: Software Engineering at Google (2017)

#155

Post by thetechlead » Fri, Jan 04, 2019, 2:27 PM UTC

xenihn wrote: post #144

thetechlead wrote: post #54

I used to be proud of many things in the article when working at the G. Not anymore. Let me talk startup anti-Google pattern here. * Most of Google’s code is stored in a single unified source-code repository, and is accessible to all software engineers at Google This can be the worst nightmare from a management POV in a startup. Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't h…

What resources do you recommend to new SWE hires with no Go experience in order to ramp them up?

https://tour.golang.org/welcome/1

Go through this tutorial and gobyexample.com and they should have enough knowledge to work on a project at the end of day three, because the language is so simple. If not, fire your new hires.

Re: Software Engineering at Google (2017)

#156

Post by seanmcdirmid » Fri, Jan 04, 2019, 2:30 PM UTC

sethammons wrote: post #136

le-mark wrote: post #120

Earlier quoted context omitted.

When it gets tied into career progression, I've come to the conclusion it's folly to pursue any one companies career progression maze. Because you get corralled into all sorts of sillyness like this; vying for projects with your peers, acrimonious code reviews, chasing silly metrics, etc. I find it's much more effective in time, money and title (and work life balance, and mental health) to simply switch jobs for the…

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.

Re: Software Engineering at Google (2017)

#157

Post by bsvalley » Fri, Jan 04, 2019, 2:32 PM UTC

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.

Re: Software Engineering at Google (2017)

#158

Post by Radim » Fri, Jan 04, 2019, 2:32 PM UTC

rpod wrote: post #140

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”."

Hey, I just wanted to say that I really love your gensim library. I've used it for my Master's thesis a couple of years back and it's been a tremendous help. Thanks so much!

Thank you! That's so nice to hear :)

To get on-topic: Gensim could use such a rewrite as well… The ML world changed, expectations and requirements changed, ecosystem and APIs changed. I changed too.

Re: Software Engineering at Google (2017)

#159

Post by yifanl » Fri, Jan 04, 2019, 2:34 PM UTC

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.

Re: Software Engineering at Google (2017)

#160

Post by MichaelMoser123 » Fri, Jan 04, 2019, 2:37 PM UTC

davidwihl wrote: post #62

MichaelMoser123 wrote: post #53

Earlier quoted context omitted.

I am wondering if the rewriting rule applies to AdWords and search, I mean they probably would get very upset if their cashcow stops working, all of a sudden.

The AdWords API is now being re-written, the biggest change in ten years. It is migrating from XML to gRPC / protobuffers. https://developers.google.com/google-ads/api/docs/start Disclosure: I co-author the Python client library and have written a few of the docs on the site listed above.

Thanks for the link!