대체 제목이 무슨 뜻인가... 표지는 또 왜 이런 그림인가 (물론 표지때문에 눈길을 주게 되었지만)... 하면서 읽었는데, 코딩 호러는 저자의 웹페이지 이름이고, 이 책은 그냥 그 블로그에서 몇몇 포스팅을 집대성한 책이다.
이 책을 읽을 때 새로운 시도를 한 가지 했는데, 마음에 든 구절마다 형광펜으로 칠하는 대신 해당 페이지의 귀퉁이를 접었다. 그래서 이 글을 쓰는 지금에 와선, 대체 그 페이지의 어느 구절이 마음에 들었는지를 찾아 내야만 한다. 그렇게 함으로써, 간접적으로나마, 두 번 읽은 효과를 만들 수 있지 않을까 생각했다.
한 번 결과를 확인해보자.
귀퉁이를 접은 페이지에서 찾아낸 문장들 (이 문장들이 모두 처음 그 페이지에서 생각했던 문장 그대로일까?), 일부 편집:
- 당신의 마음속에서 솟아나는 진실한 기쁨의 대상을 머뭇거리지 말고 좇으라.
- 우리는 꼭 그렇게 할 수밖에 없다면 당신을 속여서라도 당신이 글을 더 잘 쓸 수 있게 만들 것이다 (Gamification in Stackoverflow)
- 나는 당신이 우리가 그런 것처럼 저 광활하고 끝없는 바다를 열망하도 있다는 사실을 알고 있다.
- 래리 페이지가 말하길: "빠르고 좋은 결정은 있어도, 느리고 좋은 결정은 없다."
- (멀티 태스킹에 관하여) 하지만 시간, 질, 그리고 깊게 생각하는 능력의 눈금을 모두 조금씩 떨어뜨리지 않고는 그렇게 할 수 없다.
- 세상을 당신의 소프트웨어에게 굴복시키려면 그 소프트웨어에서 발생하는 어떤 문제에 대해서도 전적으로 책임져야 한다. 엄밀히 말하면 당신의 책임이 아닐지라도.
- 주석이 없으면 이해할 수 없는 코드라면, 그것이 엉터리로 작성되어 있을 가능성이 높다. 그런 경우라면 주석이 없어도 의미가 잘 전달될 수 있을 때까지 다시 코드를 작성하라. 그런 노력을 정말이지 끝까지 기울인 다음, 그래도 여전히 설명문이 필요하다면 주석을 달아라. 아주 신중하게.
- 내 컴퓨터 위에서 작동하는 것이라면, 내가 사용하는 다른 소프트웨어들을 포함하여, 그것들은 전부 내 소프트웨어다.
- 아이디어는 증폭기에 불과하다. 중요한 것은 실행이다.
- 그저 그런 그룹에게 좋은 아이디어를 제공하면 그들은 아이디어를 망쳐버릴 것이다. 하지만 훌륭한 그룹에게 그저 그런 아이디어를 제공하면 그들은 아이디어를 멋진 무엇으로 구현할 것이다. 혹은 그저 그런 아이디어를 밖으로 내던지고 뭔가 다른 것을 만들어 낸 것이다.
- 성공을 거두고 싶다면 위대한 아이디어를 떠올려야 한다는 강박관념에서 벗어나 위대한 팀을 경작하는 데 집중해야 한다.
- (만들어가는 제품에 대해) 뭔가 비전을 설명해 줄 수 있는 말을 찾아내는 것은, 없는 것보다 낫다.
- 성능(속도)은 기능이다.
- 우리는 인터뷰 과정에서 철학에 대해 논의한다.
- (인터뷰 전에 수행하는 오디션 프로젝트를 설명하며) 회사에서 실제로 존재하는 이슈를 맡겨보라. (...) 이러한 종류의 오디션을 위한 미니 프로젝트를 떠올릴 수 없다면 아마도 팀 내부의 직원들에게도 잘 정의된 일을 맡기고 있지 않을 확률이 높다.
- 의사소통의 부재는 그들이 딱딱하고 융통성 없는 사람인 것처럼 보이게 만들었다. 물론 사실이 아닐 것이다. 하지만 적절한 의사소통이 부재할 때는 그런 식의 이미지가 생겨난다.
- (아주 어려운 퍼즐(ps) 문제 인터뷰에 대해 말하며) 하지만 그러한 해결책을 나머지 팀원들에게 효과적으로 설명하는 기술도 중요하지 않을까? 대다수의 프로그래머들에게는 바로 그것이 가장 어려운 기술인 경우가 많다.
- 신뢰와 존경을 얻는 최선의 방법은 엄청난 노력과 실질적인 결과를 보여주는 것뿐이다. 모든 사람에게 좋은 개발 방법론을 이메일로 전송하거나, 어떤 기술을 이용하면 훌륭한 결과를 낳을 거라는 식의 조언을 보내는 식의 값싸고 피상적인 대체물은 동일한 결과를 낳지 못하며, 설령 그렇다고 해도 효과가 지속되지 못한다. (이 대목에서 나는 상당히 부끄러웠다)
- 다른 사람에게 직접적으로 혹은 도움이 되는 환경으로 만듦으로써 동기를 부여하고자 한다면 첫째로 당신이 그들을 진심으로 염려하고 있다는 사실을 확신시켜야 한다.
- (프로그래머를 뱀파이어에 비교한 뒤에) 이에 비해 시스템 관리자는 베어울프와 같다. 겉으로 보기에 그들은 평범하지만, 믿을 수 없을 정도로 힘이 세고, 보통 사람들을 쉽게 죽일 만한 일들 앞에서 멀쩡하다. 그리고 "사건"이 터지는 달밤에 몸에 기묘한 변화가 일어나는 일을 겪는다.
- 회의라는 것은 언제나 일단 생산성에 위험을 초래하는 부정적인 것으로 간주해야 한다.
- 어떠한 회의라도 한 시간을 넘기면 사형이다. 모든 회의에는 목표가 있어야 한다. 회의에 참석하기 전에 회의에서 필요한 일을 하라. 미리 준비한 사람이 아무도 없으면 회의는 당연히 취소해야 한다. 회의 참석 여부는 옵셔널이어야 한다. 회의를 마무리하면서 액션 아이템을 정해라.
- 팀의 리더십과 관련해서 팀원들이 가장 불편해한 사실은 자신의 리더가 이기적이거나 팀에 도움이 안되는 사람을 직접적이고 효과적인 방식으로 처리하려고 노력하지 않는 것이었다.
- 그룹이 최악의 경향을 가지고 있는 한 사람에게 그토록 결정적인 영향을 받을 수 있다는 사실은 우울한 일이지만, 그와 동시에 한 명의 능력 있는 리더가, 그러니까 당신의 팀이 그런 리더를 가질 정도로 운이 따른다면 사태에 개입해서 상황을 통제할 수 있다는 사실은 감동적이기까지 하다.
- 상처에서 피 대신 1과 0이라는 비트가 흘러내리는 사람이 아니라면 그런 사람과 원격근무를 통해 일할 생각은 하지 않는 것이 좋다.
- 사용자 입장에서 보면 UI 자체가 애플리케이션이다.
- 내가 앞에서 사용자는 당신이 화면에 나타내는 글을 아무것도 읽지 않는다고 말했을 때, 나는 사실 거짓말을 했다. 사용자는 사실 읽는다. 하지만 사용자는 자신의 업무를 수행하는데 필요한 최소한의 글을 읽을 뿐이다.
- 필요한 내용을 바로 그들의 코앞에 놓아야 할지 오랫동안 치열하게 고민해야 한다. 단순히 그들의 시야에 포함돼 있을 뿐만 아니라, 도저히 보지 않고는 넘어갈 수 없는 그런 장소 말이다. 그런 장소가 아니라면 그것은 그들의 눈에 아예 보이지 않을지도 모른다.
- 사용자가 보기에 그것이 버그이면, 그것이 사용자 교육, 사용자 문서, 사용자 인터페이스, 혹은 실제 기능이든 상관없이 그것은 버그입니다.
- 비록 버전1이 다소 엉망이라고 해도, 그것을 일단 출시하라.
- 고객에게 그들이 당신의 웹사이트나 소프트웨어를 이용하면서 겪은 문제가 무엇인지 묻는 것은 고사하고, 그저 그들을 마지막으로 만나기라도 했던 것은 언제인가?
- 코드 리뷰: 그냥 하라
- 소수의 사람(유저)으로 구성된 사용성 테스트조차 놀랄 정도의 효과를 낸다. 짧고 간단하게, 사람당 1시간 정도, 말 그대로 컴퓨터를 사용할 수 있는 아무나 데리고 와서, 미리 계획없이 아무때나.
- (자동적인 우회 로직 실행 대신) 실패를 즉각적으로 가시화하면, 소프트웨어를 더 깨지기 쉬운 존재로 만드는 것처럼 들리지만, 더 안정적으로 만드는 것이다.
- 커뮤니티 피드백의 90퍼센트는 쓰레기다. 하지만 나머지 10퍼센트는 대단히 훌륭하다.
- 사용자들의 요청이 말이 되지 않는다고 생각할 때나 사용자의 요청이 상식적인 수준에서 구현될 가능성이 없다고 생각될 때는 그에 대해 정중하게 거절하는 것을 두려워해서는 안 된다. 거절을 당하는 것은아프지만 무시를 당하는 것은 훨씬 더 아프기 때문이다. 당신이 자신의 커뮤니티에 대해 솔직한 모습을 보이면 그들이 결국 당신의 의견을 존중하게 될 것이라는 사실을 나는 확신한다.
- 사용자의 피드백을 무시하는 것은 궁긍적으로 당신을 실패로 몰아넣을지도 모른다. 하지만 모든 사용자의 요청에 맹목적으로 반응하는 것은 당신을 확실한 실패로 몰아넣는다.
- 배우는 것은 재미있다. 혹은 재미있어야 한다.
- 만약 하루에 한 번 꼴로 중재자에 의해 엿을 먹는 사람이 없다면 당신의 사이트는 제대로 중재되고 있는 것이 아니다.
- 당신이 선택할 수 있는 폭이 인위적으로 좁아진다면 이를 인식하고 다른 선택사항을 요구하라. (메타 인지가 필요하다)
- A/B 테스트를 이용해 겉보기에 최선의 결과를 얻어낼 수는 있다. 하지만 결코 다른 사람의 진심과 마음을 얻을 수는 없을 것이다.
- 이상한 일들을 정당화하기 위한 목적으로 전문성이라는 단어를 오용하는 것은 부끄러운 짓이다.
흠... 놀랍게도 대부분의 페이지에서 어떤 구절 때문에 귀퉁이를 접었는지 거의 정확하게 기억이 났다(고 믿는다). 형광펜을 썼을 때보다 범위를 조금 더 넓게 읽은 느낌이 있다. 계속 이 방법을 사용하는게 좋겠다.
기능이 아니라 버그예요