[소트프웨어 엔지니어링] Software Engineering at Google 읽고 기록 _ Chapter 1, 2

Software Engineering at Google 원서를 매일 조금씩 읽고 있다. 읽다가 이대로 그냥 지나치기에는 아쉬운 부분들을 기록하려고 한다.

 

Software Engineering at Google

Curated by Titus Winters, Tom Manshreck & Hyrum Wright

 

 

1.

위치 : PART II Culture / Chapter 2: How to Work Well on Teams / The Genius Myth

The Genius Myth is the tendency that we as humans need to ascribe the success of a team to a single person/leader.

천재 신화는 우리가 인간으로써 팀의 성공을 한 개인/리더에게 돌리는 경향입니다.

ex) 예시로 나온 신화 인물들과 업적. 사실 이 업적들은 똑똑한 팀원들의 공동작업이다.

Linux - Linus Torvalds

Unix - Ken Thompson and Dennis Ritchie 

Python - Guido Van Rossum  

Steve Jobs - Macintosh

Bill Gates - BASIC interpreter , MS-DOS

Michael Jordan - The team’s coach, Phil Jackson. 코치의 능력으로 마이클 조던의 재능이 더 빛났다

 

Celebrity is a big part of it. Humans have a natural instinct to find leaders and role models, idolize them, and attempt to imitate them. We all need heroes for inspiration, and the programming world has its heroes, too.

유명인사는 이것(천재 신화)의 큰 부분이죠. 인간은 본능적으로 리더와 롤모델을 찾고 우상화하고 모방하려고 합니다. 우리 모두는 영감을 얻기 위해 영웅들이 필요하고, 프로그래밍 세계에서도 이것은 마찬가지죠. 

 

 

2.

위치 : PART II Culture /  Chapter 2: How to Work Well on Teams / Hiding Considered Harmful / Early Detection

If you keep your great idea hidden from the world and refuse to show anyone any‐ thing until the implementation is polished, you’re taking a huge gamble. It’s easy to make fundamental design mistakes early on. You risk reinventing wheels. And you forfeit the benefits of collaboration, too:

만약 당신의 훌륭한 아이디어를 세상에 계속 숨기고 구현을 완성할 때까지 그 누구에게 그 무엇도 보여주는 것을 거부한다면, 당신은 엄청난 도박을 하는 것입니다. 초기에는 설계 디자인 실수를 하기 쉽죠. 바퀴를 재발명할 위험이 있고요. 그리고 당신은 협업의 이점들을 놓치는 겁니다.

 

 

3.

위치 : PART II Culture / Chapter 2: How to Work Well on Teams / Hiding Considered Harmful / Pace of Progress

Requirements morph unexpectedly. How do you get that feedback loop so that you know the instant your plans or designs need to change? Answer: by working in a team. Most engineers know the quote, “Many eyes make all bugs shallow,” but a better version might be, “Many eyes make sure your project stays relevant and on track.”

요구사항들은 예기치 않게 변경됩니다. 계획이나 디자인이 변경되어야 하는 순간을 알기 위해서는 어떻게 피드백 루프를 얻어야할까요? 답은 팀으로서 일하는 것입니다. 대부분의 엔지니어들은 "많은 눈이 모든 버그들을 얕아지게 한다."라는 인용구문을 알지만, 더 나은 버전은 "많은 눈이 당신의 프로젝트를 적절하고 순조롭게 진행시킨다."일 것입니다.

 

 

4.

위치 : PART II Culture / Chapter 2: How to Work Well on Teams / It’s All About the Team / The Three Pillars of Social Interaction

To reach collaborative nirvana, you first need to learn and embrace what I call the “three pillars” of social skills.

협업의 열반에 이르기 위해서는, 먼저 필자가 사회 스킬의 "세 기둥"이라고 부르는 것을 배우고 받아들어야 합니다. 

 

Pillar 1: Humility
You are not the center of the universe (nor is your code!). You’re neither omnis‐
cient nor infallible. You’re open to self-improvement.

Pillar 2: Respect
You genuinely care about others you work with. You treat them kindly and
appreciate their abilities and accomplishments.

Pillar 3: Trust
You believe others are competent and will do the right thing, and you’re OK with
letting them drive when appropriate.

기둥 1 :  인간성

당신은 우주의 중심이 아니고 당신 코드도 그렇죠. 당신은 전지전능하지도 않고 오점이 없지도 않습니다. 당신은 자기 개선에 열려있습니다.

기둥 2:  존중

당신은 같이 일하는 다른 사람들을 진심으로 챙깁나다. 당신은 그들에게 친절하고 그들의 능력과 성취를 높이 평가합니다.

기둥 3: 신뢰

당신은 다른 사람들이 유능하고 일을 잘 할 것이라고 믿으며, 그들이 적기에 일을 이끄는 것이 괜찮아합니다.

 

 

5. 

위치 : PART II Culture / Chapter 2: How to Work Well on Teams / It’s All About the Team / Why Do These Pillars Matter?

Relationships always outlast projects. When you’ve got richer relationships with your coworkers, they’ll be more willing to go the extra mile when you need them.

관계는 항상 프로젝트보다 오래 갑니다. 동료들과 더 돈독한 관계를 맺을 때, 당신이 필요로 할 때 그들은 더 많은 것을 기꺼이 해 줄 겁니다.

 

 

6.

위치 : PART II Culture / Chapter 2: How to Work Well on Teams / It’s All About the Team / Blameless Post-Mortem Culture

The key to learning from your mistakes is to document your failures by performing a root-cause analysis and writing up a “postmortem,” as it’s called at Google (and many other companies).

실수로부터 배우는 중요한 핵심은 근본 원인을 분석하고 구글(과 다른 많은 회사들)이 "부검(사후 평가)"이라 부르는 글을 기록해서 당신의 실패를 문서화하는 것입니다.

 

A proper postmortem should always contain an explanation of what was learned and what is going to change as a result of the learning experience. Then, make sure that the post‐ mortem is readily accessible and that the team really follows through on the proposed changes.

제대로 된 부검은 배운 것과 배운 경험의 결과로 변경될 것들에 대한 설명을 항상 포함해야 합니다. 그러고 나서는 그 부검에 쉽게 접근할 수 있는지와, 팀이 문서에서 제안한 변경 사항들을 진짜로 따르는 지도 확인해야 합니다. 

 

A good postmortem should include the following:
• A brief summary of the event
• A timeline of the event, from discovery through investigation to resolution
• The primary cause of the event
• Impact and damage assessment
• A set of action items (with owners) to fix the problem immediately
• A set of action items to prevent the event from happening again
• Lessons learned

좋은 부검은 다음의 항목들을 포함해야 합니다.

- 짧은 사건 요약

- 발견부터 조사, 해결까지의, 사건의 타임라인

- 사건의 주요 원인

- 영향 및 피해 평가

- 문제를 즉시 해결하기 위해 행한 일련의 작업 항목들(과 담당자들)

- 다시 사건이 발생하는 것을 막기 위해 행한 일련의 작업 항목들

- 배운 경험들

 

위치 : PART II Culture / Chapter 2: How to Work Well on Teams / It’s All About the Team / Blameless Post-Mortem Culture / Be open to influence

Admitting that you’ve made a mistake or you’re simply out of your league can increase your status over the long run. In fact, the willingness to express vulnerability is an outward show of humility, it demonstrates accountability and the willingness to take responsibility, and it’s a signal that you trust others’ opinions. In return, people end up respecting your honesty and strength. Sometimes, the best thing you can do is just say, “I don’t know.”

당신이 실수했다는 것이나 당신의 전문 분야 밖 영역이라는 것을 인정하는 것은 장기적으로 당신의 지위를 높일 수 있습니다. 사실, 약점을 기꺼이 드러냈기에 겸손함과 책임감, 책임지려는 의지와 다른 사람들의 의견을 신뢰한다는 것이 드러납니다. 그 대가로, 사람들은 당신의 정직함과 힘을 신뢰하게 됩니다. 때때로 당신이 할 수 있는 최선은 단지 "잘 모르겠습니다."라고 말하는 것입니다.

 

Professional politicians, for example, are notorious for never admitting error or igno‐ rance, even when it’s patently obvious that they’re wrong or unknowledgeable about a subject. This behavior exists primarily because politicians are constantly under attack by their opponents, and it’s why most people don’t believe a word that politicians say. When you’re writing software, however, you don’t need to be continually on the defensive—your teammates are collaborators, not competitors. You all have the same goal. 

예를 들어, 전문 정치인들은 한 주제에 대해 잘못하거나 지식이 없는 것이 너무나 명백할 때에도 오류나 무지를 인정하지 않는 것으로 악명이 높죠. 이러한 행동은 주로 정치인들이 끊임없이 상대방으로부터 공격을 받기 때문에 나타나고, 이러하기에 대부분의 사람들은 정치인들의 말을 믿지 않습니다. 그러나 소프트웨어를 작성할 때에는 계속 방어적일 필요가 없습니다. 당신의 팀원들은 경쟁자들이 아니라 협력자들입니다. 당신들 모두 같은 목표를 가지고 있죠.