They have a billion files in their repo, 9 million are source files.
What the heck is the other 991000000?
I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.
What the heck is the other 991000000?
I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.
Lots of things aren't source files: test data, config files, build files, metadata, documentation, etc.
Yes, you're absolutely correct. But here's the thing - it was actually Google that pioneered many of this. Many of the big/competent companies that are following these practices are because of Google's "DNA" leaking into those companies (via former employees bringing along the best practices learned at Google, etc.)
A specific example - the practice of keeping the entire codebase at the company under a single "source" repo. Pre-Google - it would've been considered outrageous to have the entire codebase of a sophisticated software company keep their entire software contents under a single repo. But Google did it, and other companies have followed suit successfully (as Google DNA has leaked to other companies).
Yes, of course keeping code in a single repo is not a "new invention". Linux is a single repo; many smaller companies have only a single repo because their only product is a single web app. Google keeps nearly 100% of their entire codebase in a single repo - and that was definitely a novel approach at the time.
Says right in the article: various config and dependency files, presumably both as caches (where everyone would generate the same product) or as a record of where things stood on at time t.
For example:
> In some cases, notably Go programs, build files can be generated (and updated) automatically, since the dependency information in the BUILD files is (often) an abstraction of the dependency information in the source files. But they are nevertheless checked in to the repository.
There are thousands of SWEs working on systems to save money for Google.
You can get an idea of what it looks like by reading the Bazel docs: https://bazel.build/versions/master/docs/be/overview.html
Storing a few text files at Google doesn't cost millions of dollars, BTW.
That "Hello World" Flask program that was 1 nice cute file? It's about 20 files deployed in Heroku.
Sometimes I wonder if things really need to be this complicated.
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.
The issue here is that politics are unavoidable. Being more data-driven is just another way of running your political process. And yes, it's a better way as long as you know its limitations. Collecting data and sifting through it to extract useful information takes time, creative thinking, and even "instinct" to figure out the right questions and hypotheses. Furthermore if you're going to collect data on dev workflow you better not have incentives there for employees or they will be gamed.
One of my pet peeves is technical people who worship so strongly at the altar of rationality that they are blind to their own biases. Even the most guileless and logical engineer still has an emotional life and worldview that forms the building blocks of what turns into "politics" when you get a large group of people together.
There are billions of dollars of difference between "would" and "should"
Who is "they" who act like it's super-awesome?
Ps: goog employee