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

Software Engineering at Google

arxiv.org

Post reply on HN
Print view View original

51–60 of 161 posts

Re: Software Engineering at Google

#51

Post by oscardelben »

l1feh4ck wrote: post #39

>>Engineers are permitte d to spend up to 20% of their time working on any project of their choice, without needing approval from their manager or anyone else. Can someone tell more about what they did and the things are that permitted (even though without needing approval.

You definitely need to tell your manager though.

EDIT: one personal example is at some point I took some external classes and used 20℅ time for it. But most cases are for developing some sort of tools or product.

Re: Software Engineering at Google

#53

Post by halflings »

dasil003 wrote: post #27
Veratyr wrote: post #21

Earlier quoted context omitted.

> Mostly just stuff any competent company would/should be doing. Many companies should be doing this. Few (that I know of) are doing this. Making data-driven decisions also should be a thing, yet many still make them based on nonsense like politics.

Right, because data leaves no room for interpretation.

No need to be needlessly sarcastic. Data-driven means that you collect various metrics on dev workflow, what slows productivity, or on the product side (user patterns, retention, etc.) and use those when making decisions. Unfortunately, many companies still base their decisions very simplistic metrics and/or on "instinct".

Re: Software Engineering at Google

#55

Post by mamon »

harryjo wrote: post #15

Is section 3.1 "20%" time still true?

You guys seem to think that Google is benevolent by giving engineers that 20%, while in fact they do that for very selfish reasons: it is all about copyrights.

They hire the smartest Software Engineers in the world, so it is only a matter of time that some of them will create new, disruptive product.

If they weren't given that 20% of time at Google they would do that anyway, on weekends, but since they do it in company-sponsored time then Google owns the copyrights to all of their work.

Re: Software Engineering at Google

#56

Post by hueving »

Matthias247 wrote: post #54

Interesting, compared to what's common in the automotive industry it doesn't even mention the terms "requirements", "specifications", "estimations", "project plan", "tracability", "UML", etc...

Right, if it mentioned those, search would still be the version we saw in 2007. None of the other products would exist yet because they would still be conducting user studies based on wire frame mock ups of workflows designed by committees of behavioral psychologists.

That's a bit dramatic, but when your product development has a fast turnaround for fixes (git push vs 100 million dollar recall) and it won't kill people when it breaks, you should immediately throw most of that process shit out the window.

You can't be competitive in consumer SaaS if you get bogged down in 'real engineering' processes.

Re: Software Engineering at Google

#57

Post by arjie »

milesrout wrote: post #49
__strisk wrote: post #29

Is the practice of shoving all disparate pieces of proprietary software (or individual projects) in the same repo a common occurrence? I have found that pulling unrelated changes just so that I can push my changes is an inconvenience. Furthermore, tracking the history of a particular project is confounded due to unrelated commits. I am sure that their vcs (piper?) makes this a feasible task, but for git, it seems lik…

No, it's not common. It's something that a couple of big companies have done, and while it might work for them it does NOT work for most people. It's a really, really bad way of doing development.

Why is it so bad? It seems incredibly effective for them and there are very good outcomes:

• no trailing dependencies so you never have to backport fixes, maintain multiple released versions, etc.

• extensive integration testing of libraries since they go live instantly

• forced library developer and library user collaboration

• deployed code is not out of date

What's the problem with only One True Version? All the complaints seem around tooling.

Re: Software Engineering at Google

#58

Post by hueving »

Google has gotten so large so quickly in the past 3 years, that I wonder how much damage has been done to their engineering culture. A lot of "less than stellar people" have joined in these recent years according to several of my friends that work there (in infrastructure and some ML groups).

It seems the push to golang is entirely to sustain large projects with average engineers. Maybe somewhere high up they decided that it's better to just have a massive engineering workforce rather than only hiring top talent? At what point does brain drain start as the best people get sick of dealing with mediocrity?

Re: Software Engineering at Google

#59

Post by msangi »

__strisk wrote: post #29

Is the practice of shoving all disparate pieces of proprietary software (or individual projects) in the same repo a common occurrence? I have found that pulling unrelated changes just so that I can push my changes is an inconvenience. Furthermore, tracking the history of a particular project is confounded due to unrelated commits. I am sure that their vcs (piper?) makes this a feasible task, but for git, it seems lik…

The company I work for has a monorepo and has a team dedicated to develop lots of tooling around it to make it manageable.

Do you want to check out only the app you're working on? There is a script that grabs it and its dependencies.

Do you want to do continuous integration? We have plugins to our CI server that understand when the app code or one of the dependencies has been updated.

Building always off HEAD is nice and it solved the issues we had with diamond dependencies but I am not completely convinced this is the right approach

Re: Software Engineering at Google

#60

Post by hueving »

>Engineers are permitted to spend up to 20% of their time working on any project of their choice, without needing approval from their manager or anyone else.

From what I understand talking to current employees, this is now bullshit. You could spend 20% on other stuff, but the culture in many of the groups is such that you are putting your peer review at risk by doing so because of your reduced output.

Any current Googlers that spend 1 day of every week working on something completely unrelated to their main job want to comment?

Post reply on HN