사랑하지 않으면 떠나라

"나의 직업을 진정 사랑한다면, 반드시 해야할 수칙을 소개하고 있다"

얼핏 제목만 보면 연애 또는 사랑에 관한 소설이라고 착각하기 쉽다. 하지만 이책은 엄연한 개발자를 주제로한 책이다.
이 책의 원 제목은 My Job went to India : 52 Ways to Save Your Job 이다. 나름 해석하자면, 인도로 간 나의 직업을 지킬 수 있는 52 가지 방법 정도가 되겠다.
IT 산업에 있어서 아웃소싱을 빼놓고서는 말이 안될 정도로 너무나도 당연한 개방 방법 중 하나다. 특히나 미국의 경우, 상대적으로 임금이 싸면서도 의사소통이 비교적 자유로운 인도로 개발부서를 이전하는 경우가 많다.
이 책의 저자 역시, 미국에서 인도로 이전한 개발부서에서 프로젝트를 이끌었던 경험을 살려 이 책을 저술했다. 이책의 특이할 만한 점이라면, 기존의 비슷한 자기개발서적과는 달리 IT 분야에 특화되었다는 점이라고 하겠다.
내 기억에 이런 부류의 책은 처음 이었을 듯 하다. 저자가 이 책에서 얘기하고 있는 바를 자신의 버릇 처럼 실행에 옮길 수 있다면 설사 모든 IT 가 해외로 이전한다고 해도 먹고 사는데 아무런 지장이 없을 것이다.

기억에 남는 구절

당신의 시장을 선택하라
수요와 공급
현재 기술적 숙련도에 대한 수요를 조사하라
직원 공모나 취업 웹 사이트를 사용해 어느 기술이 수요가 많고 적은지 알아보라. 해외 외주 회사들의 웹사이트를 찾으라(또는 해외 외주 회사 직원들과 일한다면 이야기를 나눠보라). 이 회사들에서 사용하는 기술과 자신이 수집한 수요가 많은 기술을 비교하라. 어느 기술이 국내에서 수요가 높고 해외에 거의 보급되지 않았는지 기록하라.
해외 외주 회사에서 사용하는 기술과 첨단 기술도 비교해 보라. 해외 회사들이 충분히 제공하지 못하는 기술들을 주목하라.
해외 회사들이 공백을 메우는 데 시간이 얼마나 걸릴까(만약 가능하다면)? 이 시간 차이가 시장 불균형이 존재하는 시간대다.

코딩만으로는 이제 충분하지 않다
비즈니스 담당자와 점심 약속을 잡으라
그들이 일을 어떻게 하는지 이야기를 나누라. 일과에 대해서 자세히 질문하라. 그들과 이야기하는 동안 그 일을 하고 싶은 포부가 생기면, 무엇을 배워야 하는지 무엇을 바꿔야 하는지 질문하라. 기술이 그들의 일에 도움이 됐는지(또는 일을 더디게 했는지) 이야기를 나누라. 그들의 관점에서 자신의 일에 대해 생각해보라. 그리고 이 일을 정기적으로 하라.
회사 업무와 관련된 업계 잡지를 고른다
아마 한 권도 사보지 않았을 것이다. 대부분의 회사에는 업계 잡지 과월호 모음이 있다. 잡지들을 하나하나 읽기 시작하라. 모든 내용을 이해할 수는 없겠지만 꾸준히 읽도록 한다. 경영진이나 비즈니스 고객에게 물어 볼 질문 목록을 만들라. 질문이 멍청해 보여도 고객은 여러분이 배우려고 한다는 것을 고맙게 여길 것이다.
업계 웹 사이트를 찾아 정기적으로 검토할 수 있다. 웹 사이트와 잡지에서 뉴스와 특집 기사가 무엇을 다루는지 특별히 주의해 보라.
업계에서 무엇을 하려고 애쓰는가? 현재 새롭게 뜨는 핫이슈는 무엇인가? 그게 뭐든 간에, 고객과 그에 대해 이야기하고 설명을 부탁하고 의견을 구하라.
현재 추세가 여러분이 일하는 회사, 부서, 팀, 결국에는 여러분의 일에 어떻게 영향을 미칠지 생각해 보라.

그냥 앞서 갈 것인가, 위험까지 무릅쓸 것인가
오늘날 시장에 근거해 채택할 기술 목록을 초기, 중기, 말기로 분류해 만들라. 만든 목록을 종이 위에 왼쪽에서 오른쪽으로 나열해 보라
왼쪽에는 최첨단 기술로, 오른쪽은 말기에 있는 기술로 채운다. 스펙트럼의 각 부분에 있는 기술을 가능한 한 많이 찾도록 노력하라.
기술들이 곡선에서 가능한 한 촘촘히 채워지도록 하라.
생각나는 대로 기술을 나열했다면 자신이 강한 기술에 표시한다. 그러고 나서 다른 색깔로 경험은 좀 있지만 전문적이지는 않은 기술에 표시한다. 채용 곡선에서 자신이 표시한 것들은 대부분 어디에 있는가? 모여 있는가? 고르게 여기 저기 흩어져 있는가? 곡선 끝에 특별히 관심 있는 기술들이 있는가?

지성에 투자하라
새 프로그래밍 언어를 배우라
그러나 자바를 배우다가 C# 을 배운다거나, C 를 배우다 C++ 를 배운다거나 하면 안된다.
새 언어를 배우면 새로운 방식으로 생각할 수 있게 된다. 자바 또는 C# 프로그래머라면 강 타이핑(strong typing), 정적(static) 타이핑을 쓰지 않는 스몰토크나 루비를 배워 보라. 또는 오랫동안 객체지향 프로그래밍을 해왔다면 해스켈(Haskell)이나 스킴(Scheme) 같은 함수형 언어를 시도해 보라.
전문가가 될 필요는 없다. 새 프로그래밍 환경의 차이점을 정확히 느낄 만큼 코드를 충분히 하나하나 살펴보라. 그다지 낯설게 느껴지지 않는다면 엉뚱한 언어를 골랐거나 옛 사고방식을 새 언어에 적용하고 있는 것이다. 자신의 방식에서 벗어나 새 언어의 표현 방식을 배우라. 멘토나 선배에게 자신의 코드를 검토하게 해보고, 그 코드가 해당 언어의 표현 방식에 걸맞는지 조언을 해달라고 부탁하라.

다재다능한 사람이 되라
종이나 화이트보드에 자신의 지식과 능력 중에 다재다능한 부분과 그렇지 않은 요소를 나열하라
각 요소에 자신의 특기를 적는다. 예를 들어 플랫폼과 운영체제가 여러 요소 중 하나라면 그 옆에 윈도/닷넷을 쓰면 된다. 이제 적어놓은 특기 오른쪽에 배울 것 목록에 넣을 주제를 하나 또는 그 이상 쓰라. 앞에서 든 예를 다시 들면 리눅스와 자바(또는 루비나 펄)를 쓰면 될 것이다.
가능한 빨리(늦어도 이번주 중에) 30분을 할애할 목록에 있는 '배울것 To-Learn' 항목 중 최소한 하나를 다루기 시작해본다. 그것을 눈으로 보지만 말고 가능하다면 실제로 다루어보라. 웹 기술이라면 웹 서버 패키지를 다운로드해 스스로 셋업해보라. 비즈니스 관련 주제라면 회사 고객을 만나 점심을 같이 먹으면서 대화를 나누라.

진정한 전문가가 되라
컴파일 방식이면서 가상 기계 위에서 동작하는 프로그래밍 언어를 사용하는가? 그렇다면 시간을 들여 가상 기계가 어떻게 동작하는지 내부 구조에 대해 공부해보라.
자바, 닷넷, 스몰토크에 대해 많은 책과 웹 사이트에서 다루고 있다. 생각보다 배우기 쉬울 것이다.
자신이 사용하는 언어가 가상 기계에 의존하든 그렇지 않든 시간을 들여 소스 파일을 컴파일할 때 무슨 일이 일어나는지 공부해보라.
입력한 코드가 사람이 읽을 수 있는 텍스트에서 컴퓨터가 실행할 수 있는 명령으로 어떻게 바뀌는가?

자신의 달걀을 전부 다른 사람의 바구니에 넣지 말라
작은 프로젝트를 두 번 정도 해보라
처음에는 잘 아는 기술로 하고 두번째는 경쟁 기술로 하되 그 기술의 독특한 방식을 사용해보라.

가장 못하는 사람이 되라
'가장 못하는 사람이 되는' 상황을 스스로 찾으라.
더 나은 사람과 일하고 싶다는 이유만으로 팀이나 회사를 바로 옮기는 사치를 누리긴 쉽지 않을 것이다. 대신 다른 개발자들과 함께 일해서 삼투 현상처럼 자신의 성장에 도움이 될 만한 자원 프로젝트를 찾아보라. 자신이 사는 도시에 개발자 그룹 모임이 있는지 조사해보고 모임에 참가하라. 개발자들은 흔히 새 기술을 연습하고 자신의 기술을 연마할 여가 프로젝트를 찾을 때가 있다. 활발한 개발자 커뮤니티가 부근에 없다면 인터넷을 활용하라.
자신이 감탄하고 있고, 그 프로젝트 개발자들의 수준이 자신이 이루려는 '높은 단계'에 있는 것처럼 보이는 오픈소스 프로젝트를 하나 고르라.
프로젝트의 할 일 목록이나 메일링 리스트 아카이브를 조사해 기능 구현이나 주요 버그 수정 사항을 골라 해당 코드를 짜라! 프로젝트 코드의 스타일을 흉내내라. 게임을 하듯이 재밌게 하라. 자신의 설계와 코드를 프로젝트의 나머지 코드와 구별할 수 없게 만들면 원 개발자라도 누가 그 코드를 썼는지 기억할 수 없을 것이다. 그 다음에 자신의 작업에 만족하면 패치로 제출하라. 패치가 좋다면 프로젝트에 받아들여질 것이다. 같은 과정을 처음부터 반복한다.
프로젝트 개발자들이 동의할 수 없다는 결정을 한다면 개발자들의 멘토링을 받아들여 다시 제출하거나 개발자들이 바꾼 것에 주목하라.
다음 패치를 낼 때는 재작업하는 양을 줄여보라. 언젠가는 신뢰할 수 있는 프로젝트의 팀원이 될 것이다. 목소리를 들을 기회조차 없지만 멀리 떨어져 있는 선배 개발자들로부터 놀랄 만큼 많은 것을 배우게 될 것이다.

자신에게 투자하라
물고기 낚는 법을 배우라
'어떻게' 와 '왜'
이책을 읽으면서 직장에서 자신의 업무 중 완전히 이해하지 못한 측면에 대해 생각해보라.
애매한 부분까지 파고들어 가야할 특정 분야에 대해 다음과 같은 두가지 쓸만한 질문을 자신에게 할 수 있다.
바로 '어떻게 동작하는가?' 와 '왜 이런 현상이 생기는가(일어나야 하는가)?' 이다.
질문에 대답하지 못할 수도 있지만 질문을 하는 그 행위 자체로 사고의 틀이 새롭게 짜일 것이고 작업 환경에 대해 더 높은 수준으로 의식할 수 있게 된다.
'어떻게 해야 IIS 서버가 내 ASP.NET 페이지에 요청을 넘길까?' '내 EJB 애플리케이션에 쓸 인터페이스와 배치 디스크립터들은 왜 생성해야만 할까?' '내가 쓰는 컴파일러는 동적링킹과 정적링킹을 어떻게 처리하나?' '고객이 몬태나에 사는데 왜 세금을 다르게 계산할까?'
물론 이 질문들에 대해 대답하면 또 다른 질문이 생길 수도 있다. '어떻게' 와 '왜' 라는 질문을 계속할 수 없다면 아마 충분히 이해했다고 볼 수 있다.
팁 시간
자신의 도구 중에서 중요하지만 소홀히 하는 도구를 하나 골라 집중하라. 버전 제어 시스템일 수도 있고 광범위하게 쓰지만 피상적으로 알고 있는 라이브러리이거나 프로그램을 짤 때 쓰는 편집기일 수도 있다. 도구를 골랐다면 매일 시간을 들여 자신의 생산성을 높여주거나, 개발환경을 더 잘 제어할 수 있게 해줄만 한 새로운 것을 공부하라.
예를 들어 GNU Bash 를 숙달하기로 했다고 하자. 일하다가 아무 때나 슬래시닷을 보지 말고 인터넷에서 '배시 팁'을 찾아보라. 1,2 분이면 쉘 사용법에 대해 몰랐던 '유용한 것'을 찾을 수 있을 것이다. 물론 새 요령을 하나 배웠기 때문에 '어떻게' 와 '왜' 라는 질문을 계속하면서 더 깊게 파고들 수 있다.

비즈니스의 기본을 이해하라
비즈니스 입문서를 사서 꼼꼼히 공부하라
좋은 개론서를 찾는 요령으로는 MBA 학위를 따는 데 필요한 책을 찾는 것이다. 특히 유용한(그리고 기쁘게도 얇은) 책으로는 The Ten-Day MBA 가 있다.
실제로 10일 만에 다 읽을 수 있다. 대단히 큰 투자가 아니다.
회사 또는 부서의 재무 상황에 대해 설명해 줄 만한 사람을 찾으라
회사에서 직원들과 공유하기를 꺼려하지 않는 정보라면.
가르쳐 준 사람에게 배운 것을 다시 설명해보라
'맨 아랫줄' 이 왜 당기순손익을 의미하게 됐는지 알아보라.

멘토를 찾으라
나 자신의 멘토가 되어보자
우리 모두에게 적극적으로 멘토링을 해주는 사람이 있다면 이상적이겠지만 현실은 우리가 있는 곳에서 이 역할을 할 수 있는 사람을 항상 찾을 수 있는 것은 아니다.
이제부터 스스로 멘토가 되는 방법을 살펴보자.
자신의 분야에서 가장 존경하는 사람을 생각해낸다. 대부분의 사람들이 경력의 어떤 단계에 이르면 간략하게 정리한 인물 목록 하나쯤은 갖고 있다.
함께 일한 사람일수도, 존경할만한 일을 한 사람일 수도 있다. 이 역할모델의 가장 중요한 특성 열가지를 나열한다. 역할 모델로 선택하게 된 그들만의 특성을 가려낸다.
이러한 특성은 기술 습득 폭 같은 기술의 특정 분야 또는 특정 영역에 대한 지식의 깊이일 수 있다. 또는 팀원을 편안하게 만드는 능력이거나 매력 있는 강연자 같은 좀 더 개인적인 특성일 수 있다.
이제 이 특성들을 중요도 순으로 순위를 매긴다. 1 이 가장 덜 중요한 것이고 10 이 가장 중요한 것이다. 여러분은 존경할 만하고 중요하다고 생각하는 특성 목록을 방금 뽑아 만들었다. 이런 방식으로 선택한 역할 모델을 닮기 위해 애쓰면 된다. 그러나 무엇에 먼저 초점을 맞출지 어떻게 고를까?
목록의 각 항목에 열을 추가한다. 자신의 역할 모델이 자신에게 어떻게 등급을 매길지(10점 만점) 상상해 본다. 진짜로 역할모델의 마음으로 제3자인 것처럼 자신을 관찰해본다.
특성, 순위, 등급을 다 기록했으면 마지막 열에는 순위에서 등급을 뺀 값을 적는다. 어떤 특성의 순위가 10, 즉 역할모델의 가장 중요한 특성이고 자신의 등급이 3 이라면 최종 우선 순위 점수는 7 이다. 이 열을 다 채우고 내림차순으로 정렬하면 자신이 개선할 필요가 있는 영역의 우선 순위 10 위 목록이 나온다.
1,2 위 또는 1~3 위 항목부터 시작하여 자신을 향상시키기 위해 당장 시작할 수 있는 구체적인 일의 목록으로 만든다.

멘토가 되라
도움을 줄 만한 사람을 찾으라
회사에서 경험이 부족하거나 나이 어린 사람을 찾을 수도 있다. 아마도 신입이나 인턴사원일 것이다. 또는 대학의 정보통신학부나 컴퓨터공학부에 문의해 학부 학생들에게 멘토링을 해주는 일에 자원할 수도 있다.
온라인 포럼을 찾아 주제를 고르고 참여하여 돕기 시작하라
배우고자 하는 사람들에게 열정을 갖고 참을성 있게 그리고 능력껏 도우라.

연습 연습 또 연습
탑코더(TopCoder)
TopCoder.com 은 여러 해 동안 계속된 프로그래밍 겨루기 사이트다. 계정을 등록하면 온라인에서 시합을 통해 상을 받을 수 있다.
다른 사람들과 겨루는 데 관심이 없더라도 TopCoder 에서는 상당한 양의 연습문제를 갖춘 연습실을 제공하므로 아주 좋은 소재로 활용할 수 있다. 참여해보라.
코드 카타(Code Kata)
Pragmatic Programmers 의 데이브 토머스는 코딩 연습이라는 아이디어에서 아주 실용적인 것을 만들어냈다. 데이브는 코드 카타라는 연재물을 쓴 것이다.
코드 카타는 작지만, 뇌를 자극하는 연습 문제로서, 프로그래머는 자신이 선택한 언어로 문제를 풀 수 있다. 각 카타는 특수한 기술이나 사고 과정을 강조해 사고 능력을 구체적으로 단련할 수 있는 기회를 제공한다.
이 글을 쓸 당시 데이브는 카타 21 개를 만들어 자신의 블로그(http://codekata.pragprog.com/codekata)에 공짜로 공개했다. 블로그에서 메일링리스트 링크, 문제에 대한 또다른 해답, 문제 푸는 방법에 대한 토론을 볼 수 있을 것이다.

일하는 법
소프트웨어 개발 방법론 한가지와 책 한권을 고르고 웹사이트를 보기 시작한다. 그리고 메일링 리스트에도 가입한다. 방법론은 비판적인 눈으로 보라. 어떤 것이 장점이고 약점이라고 생각하는가? 자신이 일하는 곳에서 실행하는 데 무엇이 장벽이라고 생각하는가? 또 다른 방법론을 골라 똑같이 해본다.
그것들의 장점과 단점을 비교하라. 그 방법론들의 접근 방식을 어떻게 묶을 것인가?

거인의 어깨 위에서
프로젝트 하나를 골라 책 읽듯 읽는다
기록을 하면서 장단점의 윤곽을 잡는다. 비평을 써서 발표한다.
해당 프로젝트에서 이용할 수 있는 요령이나 패턴을 최소한 하나라도 찾는다. 관찰하면서 최소한 나쁜 점 하나를 찾아 소프트웨어를 개발할 때 '하지 말아야 할 일' 점검표에 추가한다.
의견이 같은 사람들을 찾아 한 달에 한번씩 만나라
만날때마다 각자 공부할 코드(2~200줄)를 추천한다. 코드를 나눠 코드 이면에 있는 것에 대해 토론한다.
그렇게 한 결정에 대해 생각해본다. 없는 코드에 대해서도 깊이 생각해본다.

자동화 기술을 이용해 일자리를 찾으라
평소에 되풀이 되는 작업하나를 고르고 그 작업에 대한 코드 생성 프로그램을 하나 짠다. 단순하게 시작한다. 재사용성에 대해서는 걱정하지 말라
코드 생성 프로그램 때문에 시간을 절약할 수 있다고 확신만 하면 된다. 여러분이 만드는 추상화 수순을 높이는 방법에 관해 생각해보라.
MDA(Model Driven Architecture) 에 대해 조사하라
몇 가지 사용할 수 있는 도구를 써보라. 자신의 일에 전부가 아니더라도 MDA 의 개념을 적용할 수 있는 부분이 있는지 찾아보라.

실행
지금 바로
지금까지 해온 일을 돌아보라. 오랫동안 덮어두고 있는 작업을 점검하라. 곰팡이가 슬기 시작하는 프로젝트는 없는가? 프로젝트가 관료주의나 분석 마비 상태에 빠져 있을 지도 모른다. 평상시 일과 중 틈틈이 할 수 있는 일을 찾으라. 예를 들어 평소에 웹을 보거나 이메일을 확인하거나 점심을 오래 먹거나 하는 때가 있을 것이다.
여러달 걸리는 프로젝트를 1 주일 안에 할 수 있는 작업으로 바꿔보라.

마음 읽기

칼 브로피는 "다음 프로젝트나 유지보수해야 할 시스템을 위해 사용자나 관리자가 요구할 것 같은 것에 대해 노트에 기록하라" 고 제안했다. 창의적이어야 한다.
사용자와 관리자의 관점에서 시스템을 보라. 그다지 중요하지 않은 기능 목록이 나왔다면 어떻게 해야 각 기능을 가장 효과적으로 구현할 수 있을 지에 대해 생각해보라.
사용자가 당장은 마음에 두지 않지만, 발생가능한 극한 적인 상화에 대해서도 생각해보라.
프로젝트나 요구 개선 작업을 시작하면서 적중률을 추적해보라. 추측한 것 중에 몇가지 기능을 구현해달라고 실제로 요구받았나?
추측한 기능이 나왔을 때 브레인스토밍 시간에 제안한 아이디어를 사용할 수 있는가?

매일의 성과
시간표에서 30 분을 비워두고 그 시간에 연필과 종이를 들고 방해받지 않을 조용한 곳에 가 앉으라
팀에서 매일같이 참아야 하는 시시콜콜한 문제에 대해 생각해보라. 그 문제들을 적는다. 업무시간을 매일 몇 분씩 낭비하지만 아무도 그것에 대해 뭔가를 하려고 하지 않는, 그 성가신 일은 무엇인가?
현재 프로젝트에서 자동화할 수 있지만 수동으로 하고 있는 것은 무엇인가?
그것들을 적는다. 자신의 빌드나 배치 프로세스는 어떤가? 깨끗이 정리할 것은 없는가? 빌드시 생기는 실패를 어떻게 줄일 수 있을까? 이에 대한 생각들을 모두 적는다.
20 분동안 차분하게 생각해보라
좋든 나쁘든 자신의 모든 구상을 적는다. 20 분이 되기 전에 그만두지 말아야 한다. 목록을 만든 후 새 종이에 좋아하는 다섯 가지 항목을 적는다.
다음 주 월요일에 목록에서 첫 번째 항목을 골라 그것에 대해 무언가를 하라. 화요일에는 두 번째 항목을, 수요일에는 세번째 항목을 한다.

누구를 위해 일하는지 기억하라
관리자와 회의 일정을 잡으라. 의제는 관리자가 세우고 월별, 분기별, 연도별 목표를 이해하는 것이다.
변화를 어떻게 가져올 수 있을지 물어보라. 회의 후 자신의 일과를 팀의 목표에 어떻게 맞출 것인지 따져보라.
관리자의 목표를 자신이 하는 모든 일에 대한 거르개로 삼으라. 이 목표에 바탕을 두고 자신의 일에 우선순위를 매기라.

오늘은 얼마나 잘할 수 있을까?
눈에 띄게 하라. 지겨운 일을 가지고 동료들과 경쟁해보라. 누가 그일을 더 잘하는지 본다. 단위 테스트 짜기가 싫은가? 날마다 체크인하는 코드에 대한 테스트 단언(assertion)수를 인쇄하라. 그리고 그것을 칸막이벽에 걸라. 전체 팀원용 점수판을 계속 걸어둔다. 자랑할 권리를 놓고 경쟁하라.
프로젝트가 끝났을 때 우승자에게는 그 사람의 허드렛 일을 한 주 내내 다른 팀원들에게 시킬 수 있게 한다.

자신이 얼마나 가치가 있는가?
회사가 투자를 할 때는 가능한 한 가장 좋은 방법으로 돈을 쓰려고 한다. 투자 수익률을 단순하게 계산하는 것을 현명한 결정이라고 볼수는 없다. 다른 여러 요소 중에서 회사는 인플레이션, 기회비용, 리스크를 고려해야 한다. 화폐의 시간적 가치라는 개념은 경영 대학원을 다니지 않은 개발자들에게는 특히 이해하기 어렵다.
지나친 단순화의 위험이 있지만 다음과 같이 설명할 수 있다. 오늘의 1 달러는 내년의 1 달러보다 더 가치 있다. 오늘의 1 달러로 더 많은 돈을 버는 데 쓸 수 있기 때문이다.
대부분의 회사에서는 회수율을 결정하고 그 아래로는 투자하지 않는다. 투자는 합의된 기간 내에 합의된 이익을 내야한다. 그렇지 않으면 투자를 하지 않는다. 이 수치를 최소 기대 수익률이라 한다. 회사의 최소 기대 수익률을 알아내고 여러분의 봉급에 적용해보라. 여러분은 좋은 투자 대상인가?

물 양동이 속 자갈
만들었거나 유지보수하는 코드와 수행하는 모든 태스크를 목록으로 만들라. 팀에서 전적으로 자신에게 의존하는 것에 대해 기록한다. 자신이 애플리케이션 배치 프로세스를 완전히 이해하는 유일한 사람일 수도 있다. 또는 자신이 짠 코드 중 일부가 특히 어려워서 나머지 팀원들이 이해하기 힘들 수도 있다.
이 각각의 항목을 할 일 목록에 적는다. 각각의 코드나 일을 문서로 만들고, 자동화 하거나 리팩터링해 팀원 누구나 쉽게 이해할 수 있게 하라.
이 목록이 다 없어질 때까지 이 일을 하라. 팀의 리더 그리고 팀원들과 문서를 적극적으로 공유하라. 문서는 어딘가에 반드시 저장해 팀원들이 쉽게 볼 수 있게 해야 한다.
이 연습을 정기적으로 되풀이하라.

유지 보수를 즐기라
측정하고 개선하고 또 측정하라.
자신이 유지보수하는 가장 중요한 애플리케이션이나 코드에 대해 애플리케이션의 품질을 나타내는 측정 요소의 목록을 만든다. 애플리케이션 응답시간 혹은 프로세스에서 생긴 처리하지 못한 예외일 수도 있다. 그러나 지원 업무를 직접 한다면 애플리케이션 품질 문제에 대해 직접 언급하지 말라.
지원 응답 소요시간은 애플리케이션에 대한 사용자 경험의 중요한 부분이다. 이렇게 측정할 수 있는 속성 중 가장 중요한 것을 골라 측정하기 시작한다.
기준이 되는 측정법을 마련한 후 현실적인 목표를 세우고 애플리케이션의 성능(또는 자신의 성과)을 개선해 그 목표를 채운다.
개선한 후 다시 측정해 바라던 개선을 정말 했는지 검증한다. 개선 했다면 팀, 고객과 공유하라. 또 다른 측정기준을 골라 다시하라.
첫 번째 과정을 거친 후로는 게임처럼 재미있어질 것이다. 이처럼 뭔가를 눈에 띄게 향상시키는 것은 중독성이 있다.

"아니오"라고 말하라
평론가 칼 브로피는 지켜야 할 모든 약속을 목록으로 만들 것을 제안한다.
만기일 까지 뭘 하도록 요구 받았나?
무슨 약속을 했나?
자신이 무시당했다면 자신이 생각했던 것과 받아들여진 것을 둘 다 기록하라.
언제 마무리 했는지 기록하라.
이것을 매일 연습하라. 실패할 것 같으면 바로 이야기 하라. 이것을 다달이 연습하라. 적중률은 얼마인가? 옳은 때는 얼마나 자주 있나?

마케팅은 높으신 분들만 하는 게 아니다
인식이 대수롭지 않다고?
인식은 대상이 누구냐에 따라 여러 요소에 좌우된다. 어머니는 여러분이 객체지향 시스템을 얼마나 잘 설계할 수 있는지 별로 신경쓰지 않지만 팀 동료는 신경 쓸 것이다.
각각의 관계에서 무엇이 중요한지 이해하는 것은 서로 영향을 주고받는 사이에서 신뢰할 수 있는 인식을 쌓는데 중요한 부분이다. 사무실에서 사람들과 맺는 서로 다른 유형의 관계에 대해 생각해보라. 이를 테면 같은 일을 하는 동료가 있을 것이다. 직속 관리자가 있고 한 명 이상의 고객과 프로젝트 관리자도 있을 것이다.
이 서로 다른 집단들을 목록으로 만들라. 각 집단 목록 옆에 그 집단에서 여러분이 어떠한 모습을 보고 인식할지 한번 적어보라. 예를 들면 다음과 같다.
집단 인식에 영향을 미치는 요소
동료 기술적 숙련도, 사회 적응도, 팀워크
관리자 지도 능력, 고객 중심, 의사 소통 기술, 임무 완수, 팀워크
고객 고객 중심, 의사 소통 기술, 임무 완수
프로젝트 관리자 의사 소통 기술, 임무 완수, 생산성, 기술적 숙련도
자신의 목록을 보며 잠시 생각해보라. 이 목록의 결과로 자기 행동을 어떻게 바꾸겠는가? 각 집단과 일할 때, 자신이 집중해야할 점은 어떤 방식으로 조정했는가?
어떤 방식을 썼을 때 자신의 행동을 적절하게 조정하였는가?

모험 여행 안내자
자신을 점검하라
여러분은 모두가 두려워하는 심술궂고 고루한 도깨비인가? 확실한가? 사람들이 말하기를 두려워하는 건 아닌가?
편지함을 조사해 기술에 대해 잘 알지 못하는 동료, 관리자, 고객에게 보낸 전자우편들을 찾으라. 읽으면서 받는 사람의 관점에서 보라.
메세지를 보내고 시간이 좀 지났다면 제 3 의 관찰자로서 자신을 볼 수 있을 것이다. 더 좋은 방법은 그 전자우편을 어머니에게 보여주는 것이다.
함께 일하는 어떤 사람이 고객에게 보낸 메세지라고 말하고 어머니가 메세지를 보고 어떻게 느끼는지 물어보라.
벽을 뛰어 넘으라
자신이 전문가가 아니어서 전문가에게 의지해야 하는 상황에 처할 수도 있다. 왼발만 두 개인 자신이 축구팀 일원이라고 상상해보라.
왼쪽 엄지만 두 개인 자신이 국가대표 뜨개질 팀 일원이라고 상상해보라. 팀 통료들이 자신과 어떻게 의사소통하길 바라겠는가?

나를 정말 글이 잘 정말 써...
개발 일기를 쓰기 시작하라
매일 조금씩 쓰면서 뭘 했는지 기록하고, 설계 설정에 대해 타당성을 증명하고 어려운 기술적 또는 전문적 결정을 자세히 조사하라.
자기 자신만 보는 것이라 하더라도 자신의 입장을 분명하게 표현할 수 있도록 작문의 품질과 능력 향상에 주의를 기울이라. 이따금 옛글을 다시 읽고 비평해보라.
옛 글에서 좋았던 것과 나빴던 것을 바탕으로 새글을 수정하라. 이러한 일기를 통해 글쓰기가 개선될 뿐만 아니라 자신이 내린 결정을 좀더 잘 이해하는 데 이용할 수 있다.
또한 과거에 어떤 일을 왜, 어떻게 했는지 다시 봐야할 필요가 있을 때 참고 할 수도 있다.
타자를 능숙히 칠 수 있도록 배워라
아직도 키보드를 보지 않고 모든 자판을 능숙하게 칠 줄 모른다면 타자 소프트웨어를 설치하여 연습하라. 모든 자판에 능숙해지면 더 자연스럽고 편해질 것이다.
당연히 시간도 절약될 것이다.

현장에서 부대껴라
다음 주 중 하루를 잡아 아무에게도 전자우편을 보내지 말라
평소처럼 전자우편을 보내지 말고 전자우편을 받을 사람을 전화로 부르거나 그 사람 사무실로 가 직접 이야기를 해보라.
잘 이야기하지 않는 동료, 상사, 고객 명단을 만들라
달력에 정기적인 약속을 잡고 출근할 때 인사하라. 대화는 짧고 의미있게 해야 한다. 대화를 하면서 일과 관련된 것에 대해 의견을 나누고 간단하게나마 인간관계를 만들라.

적절한 표현으로 말하기
최근 성과 목록을 만들라
각각의 비즈니스적 이익을 적는다. 목록에 있는 성과 중에 비즈니스적 이익을 쓸 수 없는 것이 있다면 관리자나 믿을 만한 사람에게 어떻게 설명할 것인지 질문하라.
'승강기 발표'를 준비해 외워두라

자신의 강점을 유지보수하라
이미 구식
주 중에 시간을 내 첨단 기술을 연구하라. 최소한 매주 두시간 정도 여유를 만들어 새 기술을 조사하고 그 기술에 능숙해지도록 연습하기 시작한다.
이 새 기술들로 실무 작업을 해 본다. 간단한 애플리케이션을 만들라. 현재 기술 프로젝트에서 어려운 부분을 새 기술 버전으로 프로토타입을 만들어 둘 간의 차이가 무엇이고 새 기술로 무엇을 할 수 있는지 이해하라. 이 시간을 일정에 넣고 빠트리지 않도록 한다.

거울 속 그 뚱뚱한 남자
360 도 리뷰를 하라
편하게 조언을 구할 수 있는 믿을 만한 사람 명단을 만들라. 명단에는 동료, 고객, 관리자가 모두 들어 있어야 한다. 전문가로서 중요한 척도라고 믿고 있는 열가지 특성에 대한 또 다른 목록을 만들라.
이 목록을 설문지로 바꾸라. 설문지에서 각각의 특성 항목에 여러분에 대한 점수를 매겨달라고 요청하라. '내가 무엇을 물어봐야 했을까?' 라는 질문도 포함시켜라.
설문지를 명단에 있는 사람들에게 나눠준다. 적극적으로 비평해 달라고 요청하라. 정직한 조언이 필요하지, 사탕발림이 필요한 것이 아니다. 완성된 설문 답안을 받으면 전부 읽고 결과로서 취할 행동 목록을 만든다. 정확한 사람에게 정확한 질문을 했다면 행동으로 옮길 만한 항목을 얻은 것이다.
검토자들과 설문지 결과를 공유하라. 단순한 답변이 아니라, 계획한 결과로서 생길 변화에 대해 공유해야 한다. 그 사람들에게 꼭 감사한 마음을 가져라.
이 과정을 자주 되풀이하라.
일지를 쓰기 시작하라
자신의 목소리가 들리게 하라 에서 논의한 블로그일 수도, 개인 일기일 수도 있다. 무슨 일을 하는지, 무엇을 배우는 지, 업계에 대한 자신의 의견을 쓰라.
한동안 일지를 계속 쓴 후에 예전에 쓴 것들을 다시 읽어보라. 여전히 동의하는가? 미숙하게 보이지는 않는가? 얼마나 많이 변했나?

남인도의 원숭이 덫
원숭이 덫을 찾으라
자신의 경직된 입장은 무엇인가? 의식적으로 알지 못하지만, 매일 자신의 행동을 이끄는 가치는 무엇인가?
열이 두개인 테이블을 만든다. 각각 경력과 기술을 넣는다. 각 항목 밑에 확고하게 사실이라고 믿는 가치를 나열한다. 예를 들어 경력 밑에는 다음과 같은 것을 적을 수 있다. 장점이 하나라고 항상 알고 있는 것은 무엇인가? 또는 단점은? 경력 목표는 무엇인가? 목표를 이루는 적절한 방법은 무엇인가? 기술 열에는 투자하기로 선택한 기술에 대해 가장 가치있다고 여기는 것을 나열한다. 선택할 때 고려해야 하는 기술의 가장 중요한 특징은 무엇인가? 확장성이 있는 시스템을 어떻게 만들까?
소프트웨어 개발에 가장 생산적인 환경은 무엇인가? 일반적으로 최고/최악의 플랫폼은 무엇인가?
목록을 써내려가다 완전히 다 됐다고 느끼면 목록에서 하나씩 각각의 주장을 마음속으로 번복해보라. 각각의 주장이 사실은 그 반대라면 어떨까? 각각의 주장에 정직하게 도전해보라. 이것이 취약점 목록이다.
적을 알라
가장 싫어하는 기술을 고른다. 그리고 그것으로 프로젝트를 한다. 개발자들은 경쟁 기술에 선을 긋는 경향이 있다. 닷넷 사람들은 J2EE 를 싫어하고 J2EE 사람들은 닷넷을 싫어한다. 유닉스 사람들은 윈도를 싫어하고 윈도 사람들은 유닉스를 싫어한다. 쉬운 프로젝트를 골라 싫어하는 기술로 훌륭한 애플리케이션을 만들어보라.
자바 사용자라면 닷넷 사용자에게 진짜 개발자는 닷넷 플랫폼을 어떻게 사용하는지 보여주라. 자신이 싫어하는 기술이 모두 나쁜 것이 아님을 배우고, 사실은 그 기술로도 좋은 코드를 개발할 수 있음을 배우는 것이 중요하다. 앞으로 활요할 필요가 있을지 모르는 새 기술도 배워라. 최악의 경우라고 해봐야 그 쉬운 프로젝트가 연습시간이 될 것이고 자신의 주장에 대한 더 좋은 논거를 갖게 될 것이다.

그들을 이길 수 없다면
오픈 소스에서 배우기
성공적인 오픈소스 프로젝트를 관찰하라
해당 프로젝트에서 의사소통, 디자인, 작업, 오류, 소스관리는 어떻게 하는지 기록해두라.
오픈소스 프로젝트에 참여하라
버그를 고치고 새 기능을 추가하고 지원 요청에 응하고 출시 과정에 참여해보라.
해외 프로그래머와 오픈소스 개발자들이 어떻게 다른지 생각해보라
차이점을 발견했다면 해외 프로그래머들과 일하는 방식을 어떻게 바꿀 수 있을까? 오픈소스 방식 중에 평범한 해외 프로그래머에게 어울리지 않는 것은 어떤 것이 있을까? 반대로 적용할 수 있는 것은 어떤 것이 있을까?