Google has an unique software engineering culture that was built and designed by the first engineers. Many of the practices show deep understanding of the challenges that growing an engineering culture faces.
A few examples:
There are clearly defined initiation rites for new employees that make them familiar with the engineering practices.
Focus is on a few key languages (C++, Java, Javascript, Python, Go) and code reviews are practiced over the team boundaries. This makes the knowledge transfer inside the company faster.
Changing your team and role regularly is encouraged.
Single, company-wide code tree and build system makes it easy to switch teams and make it possible to build very efficient tooling.
Coding style is strictly enforced to avoid petty fights and Google's very good coding styles guides include reasoning why certain choices were made.
He may be referring to the on boarding process + first commit. Generally you'll have a few classes that introduce you to Google's build tools and any technologies that are relevant to you/your team. Then you'll start work and go through your first code review. This is probably what is refereed to as 'initiation rites'. Depending on the size of the change you may get a handful of comments or quite a few. After going through the code review process you will have successfully internalized Google's commitment to code quality. Generally you'll get a bunch of comments and suggestions that seem nitpicky but help keep things consistent and a few that are eye opening and help you become a better engineer.
I'm guessing he means readability. Google fetisihizes consistency, even at the cost of ingenuity and productivity. Heroism is a virtue at some other companies; at Google, it's a sin.
> Heroism is a virtue at some other companies; at Google, it's a sin.
This is not entirely true. I've seen many people being promoted for "jumping on grenades", especially in SRE. A culture of heroism is unsustainable, but individual acts of heroism (when required) should always be appreciated.
Python and perl are very very similar. Python prioritises expressiveness over uniformity, perl is the opposite. Perl's original OO mechanism was stolen from pythons, but due to the greater flexibility it means that there's a lot of choice and perl's extended OO capabilities exceed that of python. Personally I hate the way that the python people keep bagging out perl when it's clear they know little about it.
I don't have preferences as such. My main problem is that over the past few years my perl skills have been in such high demand that I haven't had much time to do substantial other programming stuff (this is a class of problem you want to have). I have been playing with python's maths libraries (particularly sympy) lately, and along with jupyter it's pretty neat stuff.
A few examples:
There are clearly defined initiation rites for new employees that make them familiar with the engineering practices.
Focus is on a few key languages (C++, Java, Javascript, Python, Go) and code reviews are practiced over the team boundaries. This makes the knowledge transfer inside the company faster.
Changing your team and role regularly is encouraged.
Single, company-wide code tree and build system makes it easy to switch teams and make it possible to build very efficient tooling.
Coding style is strictly enforced to avoid petty fights and Google's very good coding styles guides include reasoning why certain choices were made.