먼저 현업에 뛰어든 아홉명의 이야기를 듣는다는 것은, 그 내용을 떠나서 일단 상당히 드문 기회라고 생각한다.

천재 개발자 L과 주기적으로 이 책에 대해 의견을 나누는 시간을 가지고 있는데 (사실 오늘이 첫 시간이었음), 굉장히 좋은 경험이었고 또 "여전히 주관이 많이 부족하구나"라는 부분을 느꼈다. 상당히... 무비판적으로 읽은 것 같다, 이 책은.

독서 모임을 어떻게 진행해야 하는가

스터디라고 보긴 좀 애매하지만 다음과 같은 세 단계면 좋을 것 같다.

• 책을 다 읽는다. 읽으면서 좋은/나쁜 구절이 있는 페이지에 인덱스 스티커를 붙이고 필요할 경우 추가적인 메모까지 해둔다.
• 1주일 텀을 두고 책의 감상을 이렇게 블로그에 남긴다.
• 1주일 텀을 두고 그 책에 대하여 이야기를 시작한다.

이 프로세스는 책 전체에 대해서 시행할 수도 있고, 몇 덩어리로 쪼개서 시도해 볼 수도 있다. 그러나 어느 쪽을 택하던 일반적으로 다른 참가자들에게 공지하는 시간보다 훨씬 먼저 읽어야 할 것이다.

에빙하우스의 망각곡선을 고려한 독서법이라고 할 수 있다.

좋았던 구절들

하나의 챕터에 적어도 하나의 구절은 찾아내려고 노력했다.

1장

• 전문가 = (코딩 능력 + 코딩 외적 능력) * 동기 * cosθ * 연대 : 동기에 cosθ 를 곱하는 것은 회사 목표와 얼라인을 시켜야 한다는 뜻이다. 천재 개발자 L도 이 부분에 (특히 연대 부분에) 공감하는 눈치였다.

2장

• 이해한 내용을 공유하라 (블로그, 컨트리뷰트) : 이걸 위해선 평소 업무 후에 자기가 배운걸 어떤 식으로든, 휘갈겨서라도, 정리해놔야 할 것 같다. 블로깅은 상당히 시간이 들어가는 작업이기 때문에 우선 뭘 배웠는지 정리해두는 작업이 분명 필요할 것이다. 그동안은 이걸 잘 못했다고 생각한다.

3장

• 애자일은 매우 빠른 폭포수 프로세스다 : L 은 이에 대해서 동의하긴 했으나 애자일의 정신(manifesto)에 대해서는 언급이 부족하다고 평가했다. 듣고보니 그런 것 같다.

• "코드 자체가 설계고 설계도이고 문서다"라고 이야기하는 개발자가 너무 많다 : 꽤 공감하는 부분이다. 코드는 비즈니스 맥락을 담아 보기엔 꽤 협소한 공간이라고 생각한다. 문서의 노후화와 코드/주석의 복잡함 사이에서 어떻게 균형을 맞춰야 하나? 문서에 신경써야 하는데 대체 그걸 어떻게 하면 좋은가. 잘 모르겠다.

• 소프트웨어의 설계에는 4가지 보이는 요소와 13가지 보이지 않는 요소가 있다. 이 모든 것을 고려해야 한다 : 누가 시키지 않아도 '이런 거'를 찾아서 체크하고, 적용하고, 기준으로 삼는 사람이 더 큰 책임과 힘을 가지게 되는 것 아닐까 하는 생각이 든다.

4장

• 오로지 내가 가는 속도만 중요하다.

• 수집한 자료를 분류했다. 당장 업무에 필요한 것, 업무와 관련은 없지만 살펴볼 것, 전혀 다른 분야.

• 개구리를 더 잘 이해하는 방법 하나는 개구리라고 부를 만한 수준의 무언가를 만들어내는 것이다.

• 다른 사람 피드백에 흔들리지 말고, 나에게 집중해서 나에게 맞는 방법으로 성취감을 얻어갑시다 : 상당히 찔리는 부분. 나는 여전히 남의 피드백을 걸러듣지 못하고 있다.

• 컴파일 오류에 익숙해지듯이, 실수도 두려워할 필요가 없습니다.

5장

• 기존 환경에서 변화 모색하기 먼저. 그 다음이 이직. 책임감 있는 마무리 잊지 말기.

6장

• Measure.
• 내가 뽑은 개발자의 7대 고민: (1) 목표를 못 정하겠어요 (2) 이직해야 될까요 (3) 성장하고 있는걸까요 (4) 신기술이 너무 많아요 (5) 창업하고 싶어요 (6) 개발이 너무 더뎌요 (7) 매니징을 잘 하고 있는걸까요 : 재밌어서 뽑아봄. 역시 나의 고민은 나만의 고민이 아니군.

7장

• 프로젝트의 후반부에선 핵심 목표가 필요합니다. 이 목표가 프로덕트의 완성도를 좌우하는 '디테일'을 결정합니다.

• 프로덕트에 대한 이해가 높은 사람은 어디서나 환영받습니다.

8장

• 상호 유대감을 얼마나 쌓아놓느냐가 일할 때 정말 중요하다는 사실에 누구나 동의하실 겁니다.

• 인간적인 신뢰를 쌓고 난 뒤에는 엔지니어링 영역에서의 신뢰를 쌓는 작업을 시작했습니다.

  • 여기엔 조금 다른 생각이 있음. 코딩을 잘하는 건 아주 중요하지만, 코딩을 잘한다고 인간적인 신뢰가 생기는 건 아니라고 생각한다. 완전 별개의 문제.

9장

• 좋은 코드는 유연성이 있습니다. 그러나 유연성이 있고 어려운 코드보다는, 유연성이 없고 쉬운 코드가 더 좋은 코드입니다 : 잊지 말자. 읽기 좋은 코드가 좋은 코드다.

• 개발을 직업으로 삼는 개발자에게 잘 동작하는 코드는 '제때 제대로' 동작하는 코드입니다 : 적정 기술은 코드의 모든 순간에 존재한다!

• 모든 것을 다시 발명할 필요는 없습니다. 그러나 바퀴를 다시 발명하는 일은 결과보다 그 과정에 더 큰 가치가 있습니다.