I 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 have time to do so (if they do their work load is not full, increase the load). The 1% I guarantee all your codebase has just been stolen by an ex-employee with malicious attempt. Instead divide your codebase into different projects/roles and people only gain access when needed.
* Software engineers at Google are strongly encouraged to program in one of five officially-approved programming languages at Google: C++, Java, Python, Go, or JavaScript.
We use Go for backend programing and vue (javascript) for frontend. Don't use Java if possible, keep away from C++ and definitely never Python which is a maintenance nightmare.
* The next step is to usually roll out to one or more “canary” servers that are processing a
subset of the live production traffic.
Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage.
* All changes to the main source code repository MUST be reviewed by at least one other
engineer.
Same as above. Just build and RTFO.
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 have time to do so (if they do their work load is not full, increase the load). The 1% I guarantee all your codebase has just been stolen by an ex-employee with malicious attempt. Instead divide your codebase into different projects/roles and people only gain access when needed.
* Software engineers at Google are strongly encouraged to program in one of five officially-approved programming languages at Google: C++, Java, Python, Go, or JavaScript.
We use Go for backend programing and vue (javascript) for frontend. Don't use Java if possible, keep away from C++ and definitely never Python which is a maintenance nightmare.
* The next step is to usually roll out to one or more “canary” servers that are processing a subset of the live production traffic.
Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage.
* All changes to the main source code repository MUST be reviewed by at least one other engineer.
Same as above. Just build and RTFO.