똑똑하고 100배 일 잘하는 개발자 모시기Smart and gets things done 
조엘 스폴스키지음/이석중옮김|위키북스|2007.09.18|248p|ISBN 9788995856482

[조엘 온 소프트웨어 http://blog.jrcho.com/82 ]를 읽었다. 오늘은 그의 또 다른 책을 읽었다. 작고 페이지도 적어 금방 읽었다. 예전 그의 의견(글)은 처음엔 대단하다 생각했었다. 지금도 다시봐도 좋은 글이라 인정은 해주겠으나, 이젠 소화를 해서 그런지......
그렇다고 그의 스마트함을 깎아 내릴 의도는 없다.

그는 (내가) 가보지 않은 길을 갔던 것이다. 흔히 개발자가 마음먹고 하고자 하는 그런 회사를 그는 경영하고 있는 것이다. 거기에 부러움이 없다면 그건 거짓일테지! 하지만, 10년을 겪고 나니 그것은 일부분인게야.

그는 포인터와 재귀용법을 반복 용어로 사용하고 있다. 구식인 거다. 그의 말대로 중요성을 무시하는게 아니라 반복이 지겹다는 뜻. 내가 생각하는 포인터나 재귀용법은 안다의 차원이 아니라 사용하다보면 익숙해지는 것 이상은 아니다. 물론, c코딩을 해야 하겠지만.

이번엔 똑똑한 개발자가 어떻게 하면 되는가에 대한 궁금증에 저번에도 반 읽었지만, 다시 잡게 된 것이다. 한데 그는 자기 회사 자랑을 하더라. 물론 스티브 맥코넬이 말한 고수와 초보의 만배가 차이난다는 생산성 이야기는 흥미롭기도 하다.

아니 자랑이라기보다 자신이 생각하는 개발자에 대한 처우를 정리하고 있다고 봐도 되겠다. 그의 글이 꼭 객관성/주관성 이렇게 나눌 필요는 없다. 개발자 1인 1실을 지켜주고 싶어하는 마음과 새로운 언어를 배우는 프로그래머를 보면 열정있는 사람이라고 하는 것.

노동절 머리 식힐 책이었다.
Posted by iarchitect

조엘 온 소프트웨어 - 유쾌한 오프라인 블로그 (2005/04/25)
조엘 스폴스키 지음/박재호, 이해영 옮김| 에이콘 | 2005년 04월 07일

역자가 마음에 든다. 그는 스티븐 맥코넬의 [프로젝트 쾌속 개발 전략(Rapid Development)]도 번역했는데, 괜찮다.

4장의 유니코드와 문자집합이란 장은 재미나고 깔끔했다. mySQL과 웹애플리케이션과 서비스를 구축하는 나에게도 실체로 와닿고 있다. 예전엔 생각지 못했는데 말이다. gmail.com에서 한글이 깨지는 것과 mysql의 세팅에 따라 한글이 보였음하고 삽질하는 나를 볼때 말이다.
-> 이젠 gmail.com 에서 한글이 깨지지 않는다
..
그게 싫다면 집에가서 아기나 봐야 될지 모르겠습니다란 ... 1장의 글에서 전문성에 대한 화두를 또 한번 발견한다. 회사경험 5년차 난 정말로 전문성이 있는가? 요새 읽고 십여 권의 책 독후감을 써야 되는데 ...이론 바쁘다는 핑계보다 그 책들이 링크되어져있는게 문제다
...

8장 손쉬운 기능명세 작성법 을 읽는데 http://www.construx.com/survivalguide/desspec.htm  이란 url을 찾을 수 있었다. 내가 좋아하는 스티븐 맥코널이다. 이 사람도 은연중에 자기가 옳다는 주장을 하고 있음을 잊지 말고 읽자 신토피컬 독서!!

지금 읽고 있는 부분에서의 이슈는 상황론인 것 같다. 그때 그때 맞는 적절한 도구를 이용하라는 말인지도 모르겠지만, 여하튼 xp를 그리 좋은 방법론으로 보지 않고 있다. 음... http://xper.org 에선 어떻게 말하고 있을까?

유닉스 철학과 원도 철학에 관한 이야길 하는데 갈수록 이사람의 일방성에 반감이 생기는 부분도 있다. 필체는 대부분 내가 MS를 다닐때 이랬고, 자기 product에 관한 이야기가 거슬리기 시작하누만.

그리고 한국여건으로는 그 사람이 적었던 100mb 자료 올리고 내리는 거 정도는 일반화 되어 있음을 모르는 부분도 분명 있다.

[기억에 남는 구절]
* Binary Lagre OBject(BLOB) -p6
* 문자열의 첫 바이트에 바이트개수를 저장하는 방법으로 이를 해결했습니다. 바로 이런 문자열을 파스칼 문자열이라고 합니다. -p10
* 비록 정도는 약하지만, 전형적인 malloc구현을 따를 경우에도 가비지 컬렉션과 유사한 성능 저하 문제가 생기니까요.-p14
* 버그는 발견 즉시 수정해야 합니다. -p28
* 새로운 기능을 소개했다면, 축적된 대규모 버그를 수정하는 작업 없이 해당 기능을 구현해서 즉시 출시할 수 있습니다. p29
=> 이 앞에 내용이 경쟁사에 발 빠르게 대응할 수 있다는 장점....의 이야길 나왔다.
* '명세 없이는 코드도 없다'는 단순한 규칙을 일관되게 주장해야 합니다.-p31
* IBM PC는 OEM 문자집합을 고안했을때, 이 문자집합은 유럽 언어를 위한 몇몇 강조 문자와 수평, 수직, 귀퉁이를 비롯한 각종 선 그리기 문자를 제공했기 때문에, 화면에 그럴싸한 상자를 그리는 데 이런 문자를 사용할 수 있었습니다. -생략- 온갖 OEM 문자 집합 형식이 꿈틀거리며 기억 나오기 시작했으며, 각자 용도에 맞춰 128글자를 정의했습니다.-p45
* 반면에 아시아에서는 사람을 환장하게 만드는 여러 가지 요소를 고려해야만 합니다. 즉 아시아 문자집합이 결코 8비트에 들어갈 수 없는 수천가지 글자로 이뤄져 있다는 사실입니다. 이런 문제점은 일반적으로 DBCS(Double Bytes Character Set)로 부르는 두 바이트 문자 집합 시스템으로 해결합니다. -p46
* U+0645 윈도우 2000/XP에서 charmap 유틸리티를 사용하거나 유니코드 웹사이트를 방문해서 각 글자마다 할당된 유니코드 코드 포인트를 확인할 수 있습니다. -p49
* http://www.unicode.org
Posted by iarchitect