| 무엇을 함께 하고 있다. 비슷한 생각을 하고 있고, 같은 어려움을 겪고 있으며, 동일한 방향을 바라 보고 있다면 알게 모르게 상당한 연대의식을 느끼게 된다. 패거리주의가 아닌 절대 공감이라는 공통 분모는 누군가의 고민을 들어주기도 하고, 누군가의 힘이 되게 하는 구심점으로 작용한다. 지식 산업에 종사하는 사람이라면 커뮤니케이션과 협력의 중요성을 누구보다 잘 알 것이다. 혼자서 움켜 쥐겠다고, 그것의 권한자로써의 지위만을 유지하려는 자에게는 퇴보만이 기다리고 있을 뿐이다. 현대의 복잡성과 기술의 발전 속도를 혼자서 감당할 수 없기 때문에 활발한 소통은 난관을 해쳐나갈 수 있도록 해결점을 제시해 줄 것이며, 비전을 보여줄 것이다. 그런 점에서 블로그라는 1인 미디어의 위력을 이 책은 충분히 보여준다. 독창적이고, 풍부한 담론들이 광케이블의 전파 속도를 타고 전 세계를 휘젓는다. 결과적으로 먼 타국의 소프트웨어 엔지니어의 글이 2만 2천원, 400페이지 가량의 두툼한 책으로 탄생되기까지는 국적과 온-오프라인을 넘나드는 수많은 블로거들의 지지와 관심, 도움이라는 화려한 배경이 있었기 때문이다. 그런 점에서 구어체가 많고, 문화의 벽을 느끼게 만드는 많은 요소를 자연스러운 번역으로 문화 충격을 완화시키고 있다는 점은 이 책이 가지고 있는 장점 중의 장점이다. 그러한 사실은 책의 여러 곳에서도 확인 될 수 있고, 웹에서 확인할 수 있다. 많은 개발자들의 공감이 만들어 낸 작품이기 때문에 완성도는 한껏 높아졌다. 또한 책에서 느낄 수 있는 만족감은 절대 후회 없음이다. 일상의 활력을 불어 넣어줄 정도라면 설명이 제대로 될까. 어떤 글들이길래 이렇게 칭찬을 늘어 놓을까? 개발자의 시선이 담긴 에세이, 기술 동향, IT 비즈니스, 소프트웨어 개발, 관리, 시스템 운영 등 소프트웨어 개발 전반에 대한 통찰력, 해석, 정보가 담겨져 있다. 심지어 개발자 면접 방법, 명세서 작성법까지 방대하면서도 구석 구석을 이야기하고 있기에 CEO부터 말단 개발자까지 대상 독자층은 광범위하다고 볼 수 있다. 다른 소프트웨어 공학을 다루는 책들처럼 재미없어 보이지만, 차별성은 몇 페이지만 읽어도 느낄 수 있다. 딱딱하게 타버린 삼겹살 같은 소프트웨어 공학책이 절대 아니다. 재미가 장난이 아니다. 무슨 재미? 씹는 재미. 현실에 대한 정확한 지적만큼 통쾌한 재미는 없다. 합리적이고, 효율적인 방법론을 제시해주는 것만큼 시원한 재미는 없다. 게다가 잘 알려지지 않는 사실을 드러내서 알려주는 미덕은 말초신경을 자극하는 그것과 같다. 특히 3년간 저자가 일했다던 MS사의 비화는 구경거리 중의 구경거리이다. MS사의 발전 역사와 현재의 MS사의 덜그덕거림에 대한 통렬한 비판은 개발자들의 관심을 바짝 당긴다. ‘MS사가 윈도우 API의 지배력을 잃고 있다’라는 한 문장만 봐도 다음 책장을 넘겨 보지 않을 수 없지 않은가. 저자가 느끼는 MS사에 대한 느낌은 한 마디로 표현하자면 표지의 그림처럼 ‘Anatomy of Melancholy이다. 우울의 해부학, MS사에 대한 상당한 배신감을 느낄 수 있다. 이용당한 느낌. 버림받은 느낌. 그것을 낱낱이 해부하여 까발리고 싶은 그 심정. 바로 그것이다. 이전 버전과의 호환성, 대중성의 조화라는 MS사의 최대 강점이자 발전 원동력을 폐기처분하고(얼마전에 떠들썩 했던 VB6.0의 지원 중단), 개발자와의 공생적인 관계를 깨버리는 독단적인 태도는 MS사의 몰락을 불러올 수도 있음을 은근히 내비친다. 저자의 글을 모두 받아들일 수 없더라도, 그러한 환경에 있지 않더라도 현재의 상황에서 최선의 시나리오와 알고리즘을 만들어 내는게 개발자 아니던가. IT노가다 업종에 종사하시는 분들에게 필독서가 될 듯 싶다. 영양가 있고, 맛도 있고, 즐겁게 요리 방법까지 알려주니 모자람이 없다. |
|
IT관련 직종에 있으면서 내가 읽었던 대다수의 책은 경제, 경영관련 서적이었다. 그 외에는 사회, 심리, 예술, 역사 서적이었고, 어쩌다 과학관련 서적도 읽었다. 그런데 이 책과 같이 현재 내가 하고 있는 일에 대한 책을 읽은 경우는 극히 드문 경험이라 할 수 있다. 아마 1~2년 전에 IBM관련 책을 읽은 뒤로는 처음인거 같다.
이 책을 구입하게 된 동기는 사연이 좀 있다. MS에서 오피스 개발팀의 PM을 구한다는 Job Offer에 우연히도 걸려들어 2번이나 면접을 보게 되었는데, 면접관들이 했던 공통된 말이 바로 Spec을 쓸 줄 아는가였다. 당연히 쓸 줄 알지만 그들이 이야기하는 Spec이나 PM(Project Manager가 아니라 Program Manager)의 역할이 좀 유별나다는 것을 인지하게 되었고, 이리저리 찾아보던 중 조엘의 블로그까지 이르게 되었으며, 거기서 해답을 찾게 되었다.
어쨌든 이 책은 IT관련 분야 종사자라면 누구나 읽을만한 책이지만, 결국 소프트웨어 개발자와 프로젝트 관리자가 가장 공감할만한 책이다. 특히 마이크로소프트의 개발툴을 사용하는 개발자라면 아주 유용한 책이란 생각이 든다. 저자가 마이크로소프트에서 3년간 근무한 경험이 책의 밑바탕에 깔려 있기 때문이다. 그리고 책 내용의 절반 이상이 마이크로소프트와 관련된 내용들이란 사실도 그러하다.
이 책은 소프트웨어 프로그래머이자 조그마한 소프트웨어 기업을 이끌고 있는 조엘 스폴스키라는 사람의 블로그 내용을 그대로 번역한 책이기에 딱딱한 IT전문서적은 아니다. 하지만 이 책을 읽으면서 조엘의 소프트웨어 개발 내공이 느껴지는 것은 역시 다양한 개발툴과 개발방법에 대한 설명이 꽤 길게 이어지기 때문이다. 아마 전산 비전공자라면 잘 이해못할 내용도 상당부분있지만 그냥 넘어가도 괜찮을 것이다.
책 내용이나 번역은 큰 무리가 없어보이지만 너무 많은 내용을 책 한권에 담으려다 보니 책도 두꺼워진거 같고 무엇보다도 활자 크기가 작고 책에 여백이 없어 보인다. 이것도 역시 전형적인 전산쟁이들의 특징일까? 어쨌든 오랜만에 시원한 글을 읽은 셈이다. 현장의 생생한 경험을 고스란히 담고 있어서 매일 부딪히는 그런 문제들을 명쾌한 문장으로 잘 짚어준것 같다. 결국 내가 현업에서 프로그래머에게 또 고객에게, 상사에게 하고 싶은 말을 이 책이 다 하고 있는 것이다.
- 2005/11/28 개인블로그 작성 - |
| 학교나 학원을 졸업하고 소프트웨어 개발 실무에서 몇 년 일하다보면 누구나 이야기할 거리가 한 보따리다. 때론 교과서도 틀릴 수 있다는 걸 알게 되고, 읽을 땐 몰랐던 대가들의 책들이 가슴에 와 닿기도 한다. 반면 초보들에게 소프트웨어 개발 실무는 미지의 세계다. 학교에서 비주얼 C++ 쓰는 법을 배워야 한다는 걸 말하는 것이 아니다. 하지만 학교에서 배운 좋은 기본기만으로는 뭔가 부족하다. 조엘 온 소프트웨어는 모든 개발자들을 위한 아주 경쾌한 책이다. 하지만 마냥 가볍지만은 않다. 쉽게 이해할 수는 있지만 저자의 지식과 경험을 충분한 깊이로 공유할 수 있는 책이다. 예를 들어 우리는 "재사용"을 무조건 좋은 일이라고 배운다. 따라서 "Not Invented Here" 신드롬은 배격해야 할 대상이다. 하지만 이 책에서는 마이크로소프트 내에서도 일정을 잘 지키고 높은 품질의 제품을 내놓기로 유명한 엑셀 팀이 왜 팀 전용 컴파일러까지 별도로 쓰면서까지 외부에 의존하지 않으려지를 소개한다. 또 요즘 프로그래머들 중 코드된 문자 집합(coded character set)과 문자 인코딩 방식(character encoding scheme)의 차이를 아는 사람을 찾아보기는 참 어렵다. 그러다보니 유니코드의 본질도 모르고 그저 16비트로 표현된 글자라고만 안다. 이럴 때는 이 책의 유니코드에 대한 소개를 읽어 보기 바란다. 정말 쉽게 쓰여 있다. 개인적인 생각을 적은 책이라 때론 동의하기 힘든 내용도 있지만 동의하든 동의하지 않든 즐겁게 읽을 수 있는 책이다. 경험이 많은 개발자들은 경험한 사람만이 알 수 있는 은밀한 이야기를 나누는 재미를 느낄 것이고, 초보 개발자들은 베테랑이 쉽게 설명한 상식이나 경험을 접할 수 있을 것이다. 개발 관리를 하든 일선 개발자든 누구든 재미있게 읽고 많은 것을 얻을 수 있는 책이다. 마지막으로 꼭 언급하고 넘어가야 하는 부분은 이 책이 결코 번역하기 쉽지 않은 책이라는 점이다. 원문이 블로그고 가볍게 읽을 수 있게 쓰다보니 농담이 많이 섞여 있다. 그러다보니 웬만한 원어민도 잘 모르는 특이한 표현들도 종종 찾아볼 수 있다. 하지만 이 책의 역자들은 구글에게 물어봐도 쉬 찾기 어려운 그런 부분을 꼼꼼히 찾아서 잘 번역하고 있다. 또 책에 쓰인 관점에 무리가 있거나 정확치 않은 부분에서도 어김없이 역자들의 해명(?)을 찾아볼 수 있다. 좋은 책의 잘된 번역본을 보는 것은 그리 쉽지 않다. 그런 면에서 조엘 온 소프트웨어라는 좋은 책을 접하게 해 준 역자들께도 감사 드린다. |
| 글속에 녹아든 저자의 혜안에 정말 놀라움을 금치 못하며 읽었다. 또한 역자들의 수고와 실무경험이 녹아든 번역에 또한 감사하다. 역자가 한동안 같이 일했던 사람이기에 그의 위트,유머,어투가 살아있는듯해서 더욱 반가웠다. 난 HW 엔지니어로서 팀을 이끌며 SW 프로젝트를 이해하고 SW쟁이들을 이해하기 위해 처음 이책을 뒤젹였지만, 실제 이 책의 내용은 IT종사하는 사람들 전반 특히, IT벤처를 한답시고 어깨에 힘넣고 목에 기부스를 한 경영진들에게 반드시 한번씩 읽히고 싶다. 그들이 잘못된 개발정책,개발방항이 얼마나 많은 순진한 엔지니어들을 골로하게 하고 있는지 꼭 이 책을 읽혀서 알게 하고 싶다. 일부 몰지각한 개발팀장들도 마찬가지다. 오늘도 난 인터뷰시 책을 들고 들어가 질문하며, 이따 저녁에는 스톱워치를 사러 갈 생각이다. |
|
서울지하철 2호선으로 출퇴근을 하면서 책을 읽고는 한다.
정말 오랜만에 책에 빠져 2호선을 한 바퀴 더 돌며 책장을 넘기게 해 준 책이다.
다른분들 리뷰처럼 이책의 내용에 대해서는 별 다섯이 당연하다고 생각한다.
한가지 더 반가운 점은 역자들의 역할이 훌륭하다는 것이다.
다수의 번역서들이 독자와 원 저자와의 대화에 끼어들어 그건 내가 설명하겠다는 식의 설명으로 기분을 상하게 하는데 적어도 이책은 조엘과 독자와의 대화를 보다 부드럽게 이끄는 유능한 쇼호스트 역할을 역자들이 훌륭히 해내고 있다고 생각한다.
이전 '쾌속개발'에서의 역자들의 위치보다 보기좋은 위치에서 어려운 은유들을 멋지게 번역한 역자들에게도 박수를 보내본다.
또 글을 읽으면서 느끼는 글의 무게도 '블로그'라는 매체를 모니터앞에서 대할 때와 크게 다르지 않은 것이 편안하게 책장을 넘길수 있게 해준다. [인상깊은구절] 방법론과 스타프로그래머 등장의 반복에 대한 저자의 혜안이 놀라울 따름이다. 레이먼드의 저서와 주장에 대한 저자의 시각에도 역시 공감한다. 전 직장이었던 MS에 대한 저자의 애정과 이에 대한 이야기들 맘에든다. 내용은 사서 읽어보셔야.... |
|
읽는 내내 저자의 명쾌한 시각에서 속시원함을 느끼기도 하고
그의 강렬한 주장과 시각에서 약간의 거부감을 느끼도 했다.
어떻게 이렇게 깊은곳까지 관찰해내는 시각과 앎을 가질수 있을까 정말 부러웠다.
조엘 테스트라는 웹상에서 번역된 그의 포스트를 보고 그의 블로그를 알았다.
그리고 몇달전 책으로 번역되어 나온다는 말을 듣고는 기다렸던 책이었다.
읽으면서
아~~~ 하는 탄식과 감탄, 황당함, 부끄러움, 웃음등의 감정을 멈출수 없었다.
인상깊었던 부분들은 그가 냉철하게 열거한
1. 조엘테스트
2. 유니코드와 문자 집합에 대한 고찰
3. 명세서작업
4. 일일빌드
5. 코드관리
6. 테스터두기
7. 충돌보고서
8. 인터뷰 가이드... 이부분에서 난 부끄러움을 감출수가 없었다...
그의 기준에 나는 얼마나 부합되고 있는지를 스스로 측정하면서...
얼마나 부끄럽고 숨고 싶었는지...
더 열심히 하고 더 손에 흙을 묻혀야 함을 느낀다...
그리고 ... 등등등.... 줄줄이 열거하자만 끝이 없겠다.
각 장마다 주옥같은 글들이 나의 눈앞에서 넘실댄다..
작가는 그의 말대로 사업가다.
개발자로서 그리고 개발자 출신의 사업가로서 IT업계의 개발환경을 바라보는
탁월한 시각과 독설로 가득하다.
특히 자사의 광고를 위해 쓴 글들이 여기 저기 보이지만....
그 글 조차도 그 방향에 대해 왜 그렇게 했는지 분명하고 ... 그리고 매우 논리적이다.
어떻게 해야 자신의 울타리가 굳건해 지는지 알고 있는 ... 그런 내용들로 가득하다.
가장 많은 내용은 역시 자사의 소프트웨어 관련한 내용이 많다.
그런 내용들조차 그의 해박한 지식과 산 경험 그리고 고민한 흔적으로 가득한
논리적인 결과를 말하고 있다.
그의 말들(물론 블로그에 올렸던 구어체 형식의 글들을 그대로
우리나라의 정서에 맞게-번역자가 참 고생했을듯
싶다 - 번역을 했기 때문에 글이라기 보단 대화 형식이 많았다. )
이 다 옳다고는 생각하지 않는다.
다만, 구구절절 자신의 의견에 대한 합당한 이유가 있다.
상대방이 반박하기 어려울 정도의 논리와 전체를 바라보는 시각을 가진.
다만 강한 표현의 어구로 인해 반발감이 생기는 경우도 적지 않겠다.
그런 부분들은 ... 블로그라는 매체의 특성상 생겼던 경우라 이해하며 읽었다.
무언가 길을 확실히 제시하거나 답을 제시하는 말들은 드물다.
다만. 독자에게 커다란 생각꺼리와 자신만의 일관된 어떤 원칙을 계속 해서 말한듯 싶다.
요즘 많이 바쁘다.
바쁜 와중에 가볍게 이런 무거운 주제들을 읽을 수 있게 해준 저자에게 감사한다.
그리고 두분의 역자역시 쉽게 번역할 수 없었던 걸로 보이는 문장들 역시 우리의 정서에 맞게
번역하느라 고생하셨을듯 싶다. 감사한다.
[인상깊은구절] "고객은 자신이 원하는 내용이 뭔지를 모릅니다, 고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마십시요" - p.255 "모든 쓸만한 추상화에는 어딘가에 구멍이 존재합니다" - p266 "방법론을 조심하라. 쓸만한 수준으로 그저 그런 성능을 내는데는 괜챦은 방법이 될 수 있지만, 동시에 유능한 인재를 쫓아 낼 수도 있습니다" - p.324 |
| 해외의 개발자 사이에서는 이미 많이 알려져 있는 컬럼(혹은 웹로그)인 Joel on Software는 외국의 개발자 메일링 리스트를 구독하다보면 가끔 인용당하는(?) 그의 글로 인해서 내게도 익숙했다. 우리나라에서는 안철수 연구소에서 몇몇 글들을 번역해주고 있기 때문에 이미 알고 있는 사람들은 조엘테스트니 일별 빌드니 하는 것이 어느정도 익숙할 것이다. 다만 안랩에서 모든 글을 번역한게 아니라서 영어가 부족한 나와 같은 사람에게는 아쉬운 점이 있었는데 그의 블로그와 같은 제목으로 미국에서 출간되었던 책이 번역되어 접하게 되니 반가운 마음을 금할 수가 없었다. 예약 구매로 도착한 다음날에 다 읽어버렸다. 굉장히 직설적인 방법으로 이야기를 하는 그의 글은 시원한 느낌과 함께 즐거움을 안겨주었다. 특히 얼마전에 읽었던 The Art of Unix Programming과 여러모로 비교되면서 이런 저런 생각을 해볼 수 있어서 즐거움은 배가 되었다. 직설적인 화법의 소유자답게 그는 레이몬드(TAOUP의 저자)의 의견에 동감하는 부분은 인정하면서도 그의 생각과 일치하지 않는 부분에는 단호하게 아니다라고 말한다. 예를 들어 레이몬드는 TAOUP에서 GUI(Graphic User Interface)와 CUI(Console User Interface)를 이야기 하면서 GUI는 확장성이나 효율성등의 면에서 유닉스의 전통적인 CUI프로그램(pipe를 이용하고 한가지 용도에 최적화된)에 못미친다고 이야기 한다. 그는 CUI프로그램에 GUI로 인터페이스를 구축하는 방식이 더 유연한 방식이라고 보는데, 이에 대해 조엘은 CUI방식을 고입하는 것이야 말로 Usebility를 해치는 것이라 말하고 있다. 내 스스로 Unix스타일의 개발을 좋아하는 구석이 있어서 조엘의 생각은 내 생각과 다른 부분도 있었지만 근거없이 GUI가 우월하다고 이야기하는 그런 방식의 전개가 아니고 조엘 나름데로의 경험과 생각을 기반으로 하고 있어서 일견 그의 생각에서도 많은 것을 배우고 타당점을 찾을 수 있었다. 분명히 다른 프로그램과의 인터페이스 측면이나 자동화 측면, 그리고 프로그램에 어느정도 익숙해질 숙련 사용자를 위한 면에서 CUI인터페이스 제공과(레이몬드 역시 무조건 적으로 GUI를 비판하는 것이 아니라 CUI를 기반으로 하는게 어떨까 하는 의견이다) 텍스트 기반의 통신이 좋을 것이다. 하지만 프로그램을 가볍게 사용하는 라이트유저나 프로그램의 사용성(단순하게 사용하기 편리한) 향상을 위해서는 잘 설계된 GUI역시 많은 도움이 될 수 있을 것이다. 결국 여기에서는 프로그램의 사용범위에 따른 선택이 중요하게 작용할 것이며, 우리가 평소 이야기 하듯 상황에 따른 선택이 중요할 것 같다. 개인적으로는 GUI프로그램들이 CUI인터페이스를 제공하는 것도 좋을 것 같다고 생각한다. 내가 직접 프로그램을 사용하면서 CUI인터페이스의 필요성을 느낀 경우가 많았는데, 특히 작업을 자동화해서 여러프로그램에게 협업을 시키게 한다는 부분이든지 프로그램을 테스트 할 경우에서 편리한 점이 많았다. 개발자들 사이에서 이견을 발견하는 것은 쉬운 일이지만 어느 정도 정점에 선 사람들이 그렇게 다른 의견을 이야기 하는 것은 언제나 많은 교훈을 준다. 각자의 의견은 대부분 일리가 있고 나름데로 타당한 이유를 가지고 있기 때문에 내가 몰랐던 부분들에 대해서 생각해 볼 수 있는 기회를 주고 내 생각을 정립할 수 있는 기회가 된다. 조엘의 책에서는 그와 다른 개발자 사이의 이견들을 발견할 수 있고 각각의 주장들을 접할 수 있다(조엘은 대부분 상대주장도 싣거나 출처를 제시하고 있다). 책을 읽으면서 그렇게 접한 다른 주장들도 시간을 내서 알아보거나 읽어본다면 많은 도움이 될 수 있을 것이다. 책에도 나오고 있지만, 조엘이 제시하여 상당히 유명해진 조엘 테스트 라는 것이 있다. 한 조직을 평가하는 기준으로 12가지의 테스트를 만들었는데, 전체 몇 개의 테스트를 통과했는지에 따라 조직을 평가한다. 각 테스트마다 1점으로 12점은 완벽한 조직, 11점은 괜찮지만 10점 이하는 문제가 있는 것으로 평가한다. 방법론이나 개발방법에 대한 테스트가 아니라 단순하게 조직의 질을 테스트하는데 목적을 두고 있는 것 같은데, 우리나라에서 12점 만점을 받는 조직은 몇개 안될 거란 생각이 든다(솔직히 하나라도 있을까?). 물론 우리나라의 문화적인 차이 때문에 조엘 테스트 중에 적합하지 않은 것도 있을 수 있지만, 조엘 테스트에서 좋은 점수를 받기 위해 노력하는 조직은 더 높은 수준의 질을 유지할 수 있을거라 생각한다. 조엘 테스트를 보면 새로운 기술에 민감하면서 조직의 질을 높이기 위해서 노력하는 조직들이 유리할 것 같다는 생각이 든다. 내 생각도 그렇게 기민한 조직이 앞으로 생존가능성이 높을 것 같다. 조엘이 블로그에 쓴 글들을 모아서 책으로 발간했기 때문인지 책 전체를 가르는 하나의 생각이나 주제 같은 것은 없다. 다만 조엘이 느끼고 생각한 짧은 글들을 하나씩 읽어가면서 내가 생각했던 것들과 비교도 해보고 조엘의 생각에 감탄도 하면서 즐겁게 읽을 수 있는 것이 이책의 묘미가 아닐까 생각한다. 더불어 컴퓨터 화면을 통해서 봤던 글이기는 하지만 종이로 된 책을 읽을 때의 감성적 느낌을 통해서 같은 글을 읽었을 때 느끼지 못했던 새로운 것들을 느낄 수 있는 것도 또 다른 묘미일 것이다. |
|
SW 개발자라면 누가나 한번쯤 들어봤을 조엘 온 소프트웨어. 프로그래밍 세계에서 요구정의서가 왜 필요한지 부터 관리자 입장에서 개발자를 어떻게 관리해야 하는지 등 전반적인 내용을 다루고 있다. 조엘이 직접 경험한 다양한 이야기와 팁들을 제시한다. 현직 SW 개발자로 많은 것을 생각하게 하는 도서이다. 다수의 프로젝트를 진행하면서 시간적인 제약이나 인적 자원에 대한 제약으로 생략하거는 간과하고 넘어갔던 프로세스들에 대한 당위성를 다시 한번 일깨워 주는 도서였다. |
| 당신이 IT분야에서 일하고 있거나 또는 일할 계획을 가지고 있는가? 당신이 IT분야와 협업을 하거나 사사건건 사내 개발부서와 이견이 생기는가? 그렇다면 당신은 바로 이책 "조엘 온 소프트웨어" 읽어 봐야 할 사람이다. 이 책은 저자가 겪은 소프트웨어 개발에 대한 다양한 경험을 편한하고 읽기 쉽게 정리한 책이다. 원 수록처가 저자의 블로그 임이니만큼 주제를 자유롭게 선택하여 읽기에 지루하지 않고 직설적인 말투와 표현으로 인해 독자들에게 더 쉽게 내용을 이해 시킬 수 있게 하였다. 아마 다른 독자들도 마찬가지 겠지만 이 책을 읽다 보면 IT관련 종사자 특히 개발자들은 평소 현업에서 겪게 되는 어려움에 대해 저자가 풀어 놓은 이야기에 고개를 끄덕이게 될 것이다. 그리고 아 이런 문제는 나만의 문제가 아니구나 하는 공감과 함께 저자가 제시하는 해결책들을 눈여겨 보게 될 것이다. 그러나 여기서 아마 대부분의 독자들은 다시 한번 자괴감을 느낄 수 밖에 없을 것이다. 저자가 제시하는 해결책들의 대부분은 우리나라의 IT현실상 이루러지지 어려울 수 밖에 없는 사안들이기 때문이다. 그리고 대부분의 회사에서의 의사 결정자들은 IT개발에 대한 경험이 전무한 사람이거나 겉핡기 식의 경험과 귀동냥의 정보로 인해 IT작업 환경을 왜곡하고 있다. 때문에 이 책은 사실 개발자들 보다는 IT관리자들이 꼭 한번 읽어 보아야 할 책이다. 그들의 생산성과 업무 효율성에 대한 고민의 해결책의 대부분이 이 책 안에 들어 있기 때문이다. 자 이 책을 다 읽은 개발자 분들은 슬쩍 이 책을 관리책임자의 책상에 올려 놓자. |
|
소프트웨어 개발자들의 가려운 곳을 시원하게 긁어주고, 여러 가지 도움이 되는 이야기들을 올려놓는 Joel on software블로그. 이 블로그의 주인인 조엘이라는 사람이 블로그에 올려놓은 글들 중 일부를 모아 책으로 냈다.
프로그래밍에 대해, 개발자들과 관리자에 대해, 회사 경영에 대해, .NET에 대해.. 등등 여러 가지 이야기들을 개발자가 아닌 내가 봐도 재미있게 써놓았다.(물론 프로그래머가 아니면 알아들을 수 없는 이야기들도 많다)
블로그에 가보고 재미있으면 책으로 읽어봐도 좋을듯하다. 유익한 내용들이 많다. 컴퓨터공학과 학생이라면 자신의 진로 선택에 있어서 안목을 넓히는데 많은 도움이 될 듯 하다.
[인상깊은구절] 조엘이 권장하는 '대학생이 갖춰야 할 지식' 목록 1. 졸업 전에 작문법을 배운다. 2. 졸업 전에 C를 배운다. 3. 졸업 전에 미시 경제학을 공부한다. 4. 따분하다고 비 전산 과목을 등한시하지 마라. 5. 프로그래밍 심화과정을 수강하라. 6. 모든 직업이 인도로 넘어간다는 걱정은 그만둬라. 7. 무엇을 하든 여름 인턴과정을 거쳐라. |