"사랑하지 않으면 떠나라!" 를 읽고

"모니터 앞에 앉아 반복된 코드뭉치를 바라보는 개발자들에게
모니터 밖의 넓은 세상에 대해..."

───────────────────────────────────────────────
사랑하지 않으면 떠나라!
⊙ 제 목 : 사랑하지 않으면 떠나라!
⊙ 지은이 : 차드 파울러(지음), 송우일(옮김)
⊙ 장 르 : 컴퓨터관련 교양
⊙ 펴낸 곳 : 인사이트
⊙ 펴낸 날 : 2008년 1월 11일
⊙ Page : 295 쪽
⊙ ISBN : 9788991268357


⊙ 평점 : ★★★★☆

───────────────────────────────────────────────

"이 책은 다른 컴퓨터 교양서적과 마찮가지로
실무에 직접적인 도움을 제공하진 않는다.
하지만 꺼져가던 개발에 대한 열정은 다시 불타오르게 한다."



인상깊은 부분

48쪽: 그냥 앞서 갈 것인가, 위험까지 무릅쓸 것인가?

초기에 자바에 투자하면 다가오는 거대한 기술 추세에서 리더가 됐을 것이다. 물론 그렇게 했다면 여러분은 옳은 결정을 한 것이다. 또한 개인적으로 자바에 투자하기로 패를 던졌다면, 자바에 대한 개인적인 투자는 매우 수지 맞는 것이 됐을 것이다. 위험이 큰 만큼 보상도 큰 것이다.
...
BeOS는 위험하지만 매력적인 기술 투자였다. 그러나 BeOS에 경력을 투자하기로 한 개발자들에게는 구체적이고 장기적인 보상을 주지 못했다. 위험은 컸지만 보상은 없었다.

57쪽: 새 프로그래밍 언어를 배우라.

자바 또는 C# 프로그래머라면 강 타이핑(strong typing), 정적(static) 타이핑을 쓰지 않는 스몰토크나 루비를 배워 보라. 또는 오랫동안 객체지향 프로그래밍을 해왔다면 해스켈(Haskell)이나 스킴(Scheme)같은 함수형 언어(functional language)를 시도해 보라. 전문가가 될 필요는 없다. 새 프로그래밍 환경의 차이점을 정확히 느낄 만큼 코드를 충분히 하나하나 살펴보라. 그다지 낯설게 느껴지지 않는다면 엉뚱한 언어를 골랐거나 옛 사고방식을 새 언어에 적용하고 있는 것이다.

69쪽: 진정한 전문가가 되라.

닷넷 전문가라는 게 닷넷 이외에 아무것도 몰라도 된다는 이유가 되지 않는다. 닷넷 전문가라는 것은 닷넷과 관계가 있는 일에 권위가 있다는 의미다. IIS(Internet Information Server)가 죽어서 재시동해야 하는지 질문하면 "문제없어요"라고, 비주얼 스튜디오 닷넷(Visual Studio.NET)과 소스 제어 통합에 대해 물으면 "어떻게 하는지 보여줄게요."라고, 모호한 성능 문제 때문에 플러그를 뽑아버리겠다고 고객이 위협하면 "30분만 주세요."라고 대답할 수 있어야 한다.

79쪽: '가장 못하는 사람이 되는' 상황을 스스로 찾으라.

자신이 감탄하고 있고, 그 프로젝트 개발자들의 수준이 자신이 이루려는 '높은단계'에 있는 것처럼 보이는 오픈소스 프로젝트를 하나 고르라. 프로젝트의 할 일 목록이나 메일링 리스트 아카이브를 조사해 기능 구현이나 주요 버그 수정 사항을 골라 해당 코드를 짜라! 프로젝트 코드의 스타일을 흉내 내라. 게임을 하듯이 재밌게 하라. 자신의 설계와 코드를 프로젝트의 나머지 코드와 구별할 수 없게 만들면 원 개발자라도 누가 그 코드를 썼는지 기억할 수 없을 것이다. 그 다음에 자신의 작업에 만족하면 패치로 제출하라. 패치가 좋다면 프로젝트에 받아들여질 것이다.
82쪽: 사랑하지 않으면 떠나라!
바에서 귀가 먹먹해진 저녁을 보내고 집에 늦게 돌아와 프로그래밍 설명서가 있는 고퍼(Gopher) 사이트를 돌아다니다 보면 해가 뜨곤 했다. 해가 뜨면 눈을 좀 붙인 후 일어나 공부를 계속하다가 다시 연주하러 나갔다. 공부하는 도중에 좋아하는 컴퓨터 게임을 하면서 놀기도 하고 다시 고퍼를 가지고 빈둥거렸다. 결국 어떤 컴파일러든지 쓸 수 있게 됐다.
...
열정이 충만한 것처럼 한동안은 속일수 있겠지만 열정 부족은 자신과 자신의 일에 나쁜 결과를 가져올 것이다.
110쪽: 연습, 연습 또 연습
몸에 익히기 : ... 현대적인 프로그래밍 언어들은 대부분이 모든 영역에 대한 풍부하고 강력한 라이브러리를 제공하지만 소프트웨어 개발자는 작은 서브셋만 배우려는 경향이 있다. 결국 같은 코드를 비효율적으로 짠다. 개발자들이 이용할수 있는 도구 전체를 습득했다면 그렇지 않았을 것이다.
악보 읽기 : ... 기능을 고른 후 소프트웨어 소스코드를 다운로드하고 살펴보기 시작하라. 어디를 봐야 할 것인가? 어떤 요령으로 코드 중 주요 부분을 찾을 것인가? 출발점은 어디인가?
즉흥 연주 : ... 사고를 날카롭게 하고 즉흥 코딩 솜씨를 향상시킬 멋진 방법으로는 스스로 제한 조건(constraint)을 두고 연습하는 것이 있다. 간단한 프로그램을 골라 제한 조건을 두고 작성해 보라.
129쪽: 자동화 기술을 이용해 일자리를 찾아라.
평소에 되풀이하는 작업을 하나 고르고 그 작업에 대한 코드 생성 프로그램을 하나 짠다. 단순하게 시작한다. 재사용성에 대해서는 걱정하지 말라. 코드 생성 프로그램 때문에 시간을 절약할 수 있다고 확신하기만 하면 된다. 여러분이 만드는 추상화 수준을 높이는 방법에 관해 생각해 보라.
143쪽: 매일의 성과
간단한 목표를 세우고(일간, 주간 또는 자신이 할 수 있는 아무것이나) 이러한 성과를 추적하다 보면 자신의 행동이 근본적으로 바뀔 수 있다. 두드러진 성과가 무엇인지 찾을 때, 자신의 활동이 비즈니스 가치에 바탕을 두고 있는지 평가하여 우선순위를 정하는 과정을 자연스럽게 거치게 된다.적절한 빈도로 성과를 추적하면 확실히 정체되지 않을 수 있다. 매일 성과를 하나씩 내겠다고 마음먹었다면, 완벽하게 태스크를 마무리하는 데는 2주일이 채 걸리지 않을지도 모른다.
156쪽: 오늘은 얼마나 잘 할 수 있을까?
그렇다면 어떻게 해야 일과 중의 평범하고 자질구레한 일(아마 개발자들의 시간 중 80% 이상을 차지할 것이다)을 하면서도 창조력을 발휘하고 스스로에게 도전 의식을 불러일으킬 수 있을까? 지겨운 일을 완벽하게 하려고 노력해 보는 건 어떨까? 예를 들어 단위테스트를 싫어한다고 하자. 프로그래밍은 좋아하지만 자동화된 테스트 코드를 짜야만 하는 것은 성가시다. 테스트를 완벽하게 하려고 애써보는 것은 어떨까?
174쪽: 8시간 열중하기
시간의 가치가 떨어지면 일을 하기 위해 더 많은 시간이 필요하다. 로버트 마틴의 8시간 열중하기는 여러분에게 제한(constraint)을 두고 그 제한을 다루는 법을 알려준다. 여러분은 일하면서 다음과 같이 생각한다. '여덟 시간 밖에 없어! 자, 부지런히 일해야지!' 시작과 끝 시간에 엄격한 제한을 두면 자연히 시간을 더 효율적으로 조정한다. 그날 해야 할 업무를 우선순위에 따라 나열하고 한 번에 하나씩 해치우기 시작할 것이다.
178쪽: 실패하는 법을 배워라.
알게 되자마자 문제를 제기하라. ... 소프트웨어 개발과 테스트에서처럼 실수를 일찍 잡아내면 늦게 잡아내는 것보다 문제가 줄어든다.
책임을 지라. ... 혼자서 다 비난 받는 게 아니더라도 책임을 지고 나아가라. 목표는 가능한 빨리 이 시점을 지나가는 것이다.
해결책을 제시하라. 자신에게 해결책이 없으면 해결책을 찾기 위한 착수 계획을 제안하라. 구체적이고 예측할 수 있는 기간으로 말하라.
도움을 구하라. 문제에 대한 비난을 혼자서 받는다 하더라도 자존심 때문에 해결 과정에서 도움을 거절해 상황을 악화시키지 말라.
209쪽: 개발 일기를 쓰기 시작하라.
매일 조금씩 쓰면서 뭘 했는지 기록하고, 설계 결정에 대해 타당성을 증명하고 어려운 기술적 또는 전문적 결정을 자세히 조사하라. 자기 자신만 보는 것이라 하더라도 자신의 입장을 분명하게 표현할 수 있도록 작문의 품질과 능력 향상에 주의를 기울이라. 이따금 옛글을 다시 읽고 비평해 보라. 옛 글에서 좋았던 것과 나빴던 것을 바탕으로 새 글을 수정하라. 이러한 일기를 통해 글쓰기가 개선될 뿐만 아니라 자신이 내린 결정을 좀더 잘 이해하는 데 이용할 수 있다. 또한 과거에 어떤 일을 왜, 어떻게 했는지 다시 봐야할 필요가 있을 때 참조할 수도 있다.
249쪽: 주 중에 시간을 내 첨단기술을 연구하라.
최소한 매주 두 시간 정도 여유를 만들어새 기술을 조사하고 그 기술에 능숙해지도록 연습하기 시작한다. 이 새 기술들로 실무 작업을 해 본다. 간단한 애플리케이션을 만들라. 현재 기술 프로젝트에서 어려운 부분을 새 기술 버전으로 프로토타입을 만들어 둘 간의 차이가 무엇이고 새 기술로 무엇을 할 수 있는지 이해하라.
294쪽:
인도에서 깨달은 것이 하나 있다면, 미국인들은 인도인들이 빈곤 속에 불행하게 산다고 여기지만 그 인도인들이 평균적으로 미국인들보다 행복하다는 것이다. 나는 몹시 가난한 사람들을 만났다. 하지만 그 사람들은 작은 집에 살면서도 미국인들보다 단연 건강한 전망을 계발하고 있었다. 이 경험에서 나는 '지금 무슨 일을 하는지'나 '무엇을 가졌는지'가 중요하지 않다는 것을 진짜 배웠다. 그것은 어떻게 받아들이냐에 달려 있다. 그것은 내면의 문제이다. 만족스런 경력을 만들어 나가려면 항상 적극적으로 찾아야 하고 그것을 목적을 갖고 판단하고 결정해야 한다. 

관련 사이트


TIOBE Software : 프로그래밍 언어 인기도 측정
TopCoder : 프로그래밍 겨루기 사이트
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 외계고양이

이 글의 관련글

2008/08/24 22:04 2008/08/24 22:04
, ,
Response
No Trackback , No Comment
RSS :
http://nekothink.com/rss/response/11

Trackback URL : http://nekothink.com/trackback/11

Leave a comment
[로그인][오픈아이디란?]

블로그 이미지

게임 개발에 관심많은 고양이

- 외계고양이

Categories

Home (16)
리뷰:Review (6)
메모:Memo (4)
작업일기:Log (4)
OpenLibrary (2)

독도 광고 모금 캠페인