실용주의 프로그래머 1. 실용주의 철학

1. 책임

실용주의 프로그래머는 경력에 대해 책임을 지고 자신의 무지나 실수를 인정하기를 두려워하지 않는다.
결과에 대해 책임을 진다는 것은 안좋은 결과가 나타났을 때 변명이 아닌 대안을 제시한다는 것과 같다.
단순히 안 된다고 할 것이 아니라 상황을 개선하기 위해 무엇을 할 수 있는지 설명해야 한다.

2. 소프트웨어 엔트로피

우주의 엔트로피는 점점 증가하는 방향으로 나아가듯, 소프트웨어도 커질수록 무질서도가 증가한다.
대신 소프트웨어는 잘 관리한다면 부패하지 않도록 할 수 있다는 점이 다르다.

소프트웨어의 관리는 사회 심리학에서 나온 깨진 유리창 이론에 빗대어 설명할 수 있다.
방치된 건물의 유리창이 하나가 깨지면 건물이 걷잡을 수 없이 망가지는 것처럼, 소프트웨어도 단 하나의 '깨진 창문'(잘못된 설계, 지저분한 코드)으로 인해 무너질 수 있다.
바꾸어 말하면, 깨진 창문이 보였을 때 바로 처리해 준다면 소프트웨어가 부패하지 않도록 막을 수 있다는 것이다.

3. 돌멩이 수프와 삶은 개구리

전쟁이 끝나고 군인들이 집으로 돌아가는 길에, 마을에서 음식을 얻어 먹으려 했으나 오랜 전쟁으로 인해 마을 사람들은 식량이 부족했고, 자신의 식량을 나누기를 꺼려했다.
군인들은 꾀를 내어 큰 냄비에 돌멩이와 물을 넣고 끓이자 마을 사람들이 이를 보고 궁금해하며 돌멩이만 넣느냐고 물어보았다.
그리고 군인들이 "당근을 넣으면 더 맛있어 진다"고 하자 당근을 가진 마을 사람이 당근을 가져와 이를 넣었고, 그 뒤로도 감자, 고기 등을 나열하자 주민들이 자신이 가진 것을 넣게 되었다.
결국 맛있는 수프과 완성되었고 모두가 함께 이를 나누어 먹을 수 있었다.

개발자는 이 이야기의 군인들처럼 행동해야 할 때가 있다.
무엇을 해야 하는지 알지만 일에 착수하려고 할 때부터 복잡함이 예상될 때, 돌멩이를 내놓는다.
이를 본 사람들에게 큰 무리 없이 요구할 수 있을 만한 것들을 요구해 받아낸다.
이제 받아낸 것들을 사용해 잘 개발하고 공개해서, 사람들이 자신이 원하는 기능도 추가해 달라고 부탁할 때까지 기다리면 된다.

그런데 마을 사람들의 시점에서 보면 이야기가 조금 달라진다. 돌멩이에 너무 집중한 나머지 그 외의 것들에 대해서는 신경 쓰지 못하고 있다.
개발자도 자신이 맡은 일에만 신경을 쓰다가 전체 프로젝트가 서서히 무너지는 것을 알지 못하고 방치하다가, 결국 프로젝트 자체가 파괴되는 경우가 있다.
따라서 발생하는 작은 변화를 감지하고 프로젝트 전체를 바라보는 시야를 가질 수 있도록 해야 한다.

4. 적당히 괜찮은 소프트웨어

완벽한, 버그 없는 소프트웨어를 만드는 것은 거의 불가능에 가깝다.
그래서 완벽한 소프트웨어를 만들기 위해 시간과 노력을 쓰는 것보다, '적당히 괜찮은' 소프트웨어를 만들어 사용자가 직접 사용해 볼 수 있도록 하는 것이 낫다.
대신 적당히 괜찮은지를 결정하는 것은 사용자이므로, 제대로 돌아가지도 않는 소프트웨어가 적당히 괜찮은 것은 아니다.

요구사항에서 품질을 결정하는 과정에 사용자를 참여시켜서, 어느 정도의 품질이라면 완벽하지 않더라도 사용자가 사용하고 싶어하는지를 파악해야 한다.

5. 지식 포트폴리오

개발자의 지식은 기한이 존재하는 것들이 많다. 새 기술이 나오면 지금까지의 지식을 활용할 수 없을 때도 있다.
따라서 개발자가 자신의 경력과 가치를 유지하기 위해서는 투자 포트폴리오를 관리하듯 지식 포트폴리오를 관리해야 한다.

• 주기적인 투자
  적은 시간이라도 꾸준히 지식에 투자하는 습관이 중요

• 다각화
  더 많은 기술에 익숙해질수록 변화에 더 잘 적응할 수 있다.

• 리스크 관리
  내가 지식을 갖고 있던 분야 자체가 망해 쓸모가 없어질 수도 있다. 기술의 스펙트럼을 다양화

• 싸게 사서 비싸게 팔기
  새로운 기술이 나오면 이를 초기에 학습하는 것은 리스크가 있을 수 있지만 대신 그 기술이 인기를 끌면 더 큰 이익을 가져다 준다.

• 검토 및 재조정
  기술의 부침은 역동적이다. 그 때마다 무엇을 새로 학습할지, 기존의 것을 복습할지 검토해야 한다.

6. 소통하라

아무리 뛰어난 기술이나 아이디어가 있어도 이를 제대로 타인에게 전달하지 못하면 없는 것이나 마찬가지이다.
개발자는 이러한 소통을 다양한 주체들과 해야 할 일이 많은데, 소통을 잘 하기 위한 아이디어의 목록은 다음과 같다.

• 말하고 싶은게 무엇인지 알아라
  그냥 생각나는대로 말하고 쓰는 것이 아니라 개요를 작성하고 무슨 말을 할지 미리 계획하는 것이 필요하다.

• 청중을 알아라
  정보가 제대로 전달되어야 소통이 이루어진다고 할 수 있다. 청중의 요구와 관심, 능력을 이해해야 정보가 전달 될 것이다.
  청중을 알기 위한 방법중 하나로 WISDOM을 사용할 수 있다.
  What: 무엇을 배우기 원하는지
  Interest: 어디에 관심이 있는지
  Sophisticated: 얼마나 소양이 있는지
  Detail: 어느 정도의 구체적인 내용을 원하는지
  Owe: 누가 정보를 소유하기 원하는지
  Motive: 어떻게 경청하도록 동기를 부여할 수 있을지

• 때를 골라라
  청중을 이해하더라도, 전달하려는 정보가 그들의 우선순위 밖이라면 효과가 없다.
  이야기하기 좋은 때인지를 파악하는 것도 중요.

• 스타일을 골라라
  전달하는 스타일도 청중에 따라 달라져야 한다. 이는 청중마다 다르므로 모르겠다면 물어보는 것이 나을 수도 있다.

• 멋져 보이게 하라
  아이디어를 설명하는 것도 중요하지만 어떻게 보여줄지도 생각해야 한다.

• 청중을 참여시켜라
  가능하다면 문서 초고에 독자가 참여하도록 해서 피드백을 받자.
  더 좋은 관계를 형성할 수 있고 더 나은 문서를 만들 수 있다.

• 청자가 되어라
  다른 사람이 내 말을 경청해 주기 바란다면 나도 경청해야 한다.
  정보를 전달하는 사람이 나 혼자일지라도 청자의 말을 귀기울여 들어야 한다.
  회의를 대화로 바꾸어 생각을 좀 더 효과적으로 전달할 수도 있다.

• 응답하라
  사소한 요청이라도 그냥 잊고 넘어가기보다 응답하는 것이 이따금 일어나는 실수에 대해 더 관대해질 것이다.