코딩 호러의 이펙티브 프로그래밍 (제프 앳우드, 2013) 독후감

소프트웨어 개발에 대한 통찰력이 담긴 에세이. 스택오버플로를 만든 제프 앳우드가 쓴 책이다.

스택오버플로를 모르는 프로그래머가 있을까? 구글링 결과 죽돌이다. 내가 궁금한 걸 누군가 질문했고 누군가 답해놨다. Area51때문에 스택오버플로 시스템을 관심 있게 보고 있다. 그러다 보니 재프 앳우드가 어떤 사람인지 궁금하더라.

coding horror라는 유명한 블로그도 운영하고 있다. 예전에 지나쳤던 글을 차근히 읽어보고 싶었다. 그러다가 만난 이 책. 좋은 글을 선별했을 것이고 우리말로 번역돼 읽기도 더 수월하다.

이런 에세이를 읽으면 조엘 스폴스키가 생각난다. 감명 깊게 읽어서 비교를 피할 수가 없다. 읽는 동안 계속 생각이 났다. 조엘 아저씨 글을 읽으면서 느꼈던 감동을 이 책에선 느낄 수 없었다. 순서를 바꿔서 읽었으면 좋았을 걸.

PS. 코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기: 엉터리 개발자에서 벗어나 진정한 개발자로 거듭나라!(How to Stop Sucking and Be Awesome Instead) 이 책도 있네. 이 책을 읽을 걸 그랬나.

• 배를 만들고 싶다면 인부들을 재촉해서 나무를 끌어모으고 일을 분활해서 명령을 내릴 것이 아니라 그들이 저 넓고 끝없는 바다를 열망하게 만들어라. - 앙투안 드 생텍쥐페리 p40
• 기술적인 리더십의 가장 효과적인 모습은 예를 통해 리드하는 것이다. 개발과 관련된 리더 중에서 규율을 강제하기 위한 시간과 권위를 가지고 있는 사람은 거의 없다. 따라서 실제 행위만이 유일한 방법이다. p136
• 팀의 이익에 부합하지 않는 사람을 팀에서 제거하거나 혹은 심지어 해고하는 것을 두려워하지 말아야 한다. 기술은 개발할 수 있지만 긍정적인 태도는 개발할 수 없다. 한 프로젝트 내부에 이와 같이 문제를 야기하는 개인이 더 오래 머물수록, 그들이 낳은 부정적인 효과는 더 크게 퍼진다. p156
• 간단히 말해서 그들이 실험을 통해 발견한 것은, 최악의 팀원을 살펴보는 것은 해당 팀이 어느 정도의 성적을 거둘 것인가에 대한 최고의 척도가 된다는 사실이다. [.] 모든 것은 결국 최악의 팀원이 어떤 사람인가에 달려 있기 때문이다. p158
• 당신의 소프트웨어와 프로젝트는 결국 작은 디테일의 모음에 지나지 않는다. p205
• 다음에 UI를 디자인하게 된다면 반드시 사용자의 좁은 시야를 염두에 두어라. 사용자들의 시야가 얼마나 좁아질 수 있는지 깨달으면 놀랄 것이다. 필요한 내용을 바로 그들의 코앞에 놓아야 할지 오랫동안 치열하게 고민해야 한다. p226
• 알다시피, 안다고 알려진 것들이 있다. 우리가 안다고 아는 사실이다. 우리는 또 알고 있다. 모른다고 알려진 것들도 있다. 그것은 곧 우리가 알지 못하는 무엇인가가 있다는 사실을 알고 있는 것이다. 하지만 또한 아직 알려지지 않은 모르는 것도 있다. 우리가 모른다는 사실조차 모르고 있는 것들 말이다. - 도널드 럼스펠드 p242