This book was given to me as a gift in the Google’s San Francisco office 5.5 years ago. I haven’t touch it all this time until recently. But this is fine - I would not understand it without a long working experience.
This book is not about C++ (and not even about development), but it can help you work in a team more effectively. It examines typical behavioral patterns of programmers, rules and principles of successful teams, and other things of the corporate world.
The book is really fine, there is no superfluousity in there. It is divided into micro-chapters, some of them turned out to be very familiar with that I encountered myself 😱
✏️ Efficient Meetings
So in order that meetings (as a “necessary evil” for many programmers) don’t become useless, it is better to obey the laws written in blood:
- At a meeting for designing something new, it is desirable to have no more than 5 people, because is difficult to hold a meeting with a larger number of people.
- If there are daily meetings (stand-up) where each member of the team speaks up, they should not be longer than 15 minutes.
- The meeting “interrupts” the context of the work, so it is advisable to put them near an “interrupt point”: right before/after lunch, at the end of the day, etc.
✏️ Working in a “Geographically Challenged” Team
If the discussion didn’t happen on the email list, then it never really happened.
✏️ Code Comments
Comments should be focused on WHY the code is doing what it’s doing, not WHAT the code is doing.
✏️ Be a Catalyst
In many cases, knowing the right people is more valuable than knowing the right answer.
About contacting other developers at the work.
✏️ Be Honest
The chapter tells about importance of constructive and understandable feedback, underlying uselessness of the shit sandwich. Many people simply do not understand or do not “read between the lines” so well, so you need to be straightforward if something needs to be changed in your colleague.
✏️ The Office Politician
The chapter about office rats among colleagues who can’t be trusted because they love getting promoted by claiming full credit for work and achievements that were actually done by you.
✏️ The Bad Organization
In many companies, the main product is not software, but rather something else (banks, food, clothes…), and programmers are just kind of support staff there. In such cases, the risk is higher that there are bad processes in the company - its common signs described in the chapter.
✏️ Learn to Manage Upward
The best chapter is about visibility. To get promoted, you need to show visible results around your work in the form of graphs, launching products, and so on.
All work is divided into two types - offensive (its results have visibility, it can be shown to the management) and defensive (refactoring/rewriting/database migration/technical debt/metrics - it is vital to do this, but its visibility is zero).
Although there is no way to work without doing defensive job, it does not give any points at the annual review. A quote:
A team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.
I would add this to the chapter: If you are only doing defensive work all the time, which obviously will not impress anyone at the review, then congratulations - you have been appointed a scapegoat!