Feb 15
Culture at Google
Continuing from where I left off in the book Software Engineering at Google, the second part of the book is focused on the culture at Google and what makes the culture unique.
The first part of the book is focused on what is Software Engineering and you can find the notes on that chapter here.
Chapter 2: How to work well on Teams
The main influencer around the work that you are doing is “you” and hence we need to recognize our behavior around the core principles of trust, respect, and humility.
Don’t hide
We have seen certain traits in the software engineers i.e. hiding their code or hiding the product until it’s finished and polished. But hiding is considered harmful when you are working in a team. The more feedback you solicit early on, the more you lower the risk (not always though, get the rough idea on how you want to progress and the general direction of your goal). Early sharing isn’t just about avoiding personal missteps but it’s also important to consider the bus factor(number of people that need to get hit by a bus before your project is completely doomed) of your project.
It always helps to have a second pair of eyes when you are stuck on something and that fresh perspective can immediately show you where you have goofed up. Programming is hard, but software engineering is even harder. Even though are you afraid of someone stealing their idea or thinking you’re not intelligent, we should be more concerned about wasting the team’s time by working on the wrong thing.
Core principles and how to put them into practice
Lose the ego: Nobody wants to work with a person who behaves as if they are the center of the team. Think about going for “collective ego” instead and trying to build a sense of team accomplishment and team pride.
Learn to give and take criticism
Understand that in the software engineering world, most of the criticism/feedback that you receive is not at the personal level. Rather, it’s for improving the team environment and the deliverables. Also, try to imbue your feedback with respect to someone. It will show that you genuinely care for the person and really want to improve them. This also applies when you are on the other side of the conversation. Programming improves with practice. So, in a way, you are not what you write or what you code.
Fail-fast and iterate
Come up with totally unconventional ideas and shoot them down as fast as possible. Only when a concept cannot be debunked at the whiteboard level, can proceed to the next stage.
Blameless Post-mortem culture
Learn from your mistakes and perform the root-cause analysis. When you are doing this RCA, write down the post-mortem of the failure i.e. what did you learn from it, what is going to change as a learning experience. Most importantly, make sure that it’s easily accessible.
Learn Patience and be open to influence
Remember that it’s OKAY for someone else to change your mind given that they are presenting a piece of new evidence. Similarly, it’s OKAY to admit that you have made a mistake and it represents your humility, accountability, and willingness to take responsibility.
Being Googley
“Googleyness” is a set of attributes and behaviors that Google looks for that represent strong leadership and exemplify “humility, trust & respect”.
- Thrives in ambiguity
- Values feedback
- Challenge status quo
- Puts the user first
- Cares about the team
- Does the right thing
Chapter 3: Knowledge Sharing
Your organization needs a culture of learning, and importantly that requires creating a psychological safety net that permits them to admit to their lack of knowledge.
Software Engineering can be defined as the multiperson development of multi-version programs.
Growing your knowledge
You don’t become an expert overnight. You have to continuously grow your knowledge and the best way to do that is to ask questions and understand the context. Embrace not knowing things as an area of improvement.
As you move into the leadership roles, you realize that the more you know, the more you don’t know. [2]
Also if you don’t understand anything, try to understand the context behind it and figure out why one thing is done in that way and not the other way. Don’t change something until you don’t understand the rationale behind it. There may be a reason behind it and hence the context would play a big role in understanding that. At Google, rather than imposing style guides on devs, they also explain the rationale behind using them and why one style is preferred over the other.
Scale your questions
If you have some questions, it might be possible that some other person in the organization might have the same question. So when you have a question, write it down and once you get the answer don’t forget to update your question with the answer.
If you don’t know whom to ask, another option could be to ask in a group chat or in a mailing list. At Google, most topics have a topic-users@ topic-discuss@ mailing list.
They have also an internal version of Stack Overflow called YAQS(Yet-another-question-system) making it easy for Googlers to discuss confidential information as well as a link to the codebase.
Scale your knowledge
You always have something to teach and Google engineers teach others in a variety of ways i.e. discussion during office hours, giving tech talks, writing documentation, and reviewing the code.
These are just my observations and notes, reach out to me if you see any discrepancy or I have mistakenly written something wrong.
References:
