구글 엔지니어는 이렇게 일한다

프로그래밍은 수단이다.

가치 있는 변경을 받아들여라

소프트웨어 엔지니어링은 여러 선택지 사이에서 트레이드오프를 평가해야 한다.

때로는 확장성이 떨어지는 정책을 받아들여야 할 때도 있다.

투자 비용이 회수되기 시작할 때까지 회사가 살아남지 못할 수 있다.

하이럼의 법칙은 유지보수를 할 때 기억해야 하는 법칙인데. 내가 만든 API가 나의 의도와는 다르게 사용될 수 있다는 논리이다.

API명세에 있지 않은 기능을 쓴다면 '동작하는 코드'. 모범적으로 따른다면 '유지보수가 가능한 코드'

그 시절 최적화 기법이 유효한지는 알 수 없다.

구글의 인프라팀은 비욘세 규칙을 만들어 책을 덜 수 있었다.

인프라 업데이트는 자주 할수록 위험도가 떨어진다.

문제는 일찍 발견할수록 비용이 적어진다. 코드의 위험을 빨리 발견하기 위해서 여러 프로그램을 쓸 수 있다.

좋은 엔지니어링은 모든 자원에 적절한 가중치를 두는 것이다.

반드시 해야 할 일과 근거에 기반하여 당시에 내릴 수 있는 최선의 선택이 선택의 요인이 될 수 있다.

예시로 로컬 컴파일을 빌드팜으로 바꾸는 비용이 엔지니어가 노는 비용보다 적다면 바꾸는 것처럼 

효율이 좋아지면 자원 소비가 늘어난다.

프로그래밍은 코드를 만드는 즉각적인 행위이고 소프트웨어 엔지니어링은 협업을 가능하게 하는 정적, 관례, 도구를 아우르는 것이다. 

 

나 자신이라는 변수.

겸손 존중 신뢰

우리는 영감을 줄 영웅이 필요하다. 천재라고 해서 괴짜처럼 행동하고 용서받는 시대는 지났다.

가능한 일찍 실패하다.

질문하기 조차 어려운 문화라면 잘못되었다.

사회적 관계의 힘을 과소평가하지 말라

자존심을 버리기. 나는 내 코드가 아니다. 상대가 틀린 것이 아니라 내가 코드를 이해하는데 문제가 있는 듯한 겸손을 지녀라. 팀원은 동반자이지 경쟁자가 아니다.

 

모르는 것을 인정할 수 있어야 한다.

앵무새처럼 흉내 내지 마라.

답변뿐 아니라 질문하는데도 마음을 열고 모르는 것을 인정하라.

항상 배우고 항상 질문하라.

모르는 것이 나오면 성장할 기회이다.

왜 그 자리에 있는지 이해하라.

괴짜는 좋은 리더가 아니다.