챕터1
Time and Change
- Software를 장기적으로 유지보수가능하게 하는 작업은 지속적인 전투(constant battle)이다.
Hyrum’s Law
- API의 충분한 사용자가 있는 경우, 주어진 계약에서 무엇을 약속하는지는 중요하지 않다. : 모든 관찰가능한 당신의 시스템의 행위가 다른 누군가에 의해 의존될 것이다.
- 엔트로피의 법칙이 참이지만, 계속 무질서도를 낮출려고 해야하듯이 우리가 개발한 API도 언젠가는 유저의 어플리케이션을 break할것이지만 API에 대한 변화가 그러한 breakage를 해결하고 식별하고 조사하는 어려움을 고려했을때 가치가 있어야한다.
- Programming의 관점에서는 clever는 칭찬이지만, Software Engineering 관점에서는 clever란 비난(accusation)이다.
- 버그해결이든 디자인 전환이든 개발초기단계에 적용하는것이 가장 비용이 적다.
챕터2
- 팀으로 일하는것이 얼마나 중요한가? 최근에 인사적인 충돌로 인해서 팀이 분리되었는데 좀더 화합하지 못한 이유를 돌이켜보면 의사 소통에 있어서 서로간에 Respect이 부족 하지 않았나 싶다. 서로 Respect하는 마음이 없으면 융화되기 어려울것같다. 한쪽이 소통의 의지가 있더라도 한쪽이 반응이 없으면 결국 융화되지 못하게 되는것 같다. 즉 변화될수 없는 사람과는 일하기가 참 힘든것같다. 면접때 스스로를 변화시킬수 있는지 완고한 사람은 아닌지 체크해보는것이 중요할것같다. 결국 사람들끼리 맞지 않는 부분이 생기고 스스로 변화시킬수 있는 능력이 있는 팀원들이 장기적으로 좋은 시너지를 낼수 있다는 생각이 든다. 결국 Repect한다는 것은 new working style을 improvise하려고 하는 인내와 willingness가 아닐까 생각이 든다. 최근에 읽은 애덤 그랜트의 Think Again이란 책도 생각이 난다.
- 인간관계가 프로젝트보다 더 오래간다는 말이 공감되었다. 뉴스테이트 데이터 팀에서 일했을때 사람들과의 관계만 봐도 그런것 같았다. 지금 함께 일하는 사람들과도 티타임하는 시간을 전혀 아깝게 생각하지 말아야 겠다.
챕터3
- 지식 공유에 대한 인센티브 부여가 부여될때 제대로 팀 문화가 될수 있는것같다. 현재 몸담고 있는 팀에서도 적용할수 있을까?