뛰어난 프로그래머가 되고자 하는 마음이 있어야만 뛰어난 프로그래머가 될 수 있다. 이런 마음이 없는 사람은 아무리 훈련을 받아도 뛰어난 프로그래머가 될 수 없다.
- 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 더 중요하다.
소프트웨어에서 가장 신경 써야 할 부분은 미래다.
가장 인상깊게 읽은 부분이 바로 여기다.
애초에 개발자들의 불평을 무시하고 이들이 생각하는 문제가 무엇인지 알아내려 하지 않았다는 건 시작부터 적대심을 품었다는 말이다.
가장 먼저, 개발자가 생각하는 문제가 무엇인지 알아내라. 스스로 판단하지 마라. 사람들의 의견을 물어라.
생산성 담당자가 쌓은 개인적인 신뢰가 엔지니어링 생산성 업무에서 가장 중요하다.
처음에는 팀의 신뢰부터 얻어야 한다.
팀 문화나 개발 프로세스 전반에 대한 모든 걸 단숨에 바꿀 수는 없다. 본인의 계획을 점진적으로 적용하면서 그 과정에서 발생하는 변화의 '부작용'에도 현명하게 대처하라. 무언가 바뀌었다는 이유로, 전과 모든 게 달라졌다는 이유로, 변화를 위한 첫 시도가 아주 성공적이지 못했다는 이유로 사람들은 화를 낼 것이다. 다음 단계로 넘어가기 전에 주변 사람들이 변화에 적응할 때까지 기다려야 한다.
모두에게 완벽한 변화를 강요하지 마라. '아군'을 모집해서 코드 정리나 생산성 개선이 필요하다는 주장의 타당성을 인정받는 게 중요하다.
지속해서 리팩토링을 제안하는 것이 업무 문화를 바꾸는 데 가장 큰 역할을 하므로 사람들에게서 '우리는 작업할 때 항상 코드를 정리한다.', '코드 품질은 중요하다.' 등 자신이 원하는 문화를 구현하는 데 도움이 되는 원칙에 대한 공감을 끌어내라.
그룹 내 모든 사람에게 완벽한 동의를 얻을 필요는 없다.
자기 눈에만 보이는 문제 말고 사람들이 인지하고 있는 문제를 해결하라.
개발자가 문제로 여길 거라 추측하는 문제 말고 (a) 존재한다는 걸 확실히 증명할 수 있는 문제, (b) 존재한다는 사실을 개발자들도 인정하는 문제를 해결하라.
'컴퓨터 프로그래머'는 '목수'처럼 직업이 아니라 기술이다. 기술 사용 빈도는 생산성을 측정하는 기준이 될 수 없다. 생산성을 확인하려면 그 기술로 생산한 제품을 측정해야 한다.