> hunger is never a reason to leave But good luck finding a free restroom at 10am. Is this an issue at other companies?
Software Engineering at Google
71–80 of 161 posts
Re: Software Engineering at Google
#72>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 Goo…
My understanding is that while I'm a little bit of an outlier, in general 20% time at Google is nowhere near as dead as people on the internet tend to claim (at least for engineers).
Re: Software Engineering at Google
#73>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 Goo…
This (like a lot of things at Google) varies wildly across PA and even among managers within a PA. All my managers so far have been extremely supportive of 20% time, and I've personally worked on three different 20% projects over my last four years (including two which have been open-sourced). That being said my engagement model has generally been less "one solid day a week" and more "a few days in a row once a month…
Re: Software Engineering at Google
#74Is 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…
Coming from companies that use reasonably-sized git repos, I absolutely hated Google's VCS. Here's some of my painpoints with it: * No branches. If you want to make a temporary code branch, you create a CL (Google's version of a pull request), but never submit it. This means nobody else can collaborate on it with you, and it must be manually updated to HEAD. * No CL collaboration. Unlike Git branches, CLs can only co…
Re: Software Engineering at Google
#75> Software engineers at Google are strongly encouraged to program in one of four officially-approved programming languages at Google: C++, Java, Python, or Go. I wonder which of these languages they use to develop the google front page or any other frontend when no Javascript is allowed...
Re: Software Engineering at Google
#76>>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.
Re: Software Engineering at Google
#77Earlier quoted context omitted.
This (like a lot of things at Google) varies wildly across PA and even among managers within a PA. All my managers so far have been extremely supportive of 20% time, and I've personally worked on three different 20% projects over my last four years (including two which have been open-sourced). That being said my engagement model has generally been less "one solid day a week" and more "a few days in a row once a month…
What is a PA ?
Re: Software Engineering at Google
#78Google 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…
As some point you have to hire someone to take out the trash. They can't all be Einsteins.
Re: Software Engineering at Google
#79Interesting, 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 peop…
Just look at Google Nest and their massive outage in December 2015, that’s usually enough to kill a company, and if Nest was independent, it’d have hurt them massively.
Their reliability is nice compared to competing websites, but compared to other infrastructure, it’s quite bad. Hell, I’ve seen 2 orders of magnitudes more Google outages than power outages in my entire life (combined 29min power outage vs. several days Google outage since '96)
Re: Software Engineering at Google
#80Although there is a well-defined process for launch approvals, Google does not have a well-defined process for project approval or cancellation. Despite having been at Google for nearly 10 years, and now having become a manager myself, I still don’t fully understand how such decisions are made. The reason why I quit Google.