Book “Software Engineering at Google”
https://arxiv.org/pdf/1702.01715.pdf
The most important chapters according to the content
- 2.1 Source Repository
- dev in “Head” of repo
- automated systems run tests frequently
- code ownership
- 2.2 Build system
- build results are cached in the cloud
- incremental rebuilds are fast
- 2.3 CR
- all changes to main source code MUST be reviewed at least by 1 eng
- CR discussions are automatically copied to a mailing list
- 2.4 Testing
- 2.5 Bug Tracker
- 2.6 Programming languages
- 1 of 5: C++, Java, Python, Go, JS
- Google style guides
- DSLs
- Protocol Buffers
- 2.7 Debugging and Profiling tools
- 2.8 Releasing Engineering
- Release often: weekly of once per 2 weeks
- Candidate build - to staging servers (small set of users)
- Canary servers
- gradual roll-out (couple of days)
- 2.9 Launch approval
- 2.10 Post-mortems (for outage)
- 2.11 Frequent rewrites
- Most software at Google gets rewritten every few years
- 3 Project management
- 3.1 20% time
- 3.2 Objectives and Key results (OKRs) - required!
- Results: 0.0 - 1.0 (quarterly).
- Desired overall score is 65% (goals is 50% more, than likely to accomplish)
- 3.3 Project approval
- 3.4 Corporate reorganization
-
- People management
- 4.1 Roles
- Engineering Manager always manage people. SWE - may also manage.
- Technical leadership vs people management
- Tech Lead lead projects
- EngMan - are responsible for selecting Tech leads and for performance of the teams, coaching, performance evaluation, compensation questions. 3-30 people, 8-12 is most common
- Research Scientist
- SRE
- Product manager
- Program Manager (like product managers, but manage projects, processes, operations)
- 4.2 Facilities
- 4.3 Training
- 4.4 Transfers
- 4.5 Performance appraisal and rewards