The Pragmatic Programmer

TPP 3. Provide Options, Don’t make Lame excuses

검토 결과 부정적일 때, 그냥 안된다고 하지말고 대안을 같이 제시하자. “이거 해 봤어?” “이거 고려했어” 같이 나올 수 있는 질문에 대해 미리 고민하고 대응할 것. 여기서 대응이란 질문에 대한 답을 제시할 수 있도록 미리 준비하라는 것. 실제로 고려해 보고, 실제로 시도해보고 나서 할 수 있으면 최고.

무조건 안된다고 하지 말고, 대안을 제시하자. 안된다고 말하기 보다는 그 문제를 해결하기 위해 뭘 할 수 있는 지 제시하자.

TPP 4. Don’t live with broken windows

잘못된 디자인, 잘못된 결정, 허접한 코드를 고치지 않은 형태로 두지 말아라. 발견했으면 반드시 조치를 해라. 필요하면 해당 코드를 코멘트로 막아버리고, 지원되지 않는다는 출력문을 내라. 차라리 그게 문제를 더 일으키는 것 보다 낫다.

이런 “깨진 유리창"이 있으면 코드를 개선할 생각을 안하기 마련이다. “어차피 이런 코드인데 뭐, 대충 작성하지 뭐"라는 생각을 갖게 한다.

반대로 잘 작성된 코드가 있으면 그 코드에 대해서는 신경을 쓰게 마련이다. 좋은 코드로 남도록 잘 다듬으려고.

TPP 4. Be a catalyst for change

돌 스프 혹은 개구리.
마을의 모든 사람들이 즐길 수 있도록 한 병사와 같은 촉매 역할을 할 것. 결국 모두가 승리하는 결과를 얻을 수 있다.

뭔가를 하려는데 사람들의 동의가 필요하고, 예산도 한정되어 있고, 복잡한 이해관계가 엮여있다. 이럴때는 우선 작은 걸 잘 만들어서 보여준다. 그리고 “여기에 이런 기능이 있으면 더 좋을 듯 한데"라며 별로 중요하지 않은 것처럼 말한다. 그리고는 그 기능을 해야 할 사람이나 예산을 가진 사람이 참여하고 싶어하는 걸 기다린다.
사람들은 성공하는 것에는 쉽게 참여한다(People find it easier to join on ongoing success)

TPP 6. Remember the big picture

마을 사람들 입장에서 보면 결과론적으로 모두 즐거운 식사를 했겠지만, 간과해서는 안되는 것은 작은 것(재료들)이 하나씩 투자되었다는 것을 눈치채지 못했다는 것이다.
때로는 작은 것들이 모여 morale과 팀을 깬다.

개구리가 되지 마라. 항상 큰 그림에 집중해야 한다. 꾸준히 내가 하는 것뿐만 아니라 주변에서 일어나는 것들을 검토해야 한다.

지나치게 완벽한 프로그램을 만들기 위해 노력하지 말라. 그럴 수도 없다. It may not be perfect. Don’t worry : I could never be perfect