This all looks nice and perfect, but what's the catch ?
For most people, the catch is that you can't pass the interview loop.
Software Engineering at Google (2017)
211–220 of 319 posts
Re: Software Engineering at Google (2017)
#212I 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…
+1
Re: Software Engineering at Google (2017)
#213I 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.
And for anyone that wants to learn more about how Google manages third-party code, all of our docs are public at https://opensource.google.com/docs/thirdparty/
Re: Software Engineering at Google (2017)
#214Earlier quoted context omitted.
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.
> The monorepo third-party system works well in practice. It's worth noting that this is only viable at Google because they don't use git. Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive. I see conflicting reports over whether google use Perforce or something proprietary called "piper"?
Vfsforgit let's you do that
Re: Software Engineering at Google (2017)
#215Earlier 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…
Code rots, even the best code rots, because the people and cultural environment that the code was written under change and fade away. Refreshing it occasionally, even if it isn’t improved in a significant way, is one way to deal with that rot. Even if the product/library/framework never changed much, rewrites would still be necessary to keep it going as new generations of programmers shuffle through. Otherwise we win…
Exactly this. I view rewriting a code base, even if I am copy and pasting some things from the existing one a way of either learning or refreshing my knowledge on how the system works.
An added kicker, I have actually gone down this road, and later realized the only thing I needed to do was make a small change to the existing system, so I did just that and discarded the new work.
Business got their new features, delivered on time, the system was still stable and reliable, everyone was happy, and now my domain knowledge has increased significantly so that new features and development or bug fixes will be even faster.
Re: Software Engineering at Google (2017)
#216Earlier quoted context omitted.
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.
> The monorepo third-party system works well in practice. It's worth noting that this is only viable at Google because they don't use git. Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive. I see conflicting reports over whether google use Perforce or something proprietary called "piper"?
> Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive.
You might be happy to know Microsoft created a Virtual File System for Git[1] [2] so you do not have to have every file checked out in your working directory. Microsoft uses Git in a monorepo (for Windows, and it's 2.5 million files/300GB[2])
Re: Software Engineering at Google (2017)
#217So, the thing that is still buzzing in my head now and not mentioned in the article (maybe I didn't read carefully enough), what actually gets released into prod after a change is reviewed and merged.
If the monorep contains let's say five different products and in a day only one of them gets a merge, then Blaze still builds all five and all five are released (based on successful integration testing)? OR only releases the changed product (and any other ones which depended on the changed one)
EDIT: Also, the "canary" server is still for testing ? There may exist practically a set of canaries running very different versions ? Is there any correlation or any version "roll-up" constraints between various canaries ?
Re: Software Engineering at Google (2017)
#218Earlier quoted context omitted.
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 exc…
Imagine trying to bash Google developers when your personal website is Wordpress based and is still fucked and runs on an expired certificate in 2k19
ad-hominem much?
Re: Software Engineering at Google (2017)
#219Earlier quoted context omitted.
This makes sure there is never 1.0 ever. I think this is one of the biggest mistake in software. We just keep rewriting things that are already doing what they supposed to. Like the Gmail UI. It got rewritten 3 times already and every iteration it gets shittier.
> every iteration it gets shittier I like how you state this like it's an objective fact. I've always been happy with the gmail UI and the latest iteration is great too. Outlook on the other hand...
Outlook has always been shit, but at least it has been shit in the same way for the past 15 years.
Re: Software Engineering at Google (2017)
#220So, the thing that is still buzzing in my head now and not mentioned in the article (maybe I didn't read carefully enough), what actually gets released into prod after a change is reviewed and merged. If the monorep contains let's say five different products and in a day only one of them gets a merge, then Blaze still builds all five and all five are released (based on successful integration testing)? OR only release…
Releases are controlled by each team. For example, my team has multiple binaries that run in production. Some of them are stable and don't receive any active code changes but are pushed every time we do a release. But for those that don't get direct code changes, they will still pickup any changes to shared libraries.
Canaries are live/production traffic only. When a release is deployed, it goes to the canary instances of a job first, and it will take a small subset of traffic. This allows the job owners to see if the new binary has any adverse effects before rolling out more widely. More details about canaries can be found here[0].
Once important thing to think about with Google's source control is that it is closer to SVN as far as versioning goes. There are no (for the most part) feature branches or anything like that. Everyone is always working on HEAD. when you do a release, you will start near HEAD when cutting the release.
[0] https://landing.google.com/sre/sre-book/chapters/testing-rel...