👨🏻‍💻 프로그래머, 열정을 말하다를 읽고

현재 다니고 있는 회사에서는 멘토가 없다. 기술적인 멘토로는 stackoverflow가 있겠지만 사실 그것만으로는 만족할 수 없다. 경험에서 우러나오는 통찰력과 선택 등을 배우고 싶었다. 현재 나에게 멘토가 없다해서 이대로 가만히 있을 수는 없다. 스스로 움직여야 결국 기회도 찾아오는 것이다. 그래서 이 책을 선택했고 이 책을 통해 내가 멀리 나아갈 수 있는 방법에 대해 배우고 싶었다. 다 읽고나서는 정말 좋은 선택이었다. 하나의 거대한 멘토가 내 옆에 있는 것 같았고 책에서 다시 읽고 싶은 부분이나 실천해야하는 부분은 접어두는데 이 책을 하도 많이 접어서 접힌 부분만 튀어나와있다. 잠시 길을 잃은 것 같은 나에게 여러가지 길을 제시해주는 책이다.

Review

• 실제로 소프트웨어 개발자는 사업 분야를 이해하고 그에 해당하는 소프트웨어를 잘 개발할 수 있어야 할 뿐 아니라 그 분야 권위자가 되어야 한다.
• 자신의 일에 ‘탁월’해지고 싶다면 자신의 일에 열정이 있어야 한다. 좋아하지 않으면 티가 날 것이다. (p65)
• 품질을 근거로 경쟁하려고 한다면 자신의 근무 시간을 연습 시간으로 삼지 말아야 한다. 기술을 연마하는 데 시간을 별도로 투자해야 한다. 그렇다면 무엇을 연습해야 할까? 1. 몸에 익히기 2. 악보 읽기 3. 즉흥 연주.
• 통찰을 얻으려면 기존 코드를 파헤치라. 코드를 읽으면서 전에 해 본 적이 없는 것들고 결코 생각해 보지도 못했던 것을 발견할 것이다. 예술에서처럼 다른 사람들의 습관을 공부하고 배움으로써 자신만의 독특한 소프트웨어 개발 스타일을 계발할 수 있을 것이다.(p105)
• 조작된 상황이라도 급하다는 느낌이 들면 생산성은 쉽게 두세 배가 된다. 시도해 보면 알 것이다. 더 빨리 할 수 있다. 지금 할 수도 있다. 일을 마무리하는 것에 대해 이야기하는 대신 그 시간에 바로 끝낼 수 있다. 프로젝트를 경주라고 생각한다면 감옥살이처럼 지겨움 없이 훨씬 더 빨리 마칠 수 있을 것이다. 계속 움직이라. 밀어붙이는 사람이 되라. 편해지면 안 된다. 항상 이렇게 묻는 사람이 되라. “그런데, 우리가 지금 바로 무엇을 할 수 있을까요?” (p119)
• 제임스의 목표는 매일 몇가지 두드러진 성과를 관리자에게 보고하는 것이었다. 적절한 빈도로 성과를 추적하면 확실히 정체되지 않을 수 있다. 날마다 성과를 하나씩 내겠다고 마음먹었다면, 완벽하게 태스크를 마무리하는 데 2주가 채 걸리지 않을지도 모른다. 이러한 방식으로 생각하며 일하는 것은 굳이 주된 생산의 과정이라기보다는 일종의 습관을 기르는 것이다. 그리고 단위 테스트 스위트의 녹색 막대에 중독된 개발자처럼 오늘의 성과를 끝내지 못하면 좀이 쑤시기 시작할 것이다. 자신의 작업 프로세스를 추적하는 것에 대해 많이 걱정할 필요는 없다. 마이크로소프트 프로젝트로 작업 목록을 짜야 하는 부담감에 비하면 이 정도로 일하는 것은 지극히 사소한 것이기 때문이다. p126

To Do

• 오늘날 시장에 근거해 채택할 기술 목록을 초기, 중기, 말기로 분류해 만들기. 만든 목록을 종이 위에 왼쪽에서 오른쪽으로 나열하기
• 회사 업무와 관련된 업계 잡지를 고르고 업계 웹 사이트를 정기적으로 검토하기 (p34)
• 자신이 감탄하고 있고, 그 프로젝트 개발자들의 수준이 자신이 이루려는 ‘높은 단계’에 있는 것처럼 보이는 1를 하나 고르기. (p38)
  • 기능 구현이나 주요 버그 수정 사항을 골라 해당 코드 짜기
  • 프로젝트 코드의 스타일을 흉내 내기
  • 게임을 하듯이 재밌게 하기
  • 같은 과정을 처음부터 다시 반복하기
• 종이나 화이트보드에 자신의 지식과 능력 중에 다재다능한 부분과 그렇지 않은 요소를 나열하기 (p57)
  • 각 요소에 자신의 특기를 적기
  • 적어 놓은 특기 오른쪽에 ‘배울 것’ 목록에 넣을 주제를 하나 또는 그 이상 쓰기
  • 되도록 빨리 30분을 할애해 목록에 있는 배울 것 항목 중 최소한 하나를 다루기
  • 눈으로 보지만 말고 가능하다면 실제로 다뤄 보기
  • 웹기술이라면 웹 서버 패키지를 받아 스스로 셋업하기
• 깊이 있게 개발하고 싶은 기술의 어떤 측면에 관한 수업을 직장이나 바깥에서 가르칠 기회 찾아보기 p61 (가르치는 것은 무언가를 배우는 가장 좋은 방법이다.)
• 작은 프로젝트를 두 번정도 해보기 p64
  • 한 번은 잘 아는 기술로 하기
  • 다음 한 번은 경쟁 기술로 하되 그 기술의 독특한 방식을 사용해 보기
• 자신이 정말로 열정을 쏟아낼 만한 일 찾기 p68
  • 다음 주 월요일부터 2주간 간단하게 기록하기
  • 일어나 일을 시작할 때마다 신나는 정도를 1부터 10으로 점수를 매기기1
  • 2주간 이 기록을 계속 쓴 후 결과를 검토하기
  • 급상승하는 부분이 있었나? 경향이 있었나? 항상 낮거나 항상 높았나? 이것이 학교 시험이었다면 평점은 얼마인가?
• 직장에서 자신의 업무 중 완전히 이해하지 못한 측면에 대해 생각해 보기 p79
  • ‘어떻게 동작하는가’와 ‘왜 이런 현상이 생기는가(일어나야 하는가)’에 답하기
• 자신의 도구 중에서 중요하지만 소홀히 하는 도구를 하나 골라 집중하기
  • 매일 시간을 들여 자신의 생산성을 높여주거나 개발 환경을 더 잘 제어할 수 있게 해줄 만한 새로운 것 공부하기
• 자신의 분야에서 가장 존경하는 사람을 생각해 내고 그 사람의 가장 중요한 특성 열 가지를 나열하기 p87
  • 중요도 순으로 순위를 매기고 마지막 열에는 순위에서 등급을 뺀 값 적기
• 무엇인가를 정말 배우고 싶다면 그것을 다른 누군가에게 가르쳐 보기 p89
  • 도움 줄 만한 사람을 찾기
  • 온라인 포럼을 찾아 주제를 고르고 참여하여 돕기 시작하기
• 선택한 프로그래밍 환경에서 멀티스레드 프로그래밍이 동작하는 방식에 대해 파고들기 p95
  • 오픈 소스 소프트웨어 중 좋아하는 것에 기능 추가하기
  • 연습하고 싶은 소프트웨어의 할 일 목록을 보고 한정된 시간 내에 새 기능 구현하기(또는 최소한 무엇을 구현할지 결정하기) > 진짜 목표는 자신이 보고 있는 것을 최대한 빨리 이해하는 것
  • 톱코더, 코드 카타 문제를 모두 풀고 문제 푼 경험을 일기에 쓰고 다른 사람들과 공유하기
• 소프트웨어 개발 방법론 한 가지와 책 한 권을 고르고 웹 사이트 보기 p101
  • 메일링 리스트에도 가입하기
  • 방법론을 비판적인 눈으로 보기. 어떤 것이 장점이고 약점이라고 생각하는지
• 프로젝트를 하나 골라 책 읽듯 읽기 p106
  • 의견이 같은 사람들을 찾아 한 달에 한 번씩 만나기
• 지금까지 해온 일 돌아보기 p120
  • 오랫동안 덮어두고 있는 작업을 점검하기
  • 평상시 일과 중 틈틈이 할 수 있는 일 찾기
  • 여러 달 걸리는 프로젝트를 1주일 안에 할 수 있는 작업으로 바꿔보기
• 다음 프로젝트나 유지보수해야 할 시스템을 위해 사용자나 관리자가 요구할 것 같은 것에 대해 노트에 기록하기 p124
• 업무 시간을 매일 몇 분씩 낭비하지만 아무도 그것에 대해 뭔가를 하려고 하지 않는, 그 성가신 일 찾기
  • 자동화할 수 있지만 수동으로 하는 것 찾기
  • 20분동안 차분하게 생각해 보기
  • 좋든 나쁘든 자신의 모든 구상을 적기
  • 20분이 되기 전에 그만 두지 말 것
  • 목록을 만든 후 새 종이에 좋아하는 다섯 가지 항목 적기
  • 다음 주 월요일에 목록에서 첫 번째 항목을 골라 그것에 대해 무언가 하기
  • 화요일에는 두 번째 항목을, 수요일에는 세 번째 항목을, 나머지 요일도 마찬가지
• 부정적으로 불평불만만 하는 사람이 성공하리라고 생각하는가? 뒤쳐지는 것 같지만 지금 현실에 집중하면 목표 자체어만 매달리는 것보다 훨씬 더 목표에 다가갈 것이다. p134
• → 부정적으로 생각하는 상황은 굉장히 자주 나타난다. 그 상황에서 어떻게 벗어날 수 있을지에 대해 생각해보는 시간을 많이 가졌으면 좋겠다. 15분동안 글을 쓰면 스트레스가 풀린다고 한다. 그런 스트레스 받는 상황에서 아무런 맥락없는 글을 적어보는게 어떨까???
• 현재 업무 목표를 적기
  • 다음에 어디로 가고 싶은지 생각하는 대신 지금 하는 일을 끝낼 때 이루고 싶은 것을 생각하기
  • 이 일을 훌륭하게 마치면 무엇을 만들어낼 수 있을까?
• 눈에 띄게 하기 p139
  • 지겨운 일을 가지고 동료들과 경쟁해 보기
  • 자랑할 권리(또는 상품)를 놓고 경쟁하기(단위테스트라던지?)
  • 프로젝트가 끝날 때 우승자에게는 그 사람의 허드렛일을 한 주 내내 다른 팀원 들에게 시킬 수 있게 해주기
• 회사가 비용을 얼마나 절약할 수 있게 했는지 수익에는 얼마나 기여했는지 생각해보기 p141
  • 그 가치의 양을 가장 잘 잴 수 있는 방법에 대해 관리자와 이야기해 보기
  • 어떻게 하면 회사 비용을 독창적으로 절약할 수 있을지 고민하기
  • 어떻게 하면 개발 팀이 좀 더 효율적으로 변화될 수 있을지 고민하기
• CIO에게 들었던 진정한 충고 한 가지(그리고 몇 번이고 들었다)는 결코 편해지면 안 된다는 것이었다. p145
• 만들었거나 유지보수하는 코드와 수행하는 모든 태스크를 목록으로 만들기
  • 팀에서 전적으로 자신에게 의존하는 것을 기록하기
  • 이 각각의 항목을 할 일 목록에 적기
  • 각각의 코드나 일을 문서로 만들고, 자동화하거나 리팩터링해 팀원 누구나 쉽게 이해할 수 있게 하기
  • 이 목록이 다 없어질 때까지 일하기
  • 팀의 리더, 팀원들과 문서를 적극적으로 공유하기
  • 문서는 어딘가에 반드시 저장해 팀원들이 쉽게 볼 수 있게 하기
  • 이 연습을 정기적으로 되풀이하기
• 나쁜 코드를 물려받았다는 제약이 없고 다룰 수 있는 자금이 부족하지 없다면 관리자와 고객은 우리에게 당연히 더 많이 기대한다. 그리고 프로젝트를 할 때는 업무가 개선되리라는 기대가 있다. 업무가 개선되지 않으면 실패한 것이다. p151
  • 품질을 나타내는 측정 요소 목록을 만들고 측정하기
  • 개선한 후 다시 측정해 바라던 개선을 정말 했는지 검증하기 개선했다면 팀, 고객과 공유하기
• 일할 수 있는 시간이 너무 많으면 근무 시간은 파악할 수 있는 가치 측면에서 눈에 띄게 줄어든다. p155
  • 푹자고 아침을 먹고 일 시작하기
  • 네 시간동안 치열하게 일하기
  • 한 시간동안 점심을 먹고 그런 다음 완전히 지쳐서 더 이상 일하지 못하겠다는 느낌이 들 정도로 치열하게 네 시간 더 일하기
• 우리는 모두 실수하기 때문에 다른 사람들도 실수한다고 생각한다. 따라서 우리가 저지르는 실수에 대해 서로 를 비난하지 않는 것이 합당하다. p159
  • 알게 되자마자 문제를 제기하기
  • 오래 숨기려 하지 말기
  • 책임 지기
  • 해결책을 제시하기
  • 자신에게 해결책이 없으면 해결책을 찾기 위한 착수 계획을 제안하기
  • 구체적이고 예측할 수 있는 기간으로 말하기
  • 도움 구하기 팀이 상황을 헤쳐 나가는 것을 돕는 동안 겸손한 태도로 자의식을 잠시 제쳐 둔다면 팀원, 경영진, 고객은 훨씬 더 긍정적인 눈으로 여러분을 볼 것이다.
• 당황한 일지를 꾸준히 쓰기 p169
  • 자신의 지각과 감정을 실시간으로 인식하는 능력이 더 강화되게 계발하는 것이다. 어떻게 대응했는지 분석해서 방법 배우기
• 할 일이 너무 많을 때 계획을 세우기 p171
  • 내일 일을 할 때 목록을 꺼내 첫 번째 항목부터 시작하기
  • 목록에 있는 각 항목을 끝낼 때 마다 ‘완료!’라고 표시하기
  • 일일, 주간 계획을 전술 계획으로 생각하기
  • 성취하고 싶은 좀 더 전략적인 목표에 초점을 둔 30일, 60일, 90일 계획 세우기
• 베끼기! 원본의 어감과 형식을 맛볼 수 있다.
• 소프트웨어 관련 문제를 토론할 떄는 고객에게 약간 쉽게 이야기하기 p191
  • 너무 기술적이지도 너무 우둔하지도 않게, 섬세하게 균형을 잡아야 한다.
• 개발 일기 쓰기 p195
  • 매일 조금씩 쓰면서 뭘 했는지 기록하고, 설계 결정에 대해 타당성을 증명하고 어려운 기술적 또는 전문적 결정을 자세히 조사하기
  • 자기 자신만 보는 것이라 하더라도 자신의 입장을 분명하게 표현할 수 있도록 작문 품질과 능력 향상에 주의를 기울이기
  • 이따금 옛 글을 읽고 비평한 뒤 새 글을 수정하기
• 최근 성과 목록 만들기 p203
  • 각각의 사업적 이익 적기
  • 목록에 있는 성과 중에 사업적 이익을 쓸 수 없는 것이 있다면 관리자나 믿을 만한 사람에게 어떻게 설명할 것인지 질문하기
• 자신이 흥미롭다고 생각한 이야기에 대해 쓰는 것으로 시작하기 p208
  • 글을 쓰고 링크를 걸면서 블로그 세계가 그 자체로 사회적 네트워크, 즉 자신이 만들기 시작할 경력 네트워크의 소우주임을 발견할 것이다. 여러분의 생각이 결국 다른 사람의 피드 수집 소프트웨어에 나타나기 시작할 것이고 그 사람들이 여러분의 아이디어에 대해 쓰고 그것을 퍼뜨릴 것이다.
  • 글쓰기 기술을 연습하기. 기술이 좋아질수록 자신감도 늘어날 것이다.
• 자신의 브랜드를 만들기 p212
  • 나의 이름이 곧 브랜드다.
  • 구글은 결코 잊지 않는다.
• 가장 똑똑하거나 빠른 사람이 되는 것으로는 충분치 않다. 실행해내야 한다. p221
  • 주제를 습득하는 데서 그치지 말고 그것에 관한 책을 쓰기
  • 1주일짜리 프로세스였던 것을 5분짜리 프로세스로 줄이는 코드 생성기를 짜라.
  • 동료 사이에서 존경받으려 하기보다는 자신이 집중하는 기술에 대한 세미나와 연수를 통해 도시에서 가장 알려진 권위 있는 개발자가 되라.
  • 다음 프로젝트에서 전에는 생각지도 못했던 것을 해라.
• 가장 좋아하는 소프트웨어를 하나 고르고 그 창시자에게 이메일을 보내기 p225
  • 그 뒤 제안을 하거나 그 사람과 인간관계를 확립할 수 있는 다른 시도를 해보기
  • 그 소프트웨어가 자유 소프트웨어나 오픈 소스라면 돕고 싶다고 제안해 보기
  여러분을 가르칠 수 있거나 여러분이 일을 찾을 수 있게 도울 수 있는 똑똑하고 배경 좋은 사람들과 어울리는 것은 스스로를 개선할 가장 좋은 방법인데도 시도해 보기를 두려워하는 사람이 많다. 긴밀한 전문가 커뮤니티의 일부가 되는 것은 연주자, 미술가, 다른 장인들이 오랜 세월 각각의 예술 형식을 발전시키면서 유지해온 방법이다.
• 존경하거나 배우고 싶은 지역의 누군가를 떠올리고 그 사람을 만날 수 있는 상황을 알아보고 찾아가서 대화 시작하기
• 주 중에 시간을 내 첨단 기술 연구하기 p235
  • 최소한 매주 두 시간 정도 여유를 만들어 새 기술을 조사하고 그 기술에 능숙해지도록 연습하기
  • 이 새 기술들로 실무 작업 해보기
• 자신이 테스터나 프로젝트 관리자인 것처럼 일해 보기 p238
  • 날마다 해야 하는 일 중에 전혀 생각하지 못했던 역할은 무엇인가?
• 시간을 들여 경력의 시각표를 분명하게 계획하기 p245
  • 어디에서 출발했고 각 단계에서 자신의 기술과 일이 무엇이었는지 나타내기
  • 어디에서 조금씩 나아졌는지, 어디에서 크게 도약한 것처럼 보이는지에 주목하기
  • 주요한 발전을 이루는 데 걸린 평균 시간에 유의하기
  • 자신의 경력으로 미래를 예상할 때 이 로드맵을 사용하기
  자신의 역사가 담긴 분명한 그림이 있다면 실제적인 목표를 스스로 세울 수 있다.
• 360도 리뷰하기 p251
  • 편하게 조언을 구할 수 있는 사람 명단 만들기
  • 전문가로서 중요한 척도라고 믿는 열 가지 특성 목록 만들기
  • 이 목록을 설문지로 바꾸기
• 일지를 쓰기 시작하라.
  • 무슨일을 하는지, 무엇을 배우는지 업계에 대한 자신의 의견쓰기
  블로그나 개인 일기도 괜찮다.
• 개선하기 위해 어제 했던 것보다 오늘 더 나은 행동을 어떻게 취할 것인가? p264
  • 오픈소스 프로젝트에 패치를 제출하고 자기 블로그에 심사숙고해 글을 써서 발행하라.
• 즐기라 p272
• 이 일은 흥미진진하다. 창조적이다. 소프트웨어 개발을 깊은 사고를 요하고 날마다 만나는 사람 대부분이 할 수 있다고 상상도 못할 어떤 일을 할 수 있다는 감각을 지니게 된다는 보상을 받는다.

옮긴이의 후기

마지막으로 이 땅의 모든 개발자들이 행복하게 개발할 수 있는 세상이 오기를 진심으로 기원한다.