[개발도서]프로그래머 열정을 말하다 (채드 파울러)

이미지 출처 - 도서출판 인사이트

 

---

목차에서

* : 다시 읽어 보고 싶은 장

** : 스스로 개선 되었으면 싶은 장

 

---

3장_코딩만으로는 이제 충분하지 않다

이제 자신의 시간을 투자할 사업 분야에 대해 생각할 시간이다.

 

실천하기

1. 비즈니스 담당자와 점심 약속을 잡으라. 담당자들이 일을 어떻게 하는지 이야기를 나누라. 일과 대해 자세히 질문하라. 이야기 나누는 동안 그 일을 하고 싶은 포부가 생기면 무엇을 배워야 하는지, 무엇을 바꿔야 하는지 질문하라. 기술이 그들의 일에 도움이 됐는지(또는 일을 더디게 했는지) 이야기를 나누라. 그리고 이 일을 정기적으로 하라.

 

2. 회사 업무와 관련된 업계 잡지를 고른다. (..) 회사에는 대부분 업계 잡지 과월호 모음이 있다. 잡지를 하나하나 읽이 시작하라. 모든 내용을 이해할 수는 없겠지만 꾸준히 읽도록 한다. 경영진이나 비즈니스 고객에게 물어볼 질문 목록을 만들라. 질문이 멍청해 보여도 고객은 여러분이 배우려고 한다는 사실을 고맙게 여길 것이다.

 

 

4장_가장 못하는 사람이 되라*

주변 사람이 자신의 능력에 영향을 준다.
주변 사람을 신중하게 선택하라.

 

(..) 그래서 누구와 일하냐는 것만으로도 기술이 엄청나게 늘거나 퇴보할 수 있다는 것을 배웠다. 사람은 집단을 이뤄 오래 일하면 업무 수행능력에 지속적으로 영향을 받을 수 있다.

 

(..) 가장 못하는 사람이 되려고 하면 실제로는 자신을 과소평가하지 않게 된다. 사람들은 A급 밴드에 속할 수도 있지만 항상 B급 밴드에 들어간다. 두렵기 때문이다. 자신이 최고가 아님을 솔직히 인정하면 자신이 최고가 아니라는 사실이 알려지는 데 대한 두려움을 씻어낼 수 있다. 사실은 가장 못하는 사람이 되려고 할 때 실제로는 가장 못하는 사람이 되지 않을 것이다.

 

 

6장_부모님 말씀을 듣지 말라

 이직은 내가 소프트웨어 산업에서 성공하는 데 비약적으로 도약하는 분명한 시작점이 됐다. 새 분야를 알았고 더 어려운 문제를 다뤘고 이전보다 더 크게 보상을 받았다. 당시에는 두려웠지만 두려움에 이끌리지 않고 보수적이지 않게 경력을 선택하기로 결정하자 내 경력, 즉 내 삶의 모양과 상태는 더 낫게 바뀌었다. 

 

 자신의 경력에서 계산할 수 있는 위험을 감수하라. 두려움이 자신을 파괴하게 두지 말라. 그리고 재미있지 않다면 탁월해지지도 않을 것이다.

 

 

7장_다재다능한 사람이 되라

 결론적으로 말하면, "코딩만으로 이제는 충분하지 않다"에서 논의했던 것 처럼 사업과 IT사이의 벽은 당장 허물어져야 한다. 사업이 어떻게 운영되는지 배우기 시작하라. 

 

실천하기

 1. 종이나 화이트 보드에 자신의 지식과 능력 중에 다재다능한 부분과 그렇지 않은 요소를 나열하라. 각 요소에 자신의 특기를 적는다. 예를 들어 플랫폼과 운영체제가 여러 요소 중 하나라면 그 옆에 윈도/닷넷을 쓰면 된다. 이제 적어 놓은 특기 오른쪽에 "배울 것(To-Learn) 목록에 넣을 주제를 하나 또는 그 이상 쓰라. 앞에서 든 예를 다시 들면 리눅스와 자바를 쓰면 될 것이다. 

 

 되도록 빨리(늦어도 이번 주 중에) 30분을 할애해 목록에 있는 배울 것 항목 중 최소한 하나를 다루기 시작해 본다. 눈으로 보지만 말고 가능하다면 실제로 다뤄보라. 웹 기술이라면 웹 서버 패키지를 받아 스스로 셋업해 보라. 사업 관련 주제라면 회사 고객을 만나 점심을 같이 먹으면서 대화를 나누라.

 

 

10장_사랑하지 않으면 떠나라 

 여러분을 신나게 하는 것이 기술일 수도, 사업 분야 일 수도 있다. 반대로 특정 기술이나 사업 분야 또는 어떤 조직 형태 때문에 우울할 수도 있다. 작은 팀에 잘 맞을 수도, 큰 팀에 잘 맞을 수도 있다. 경직된 프로세스에 어울릴 수도 있고, 기만한 프로세스에 어울릴 수도 있다. 그런 것들이 어떻게 섞여 있든지 시간을 들여 자신만의 것을 찾으라.

열정이 충만한 것처럼 한동안은 속일 수 있게지만 열정 부족은 자신과 자신의 일에 나쁜 결과를 가져올 것이다

 

실천하기 

1. 자신이 정말로 열정을 쏟아낼 만한 일을 찾으라

2. 다음 주 월요일부터 2주간 간단한 기록을 계속하라. 일어나 일을 시작할 때마다 신나는 정도를 1부터 10으로 점수를 매기라. 1은 일하러 가기보다는 아픈게 낫다는 의미이속 10은 다음 일을 마무리할 아이디어에 사로잡혀 침대에 도저히 누워있을 수 없음을 뜻한다.

2주간 이 기록을 계속 쓴 후 결과를 검토하라.

그 다음 2주간 매일 아침에 내일은 10점으로 만들 계획을 짜라.내일 일을 시작하기를 기다릴 수 없게 하게 하려면 오늘 무엇을 할지 계획하라. 매일 어제 얼마나 신났는지 기록하라.

 

 

12장_사업이 실제로 어떻게 돌아가는지  배우라*

p82

사업이 어떻게 돌아가는지 알아야
창의적으로 도울 수 있다.

 

되돌아보니 우리가 어리섞었음을 깨닫는다. 우리는 회사를 위해 일하고 우리 일은 회사가 돈을 벌거나 절약하는 데 기여하는 것이었다. 그러나 우리는 사업에서 수익을 내는 방식의 기본을 이해하지 못했다. 더욱 심각했던 점은 그걸 아는 게 우리 일은 아니라고 생각했다는 것이다. 우리는 프로그래머이고 시스템 관리자였다. 우리 일은 우리가 몰두하는 주제들에 관한 것이라고만 생각했다. 하지만 사업이 어떻게 돌아가는지 이해하지 못하면서 사업에서 수익을 내도록 어떻게 창의적으로 도울 수 있겠는가? (*p83까지 다시 읽어보기)

 

 

13장_멘토를 찾으라 

p85

누군가를 의지하는 것은 좋다.
단지 그 사람이 의지할 만한 사람인지만 확실히 해두라.

 

p85

멘토가 존재하는 가장 중요한 첫 번째 목적은 역할 모델(role model)이다. 

 

p86

멘토는 또한 배우는 과정에 체계를 세워줄 수 있다. 

 

멘토는 또한 신뢰할 수 있는 사람으로서 도움을 준다.

 

p87

멘토 관계에서 어느 정도 형식을 갖추느냐는 중요하지 않다. 아무도 자신의 멘토가 되어 달라고 분명하게 부탁하지 않는다. 사실 멘토는 자신이 멘토 역할을 하고 있다는 것을 알지 못할지도 모른다. 중요한 것은 신뢰하고 존경하는 사람이 있고, 그 사람이 경력 안내를 해 줄 수 있고, 기술을 갈고 닦을 수 있게 돕는다는 것이다. 

 

실천하기

 내 자신의 멘토가 되어보자 - 우리 모두에게 적극적으로 멘토링을 해주는 사람이 있다면 이상적이겠지만 현실은 우리가 있는 곳에서 이 역할을 할 수 있는 사람을 항상 찾을 수 있는 것은 아니다. 이제부터 스스로 멘토가 되는 방법을 살펴보자

자신의 분야에서 가장 존경하는 사람을 생각해 낸다. (..중략)

 

 이 역할 모델의 가장 중요한 특성 열가지를 나열한다. 

 이제 이 특성들을 중요도 순으로 순위를 매긴다. 1이 가장 덜 중요한 것이고 10이 가장 중요한 것이다 .

목록의 각 항목에 열을 추가한다. 자신의 역할 모델이 자신에게 어떻게 등급을 매길지(10점 만점) 상상해 본다. 진짜로 역할 모델의 마음으로 제 3자인것 처럼 자신을 관찰해 본다.

 

14장_멘토가 되라* 

p89

 무엇인가를 정말 배우고 싶다면 그것을 다른 누군가에게 가르쳐 보라. 어떤 것에 대한 이해를 구체화하는 데 가장 좋은 방법은 다른 사람들이 이해할 수 있도록 그것을 표현하는 것이다. 말을 한다는 것은 단순한 행동이지만 불분명한 사고를 다루는 데는 특효약이다. 인형 같은 물건과 얘기하는 것은 소프트웨어 개발에서 전승되어온 잘 알려진 문제 해결 수단 중 하나다. 

 

무엇인가를 정말 알고 있는지 확인해 보려면 
그것을 다른 사람에게 가르쳐 보라.

 

 우리는 가르치면서 배운다. 선생이라면 이미 알고 있다고 생각하기 때문에 역설적으로 들릴지도 모른다. 물론 다른 사람들에게 새로운 사실을 가르쳐야만 그것을 배울 수 있다는 뜻은 아니다(미리 배우지 않고 가르칠 수 있는 없다) 그러나 단순히 어떠한 사실을 안다는 것은 그것의 원인과 결과를 깊이 이해한다는 것과는 다르다. 다른 사람들을 가르쳐 봄으로써 그것을 더 깊이 이해할 수 있다. 우리는 복잡한 개념을 설명하기 위해 유추한다. 그리고 유추가 통하는 경우와 그렇지 않은 경우 대해 그 이유가 무엇인지 하나하나 살펴본다. 누군가를 가르치게 되면 전에는 결코 생각하지도 못했던 지문에 대답해야 할 때가 있다. 가르쳐 봄으로써 자신의 지식 중 모호한 부분이 드러나고 그것을 분명히 인식할 수 있게 된다.

 따라서 멘토를 찾아서 도움을 얻을 수 있는 것처럼 다른 사람에게 멘토가 되어도 자신에게 많은 도움이 된다.

멘토는 그만두려 해서는 안된다

 

사람을 돕는 것을 단지 '좋은 느낌이 드는'정도라고 과소평가해서는 안된다. 타인에게 관심이 있다면, 실제로 자신의 기술을 타인을 위해 쓸 것이다. 오늘날처럼 불확실성의 경제 환경에서 타인을 돕는다는 것은 중단할 수 없는 우리의 임무다. 그리고 그로 인해 얻는 보답은 인플레이션으로도 평가 절하되지 않는다.

 

15장_연습, 연습, 또 연습

한계까지 연습하라

 

실천하기 

1. 톱코더(Top Coder) - 여러 해 동안 운영되어 온 프로그래밍 겨루기 사이트다. 계정을 등록하면 온라인에서 시합을 해서 상을 받을 수 있다.

 

2.코드 카타(Code Kata) - 프래그머틱 프로그래머(출판사)의 데이브 토머스는 코딩 연습이라는 아이디어에서 아주 실용적인 것을 만들어냈다. 데이브가 코드 카타라는 연재물을 쓴 것이다. 코드 카타는 작지만 뇌를 자극하는 연습 문제로서, 프로그래머는 자신이 선택한 언어로 문제를 풀 수 있다. 각 카타는 특수한 기술이나 사고 과정을 강조해 사고 능력을 구체으로 단련할 수 있는 기회를 제공한다.

 

블로그(http://codekata.pragprog.com)에 21개의 카타가 무료 공개되어 있다

 

도전 과제 : 21개 카타를 모두 푼다. 카타를 푼 경험을 일기에 쓴다. 문제 21개를 모두 풀었다면 자신만의 카타를 만들어 다른 사람들과 공유하라

 

 

16장_일하는 법

 관리자들은 어떤 종류의 프로세스를 따라해야 하는지 직관적으로 안다. 그러나 바로 사용할 수 있는 대안은 대개 알지 못한다. 그 결과로 1980년대에 강요했던 낡은 프로세스를 다시 꺼내 전문 용어가 인쇄된 리본으로 포장해 팀에 실행을 떠넘긴다. 누군가 어떤 프로세스는 되고 어떤 프로세스는 안 되는지 연구 후 악순환을 깨지 않으면, 그 팀의 개발자가 스스로 관리자가 되어 똑같은 프로세스를 되풀이 하는 악순환이 발생한다. 

 

프로세스가 자신에게 속해 있다고 느끼고 싶으면
프로세스를 만드는 데 도움을 주라

 

 

 따라야 할 가장 좋은 프로세스는 팀을 가장 생산적이게 하고 최고의 제품을 만들어 내도록 하는 것이다. 가장 높은 생산성과 가장 좋은 제품을 동시에 만족하는 유일한 방법은 가능한 대안을 공부해 여러분과 팀이 이행할 수 있는 부분을 골라 실제 경험에 바탕을 두고 지속적으로 다듬는 것이다. 결과적으로 프로세스를 만들 수 없다면 제품을 만들 수 없다. 소프트웨어가 돌아가게 만들 수 있는 사람을 찾는 편이 소프트웨어 개발 프로세스를 잘 돌아가게 할 수 있는 사람을 찾는 것보다 오히려 쉽다. 따라서 소프트웨어 개발 프로세스 관련 지식을 '자기 무기고'에 추가한다는 것은 오직 자신에게 유익한 것이다.

 

 

17장_거인의 어깨 위에서

기존 코드를 이용해 자신의 능력을 비춰보라

 

코드를 읽으면서 전에 해 본 적이 없는 것들과 결코 생각해 보지도 못했던 것을 발견할 것이다. '왜일까? 이 개발자는 무슨 생각을 하고 있었을까? 동기가 무엇이었을까?' 기존 코드를 이처럼 비판적으로 의식하며 탐구한다면 나쁜 코드에서도 배울 수 있다.

 

코드 읽기의 긍정적인 부수적 효과는 기존의 것에 대해서도 더 많이 배운다는 점이다. (..중략)

 

아이작 뉴턴은 "내가 더 멀리 봤다면 그것은 '거인의 어깨 위에 서' 있어서다"라고 말했다. 뉴턴처럼 총명한 사람이라면 앞 세대로부터 배울점이 많다는 사실을 알 것이다. 뉴턴처럼 되라

 

 

20장_마음 읽기

마음 읽기 요령은 잘만 되면 
사람들이 여러분에게 의지하게 된다

 

 사람과 프로젝트를 관리하는 것은 도전적인 일이다. 지도를 별로 받지 않고 프로젝트를 올바른 방향으로 계속 움직이게 할 수 있는 사람은 관리자와 고객들로부터 그 가치를 높이 평가받고 그 진가를 인정받는다. 마음 읽기는 잘만 하면 고객이 여러분에게 의존하게 될 것이다. 이것은 자신이 가려고 하는 방향으로 경력을 주도할 수 있는 훌륭한 묘안이며 탐구하고 게발할 가치가 있는 것이다.

 

 

22장_누구를 위해 일하는지 기억하라*

 좋은 관리자의 역할은 '대타 노릇', 즉 전체 팀 업무가 돌아가는 것을 완전히 파악하고 작업이 어려워질 때 대신하는 것이 아니다. 좋은 관리자의 역할은 팀을 위해 우선순위를 세우고, 팀이 일을 잘하기 위해 필요한 것을 갖춰놓으며, 지속적인 동기 부여와 함께 생상적으로 일할 수 있도록 필요한 행동을 취하고, 최종적으로는 필요한 일을 마무리하게 하는 것이다. 팀에서 잘 수행한 업무가 곧 관리자가 잘 수행한 업무가 되어야 좋은 관리자라고 할 수 있다.

 

관리자의 성공과 여러분의 성공을 분리하지 말라

 

 

누구를 위해 일하는지 기억하라. 사업 필요에 맞게 자신을 바꿔나갈 뿐 아니라 사업을 자신의 필요에 맞게 변화시켜야 한다. 자신의 일을 완전하게 해내려고 한다면 이 내용이 일을 딱 맞게 하는 데 보증이 될 것이다.

 

 

23장_현재 위치에 충실하라

실천하기

1. 자신의 경력 목표를 1주일간 내버려 두라. 현재 업무 목표를 적으라. 지금 하고 일을 끝낼 때 이루고 싶은 것을 생각하라. 이 일을 훌륭하게 마치면 무엇을 만들어 낼 수 있을까? 전략적이면서 전술적인 계획을 세우라. 이 일을 '마친다'는 장기 목표를 지원하는 데 이 전술들을 실현하며 한 주간을 보내라.

 

(.. 중략)

 

그 주의 마지막에 이 목표들을 만족시켰는지 진행을 평가하라. 현재 역할에서 필요하다고 느끼는 모든 것을 이루는 데 얼마나 걸릴까? 다 해냈는지 어떻게 알까? 다음 주를 계획하고 반복하라.

 

 

26장_물 양동이 속 자갈*

 직장에서 여러분의 존재는 회사로서는 물 양동이 속 자갈과 같다. 정말이다. 자갈 때문에 물 높이는 더 올라간다. 일을 다 하면 자기 몫을 다 한  것이다. 그러나 양동이에서 자갈을 꺼내고 되돌아서 물을 보면 실제로는 차이를 별로 느낄 수 없을 것이다. 

(..) 우리 모두 자신의 기여가 무엇을 의미하는지 느낄 필요가 있다. 그리고 실제로도 그렇다. 그러나 우리는 나만 생각하는 데 너무 많은 시간을 쓰느라 다른 사람들도 자기만 생각한다는 점을 쉽게 잊는다. 회사에서 일하는 사람들은 모두 지각 있고 자율적인 사람들이지만 자아라는 것에 빠져 있다. 이 자아는 자기 직업을 보는 유일한 창이다.

 

자신만의 성공 때문에 눈이 머는 것을 경계하라.

 

 

그 CIO가 가르쳤던 것은 '성공하면 할수록' 치명적인 실수를 저지를 수 있다는 것이다. 모든 게 잘 되면 자기 결정에 의문을 품지 않게 된다. 늘 해오던 방식대로 다 잘 되면 더 잘할 수 있는 새로운 방법을 찾지 않을 수 있다. 거만해질 것이고 건방을 떨다 보면 맹점이 생긴다. 아무도 자신을 대신할 수 없다고 생각할수록 누구나 자신을 대신할 수 있게 된다.

 

회사에서 인정 못 받는데 과거의 성공 속에 사는 상사를 만난 경험이 있는데 이 글에 나온 것과 똑같았다

 

 자신을 대신할 수 없다고 자만하는 것은 나쁜 징조다. 특히 소프트웨어 개발자에게는 더욱 그렇다. 여러분을 대신할 수 없다면 그것은 여러분이 다른 사람이 할 수 없는 방식으로 일을 한다는 것을 의미한다. 우리는 모두 자신을 '특별한 천재'라고 주장하지만 아무리 탁월해도 그를 대신할 수 없는 개발자는 거의 없다. 

 

 같은 논리로 자신이 떠나도 다른 사람이 대신할 수 있게 만드는 사람이 되면 적대적이지 않은 업무 관계가 생길 수 있다. 우리는 모두 대체될 수 있다. 이것을 사실로 받아들이고 그렇게 일하는 사람은 자신을 실제로 변화시킬 수 있고 두말할 것 없이 자신만의 기회를 활용할 수 있다. 그리고 여러분이 누구와도 대체될 수 있다면, 더 크고 나은 직장으로 떠나는 것은 당연한 일로 아무도 못 말린다.

 

 

27장_유지보수를 즐기라*

유지보수가 자유와 창조를 위한 환경이 될 수 있다.

 

 소프트웨어를 지속적으로 동작하게 하고 사용자 요구에 시기적절한 방법으로 응답하는 한 유지보수 작업은 자유롭게 창조할 수 있는 장이다. 자신이 프로젝트 리더, 아키텍트, 설계자, 코더, 테스터다. 창의력을 원하는 만큼 마음껏 발휘할 수 있을 뿐 아니라 시스템의 성공 또는 실패를 측정하는 것도 자신에게 달려 있다.

 

 오늘날 많은 프로젝트 팀의 계약 환경과 달리 유지보수 일의 숨겨진 장점은 유지보수를 하는 프로그래머는 고객과 직접 대화할 기회가 꽤 있다는 것이다. 사업에서는 사람을 많이 알면 알수록 후원자 기반을 넓힐 기회가 더 많아진다. 또한 자신이 일하는 사업의 내부 짜임새를 정확히 배울 수 있는 가장 좋은 위치에 있게 된다. 비지니스 애플리케이션 전체를 책임지고 있으며 최종 사용자와 함께 문제와 질문을 하나씩 해결해 간다면 크게 노력하지 않아도 애플리케이션의 실제 성능뿐 아니라 많은 비즈니스 사용자를 이해할 수 있을 것이다.

 

프로젝트와 유지보수의 분열을 둘러싼 커다란 아이러니는 프로젝트가 곧 유지보수라는 것이다. 프로젝트 팀이 코드 첫 줄을 쓰자마자 이후에 추가되는 기능은 모두 살아 있는 코드 기반에 접목되는 것이다. 물론 전부터 쓰던 레거시 애플리케이션을 다루는 것보다는 코드도 더 깨끗하고 적겠지만 기본 행동은 같다. 새 기능이 추가되면서 기존 코드에 있는 버그가 수정된다. 이 일을 더 빠르고 더 낫게 하는 법을 누가 알까?

 

 

28장_8시간 열중하기**

프로젝트는 마라톤이지,단거리 경주가 아니다.

 

 프로젝트는 대부분 오래 지속된다. 단거리 경주 속도로 달리다가는 마라톤을 완주할 수 없다. 단기 생산성은 상당히 오르겠지만 장기적으로 녹초가 되어 회복 시간이 더 길어질 것이다. 이는 주당 80시간 일해 얻는 생산성이 즐기면서 일한 생산성보다 더 좋지 않다는 말이다.

 

실천하기

1. 오늘 밤 확실하게 푹자라. 내일 아침을 먹고 정시에 일을 시작하라. 네 시간 동안 치열하게 일하라. 한 시간 동안 점심을 먹는다. 그런 다음 완전히 지쳐서 더 이상 일하지 못하겠다는 느낌이 들 정도로 치열하게 네 시간 더 일하라. 집에 가서 쉬면서 재미있게 보내라. 

 

 

29장_실패하는 법을 배우라*

 우리는 모두 실수하기 때문에 다른 사람들도 실수한다고 생각한다. 따라서 우리가 저지르는 실수에 대해 서로를 비난하지 않는 것이 합당하다. 판단해야 할 것은 그러한 필연적인 실수를 어떻게 잘 처리할 것인가이다.

 기술적 실수이든, 의사소통 실수이든, 프로젝트 관리 실수이든 다음과 같은 규칙이 적용된다. 

 

• 알게 되자마자 문제를 제기하라. 오래 숨기려 하지 말라. 소프트웨어 개발과 테스트에서처럼 실수를 일찍 잡아내면 늦게 잡아내는 것보다 문제가 줄어든다. 더 일찍 문제를 끄집어내 자신이 한 것을 드러낼수록 부정적인 영향이 줄어들 것이다. 
• 책임을 지라. 할 수 있더라도 속죄양을 찾으려 하지 말라. 혼자서 다 비난 받는게 아니더라도 책임을 지고 나아가라. 목표는 최대한 빨리 이 시점을 지나는 것이다. 문제는 해결해야 한다. 누구 잘못인지 책임자를 가리지 못해 질질 끄는 것은 논쟁만 오래 갈 뿐이다.
• 해결책을 제시하라. 자신에게 해결책이 없으면 해결책을 찾기 위한 착수 계획을 제안하라. 구체적이고 예측할 수 있는 기간으로 말하라. 팀을 궁지에 몰아넣었다면 문제를 되돌리는 데 필요한 노력이 얼마나 필요한지 판단해 그 기간을 알려주라. 작고 하찮더라도 구체적으로 달성할 수 있는 목표가 이 단계에서 중요하다. 목표가 있으면 상황을 계속 호전시킬 수 있을 뿐 아니라 프로세스에서 다시 신뢰를 쌓는 데 도움이 된다.
• 도움을 구하라. 문제에 대한 비난을 혼자서 받는다 하더라도 자존심 때문에 해결 과정에서 도움을 거절해 상황을 악화시키지 말라. 팀이 상황을 헤쳐 나가는 것을 돕는 동안 겸손한 태도로 자의식을 잠시 제쳐 둔다면 팀워느 경영진, 고객은 훨씬 더 긍정적인 눈으로 여러분을 볼 것이다. 책임감을 지나치게 느껴 많은 부담을 어깨에 올려놓고는 결국, 다른 누군가가 강제로 개입할 때 까지 헛수고하는 일을 하지 말아야 한다.

긴장이 가득한 상태는 신뢰를 쌓을 수 있는 가장 좋은 기회다. 

 

 

30장_"아니오"라고 말하라**

실망시키지 않으려고 "예!" 하는 것은 단지 거짓말일 뿐이다.

 

 "예"라고 말하는 것은 습관적이고 유해한 버릇이다. 그것은 좋은 사람인 척 하려는 나쁜 버릇이다. '할 수 있다'는 태도와 자신의 능력을 '거짓으로 말하는 것'은 차이가 크다. 후자는 자신뿐 아니라 자신이 약속한 사람들에게도 문제를 일으킨다. 

 

(..중략)

 

 어떤 사람이 항상 "예"라고만 한다면 엄청나게 재능이 있거나 거짓말을 하는 것, 둘 중 하나다. 대개 후자다.

 적절한 상황에서 "모릅니다"라고 말하는 것 역시 좋다. 날짜를 맞출 수 있을지 대답하거나 약속을 하기 전에 일에 대해 조사할 시간이 필요할 수 있다. 또는 기술이 어떻게 유효한지, 프로젝트 코드의 어떤 부분이 어떻게 구현되는지 질문을 받을 수 있다. 약속의 경우와 똑같이 질문에 대답하지 못하면 작은 실패로 느낀다. 그러나 여러분이 어떤 것을 잘 모른다고 말할 때 동료와 관리자들은 여러분을 더 신뢰할 것이다.

 

 

31장_당황하지 말라

영웅은 결코 당황하지 않는다.

 

 자, 당황하지 않는 법을 내가 어떻게 배웠는지 이제 설명하겠다. 뭔가 나쁜 일이 생기면, 쳐지고 스트레스로 지친 느낌이 당황함으로 이어진다고 생각하기 시작한다. 내 자신을 좌절한 컴맹과 비교하고 조용히 웃는다. 워드 프로세서를 쓰다가 재앙을 당한 가족을 돕는 것처럼 제 3자 관점에서 상황을 분석한다. 어려워 보이던 문제가 갑자기 더 쉬워진다. 나빠 보이는 상황이 갑자기 그다지 나쁘지 않게 된다. 그리고 해법이 단순함을 발견하고 에러 대화 상자가 다음에 무엇을 할지 정확히 알려주는 것과 같은 방식으로 자신을 응시한다. 그냥 침착하게 에러 메시지를 읽기만 하면 문제가 풀릴 것이다. 

 

실천하기

 당황한 일지를 꾸준히 쓰라. 당황스러움이 생기기 전에 그것을 붙잡는 열쇠는 그런 일이 일어날 때 자신의 지각과 감정을 실시간으로 인식하는 능력이 더 강화되게 계발하는 것이다. (..중략)

 연습을 좀 한 후에는 당황스러움이 생기는 동안 분석이 시작됐음을 발견할 수 있을 것이다. 당황한 이유를 실시간으로 합리적으로 찾다보면 당황이 눈에 안 띄게 되고 결국 사라짐을 발견할 것이다.

 

 

32장_말하고 행하고 보여주라

상황 보고를 통해 자신을 적극 선절할 수 있다.

 

 자신의 계획을 관리자에게 알리기 시작해야 한다. 계획을 알리기 시작할 가장 좋은 때는 계획을 최소한 한 주기를 실행한 후다. 그리고 관리자가 요구하기 전에 그것을 시작하는 것이 중요한 핵심이다. 제 정신을 지닌 관리자라면 직원으로부터 지난주에 한 일과 다음 주 계획을 알리는 간결한 이메일을 받고 기뻐하지 않을 사람은 아무도 없을 것이다. 이와 같은 자발적인 메시지를 정기적으로 받는 것은 관리자의 꿈이기도 하다.

 

 계획을 세울 때 명심해야 할 가장 중요한 요소는 나중에 언제든지 설명할 수 있어야 한다는 점이다. 모든 항목은 마무리되거나 연기되거나 빠지거나 대체되는 것이 반드시 뚜렷이 드러나야 한다. 설명할 수 없는 항목이 있어서는 안 된다. 어떤 항목이 계획에 올라왔는데 다시 언급되지 않는다면 사람들은 여러분의 계획을 신뢰하지 않을 것이고 여러분이 짠 그 계획이 오히려 관련 계획을 효율적으로 짜는 일을 방해하게 될 것이다. 결과가 나빠도 그대로 알려야 한다. 우리는 모두 실수한다. 자신을 구별 짓는 방법은 자신의 실수와 무능력을 공개적으로 알리고, 그것들을 해결하는 데 도움을 구하는 것이다. 계획한 업무를 꾸준히 추적하다 보면 뒤죽박죽된 상황 속에서도 중요한 일을 놓칠리가 없다는 자신감을 응당 가지게 될 것이다.

 

 리더는 여러분이 독립성과 주인의식을 갖길 바란다. 계획을 만들고 실행하고 알림으로써 두 가지를 모두 손에 넣을 것이다.

 

 

43장_어울리라**

두려움을 걷어치우라.

 

 덧붙여 말하자면 평범한 사람과 우리가 존경하는 사람 사이의 가장 심각한 장벽은 우리 자신의 두려움이다. 여러분을 가르칠 수 있거나 여러분이 일을 찾을 수 있게 도울 수 있는 똑똑하고 배경 좋은 사람들과 어울리는 것은 스스로를 개선할 가장 좋은 방법인데도 시도해 보기를 두려워하는 사람이 많다. 

 

 

46장_목적 없는 길*

 늘 목표 중심적이고 목표에 초점을 맞춘 사고만 하다 보면 한 목표에서 다음 목표로밖에 나아가지 못한다. 그것은 논리적으로 끝이 없다. 사람들이 대부분 이것을 깨닫는 데 실패하는 것은 그 '길'에는 끝이 있다고 생각해서이다. 

 

결과가 아닌 과정에 집중하라.

 

 결과에 집중하다 보면 과정을 개선하는 데 게을러질 수 있다. 사실 과정이 나쁘면 나쁜 제품을 만들어낸다. 제품이 최소 요구사항을 충족했는지 모르지만 그 속은 추할 것이다. 단기 목표만 최적화했지, 필연적으로 계속될 제품 개발의 미래는 최적화하지 않은 것이다. 

 나쁜 과정이 나쁜 제품을 만들 뿐 아니라 나쁜 제품이 나쁜 과정을 만든다. 제품 중 하나가 속이 엉망이더라도 과정은 그에 맞춰진다. 제품의 '깨진 창문' 이 과정에서도 깨진 창문을 만들어낸다. 악순환이다. 

 따라서 "아직 안 됐나요? 아직 안 됐어요?"라고 계속해서 물을 때, "아직, 안 됐습니다."라고 대답하는 것만이 올바른 태도임을 깨달으라. 중요한 것은 길을 가는 과정이지, 목적지가 아니다.

---

 

 

 해당 책을 읽으면서 개발자로서 엔지니어로서 스스로 잘 지켜왔던 부분과 부족한 부분에 대해 돌아 보는 시간을 가질 수 있었다. 

 

프로젝트를 떠넘김 받았음에도 막연하게 생각하다 뒷통수 맞았던 적이나,

타인에게 "아니요"라고 말하지 못해 나를 힘들게 만들었던 시간들이 생각났다.

 

새로운 곳에 가더라도 전과 같은 실수를 반복하지 않도록 변화해야겠다.

그리고 당황과 긴장으로 기회를 놓치는 일이 없도록

연습, 연습, 또 연습하여 한계를 극복해 가야겠다

 

개발은 단거리 달리기가 아닌 마라톤과 같아서

긴거리를 계속 뛰어야하는 마라톤에서 페이스 유지는 매우 중요하니깐