코딩 호러의 이펙티브 프로그래밍 - 제프 앳우드

한 번 얘기를 한 적이 있지만 이 분 마인드가 참 마음에 든다. 

"마음 속에서 솟아나는 진실한 기쁨의 대상을 머뭇거리지 말고 좆으라." - 제프 앳우드

 

이름: Jeff Atwood

직업: 소프트웨어 개발자, 작가, 블로거, 사업가

현재 Coding Horror라는 프로그래밍 블로그를 운영하고 있고,

정말 정말,, 정말 코딩을 해봤다는 사람은 안본 사람은 있어도 한번 보고 다시 안 들어간 적이 없다는 Q&A 웹 사이트 StackOverflow와 Stack Exchange Network의 공동 창업자

(죄송.. 실물과 차이가 있는 그림이지만 다시 그릴 수는 없다..)

내가 원하는 일을 정말 깊숙히 무의식과 의식의 경계 사이에서 느끼고 있다고 하더라도 사실 그걸 끄집어 내어 보고 건드려 보지 않는 한

내가 정말 뭘 원하는 건지 알 수가 없다. 이것저것 해봐야 한다는 말은 진짜 아무거나 해보라는 얘기가 아니라 그 걸쳐져 있는 애매한 무언가를 계속 건드려 봐야 한다는 말인 것 같다.

책 내용은 2012년도 출간 했지만 정말 재미있는 얘기가 많이 있었다.

개발자를 움직이게 하려면 "intrinsic motivation"을 주어야 한다고, 광활하고 끝없는 바다를 열망하게 만들라! 는 얘기도 있었고,

제품이 살아남으려면 완벽을 추구하거나 더 낫게 행동하는 것이 아니라 더 빠르게 움직여야 한다는 것!

여기에 대해 구글 안드로이드 예를 들어서 정말 이해가 잘 되었는데, 안드로이드는 지금까지 버전이 많이 업그레이드 되어 왔는데

2012년도쯤? 프로요 2.2가 맞나? 그때 휴학을 하면서 안드로이드를 만져보고 있었는데 내 능력의 부족함을 사실 더 많이 느꼈지만 

개발 환경 구성하는 것도 만만찮았고, 생각보다 어렵다.. 그리고 너무 느리지 않나? 생각을 했었던 것 같다. 

그런데 어느 순간 업그레이드를 거듭하더니 최근 들어서는 그 속도가 더 빨라지고 있는 것 같다.

"완전 총알같이. 만약 뭔가 길을 가로막으면 방향을 바꾼다"

이 말이 그에게는 많은 영감을 준 것 같다.

또 구글의 래리페이지도 "빠르고 좋은 결정은 있지만, 느리고 좋은 결정은 없다"고 얘기를 했다고 한다.

또 많이 공감이 되었던 얘기는 '멀티 태스킹'에 관한 얘기였는데

우리는 우리가 할 수 있는 일을 과대평가 하는 경향이 있다고 말한다. 어느 연구 결과였는지 표로 나온 멀티 태스킹 효과가 굉장히 인상깊었는데 우리가 한번에 2가지 일을 하면 2배의 시간이 더 들고 3개가 되는 순간 6배가 되더니 그 이후론 기하급수적으로 해결 시간이 늘어난다.

그래서 그는 할 수만 있다면 멀티 태스킹을 피하고 작업에 "낮은 우선순위"란 태그를 쓰는 것을 추천했다.

겸손한 프로그래머가 되는 길은 어떠한 상황에서도 결국 모든 잘못의 뿌리는 내게 있음을 인정하는 것이다. 라는 얘기를 하는데 이 부분에서는 최근들어 많은 생각을 하게 만드는 말이다. 정말 우습게도 내 능력이 부족하면 부족할수록 도구와 연장을 탓하고 있는 내 모습을 보게 된다. 

최근 회사에서 꽤 오래 근무하시다 이제 막 스타트 업을 시작하고 계시는 분과 얘기를 하던 중 실제로는 문서를 작성하기 보단 코드에 주석을 달아 문서를 대신한다는 얘기를 들은 적이 있는데 이 책에서도 코드의 주석에 관한 얘기를 하고 있다.

그는 어느 상황에서든 간결함을 추구하라고 말한다. 왜냐면 코드를 보면 이해할 수 있는 당연한 얘기들을 주석에서 구구절절히 얘기를 하는 것은 가독성을 떨어트리고 의미가 없다는 얘기다. 대신 "당신은 코드를 마치 주석이라는 것이 세상에 존재하지 않기라도 한 것처럼 절실하게 작성해야 한다."라고 한다.

프로젝트 성공여부를 판단할 수 있는 세 가지 질문은 무엇일까?

당신의 팀이 얼마나 많은 줄의 코드를 작성할 것인가?

어떤 종류의 소프트웨어를 만들 것인가?

동료 프로그래머들을 좋아하는가? (정말 중요하다..!!!)

이 외에도 회의는 길지 않는 것이 좋고 최대한 미리 준비해서 최대한 간결하게! 

혼자서 코드를 짜다간 방황과 방향 상실 분석 능력이 마비된다며 동료의 필요성을! 

디테일은 경험과 실패에서 나오는 것이니 빠른 실패가 필요한 대신 피드백은 점점 더 빨라져야 한다.

최종 사용자에게는 UI가 곧 애플리케이션이다.

요즘 왠만하면 모든 암호가 쉽게 뚫리니 절대. 절대. 사용자 암호를 그대로 DB에 둬서도 안 되고, 왠만하면 인터넷 운전면허 (보안으로 신뢰할 수 있는 제 3의 site에서 관리하는 계정을 이용해 로그인하게 만드는 개념)를 사용할 것! (페이스북, 트위터...)

등등 .. 

사실 책이 여러 가지 주제를 담고 있는 데다 모두 재밌는 내용이어서 그 중 가장 기억에 남는 것들만 나열을 해 보았다.

오랜 시간 이 길이 내가 생각하는 길이 맞을까? 내가 가는 길이 맞을까? 생각을 하면서

한 가지 내가 마음을 다 잡은 건, 한 분야에만 종속되려고 하지 말고 내가 원하는 방향에 맞추어 접목시키자는 것이었다.

아니 정말로 그렇다.

앳우드도 얘기를 하지만 단순히 프로그래밍만을 좋아하는 사람은 정말 드물다. 대부분의 프로그래머들은 자신이 이루고자 하는 목표를 가지고 그 목표를 현실로 만들기 위해 노력하는 사람들이라고 생각한다. 

이 많은 얘기들을 한 권에 녹여낸 것도 대단해 보였지만 이 많은 얘기를 가지고 있다는 게 그 동안 얼마나 많은 경험을 거쳐 왔는지를 보여주는 것이기에 정말로 멋지다는 생각을 하게 만들었다. 

거기다 생각하는 것도 멋있네.