음하하하

  스택 오버플로우의 창립자 제프 앳우드가 쓴 [코딩 호러의 이펙티브 프로그래밍]이라는 책에 개발자를 8가지 유형으로 나눠 소개한 부분이 있다. 그 내용을 간략하게 옮겨본다.

1. 죽은 프로그래머

- 최고의 단계

- 나는 죽었지만, 내 코드는 계속 사용됨

- 다익스트라, 도널드 커누스, 앨런 케이

2. 성공적인 프로그래머

- 자신의 코드를 이용해 하나의 비즈니스를 새롭게 창조한 프로그래머

- 대부분의 프로그래머들이 꿈꾸는 단계

- 종종 프로그래밍 기술보다 비즈니스 기술에 의해 좌우됨

- 빌 게이츠, 존 카맥

3. 유명한 프로그래머

- 프로그래밍과 관련된 직업에 한해서 유명함

- 프로그래머가 일하고 있는 회사의 규모와는 상관없이, 다른 프로그래머들이 이름을 들어서 알고 있음

- 자신의 분야에서 긍정적인 영향을 미치는 존재

4. 일하는 프로그래머

- 소프트웨어 개발자로서 성공적인 경력을 보유

- 좋은 직장을 위해 오래 기다릴 필요가 없고, 주변에서 존경받음

- 근무한 회사의 실적이 향상

5. 평균적인 프로그래머

- 자신이 결코 위대한 프로그래머가 아니라는 사실을 알지만, 충분히 좋은 실력을 갖춤

- 비즈니스 능력과 사람을 다루는 기술이 뛰어난 사람이 더 큰 성공을 거두는 경우가 많음

- 프로그래머이면서 근근이 먹고 살아갈 정도라면 자신의 재능이 코딩에 있는 것이 아닐 가능성이 큼

- 자기가 잘하는 것이 무엇인지 깨닫고 그것을 추구하라. 아주 적극적으로.

6. 아마추어 프로그래머

- 코딩을 좋아하는 사람들 : 학생, 인턴, 오픈소스 커미터, 재미로 코딩하는 사람

- 미래의 가능성과 열정을 보여줌

- 빠르게 일하는 프로그래머의 단계로 성장하는 경우가 있음

7. 알려지지 않은 프로그래머

- 전형적인 프로그래머

- 유능하긴 하지만 별다른 특징이 없음

- 그저 직업일 뿐이며 개인적인 삶의 목표와 별로 상관이 없음

- 이 단계가 특별히 잘못된 것도 아님

8. 나쁜 프로그래머

- 프로그래밍 기술이나 능력이 없음

- 다른 동료 프로그래머들에게 고통과 통증을 안겨줌

- 비즈니스 코드를 작성하면 안되지만, 그런 코드를 작성하고 있음

  개발자들에겐 없어서는 안될 사이트인 스택오버플로우의 창립자인 제프 엣우드가 쓴 책이다. 번역은 임백준님께서 하셨다. 스택오버플로우 사이트를 개발하면서 겪은 경험과 개발자가 어떤 방향을 가지고 개발을 해야하는 지를 주로 다뤘다. 그리고 개발뿐만 아니라 UX나 기획, 그리고 개발자 커뮤니티와 커뮤니케이션 같은 부분까지 다루고 있다. 저자의 다방면에서의 내공을 살펴볼 수 있지만, 솔직히 웹 페이지의 UX같은 것은 평소에 생각해보지 않았기 때문에 잘 와 닿았지 않았고 좋은 점이나 나쁜점을 따로 생각해볼 수 없었다.

  책의 초반에 다룬 개발자의 8가지 유형을 흥미롭게 소개한 대목이 있다. 3번째로 높은 순위인 유명한 프로그래머가 되는게 현재 목표이지만, 쉽지 않을 것 같다. 현재 내가 생각하는 나의 단계는 5번 일반적인 프로그래머이다. 코딩을 좋아하긴 하는데, 나에게 재능이 있는 것 같진 않다. 더 잘하고 싶어서 노력을 많이 하고 있지만, 노력을 시작한 시점이 늦어서 그런지 조금 벅차다. 더 나아질 것이라는 기대 하나만으로 개발을 계속 하지만, 당장 직접적으로 나에게 다가오는 성과같은 것들이 없어 짙은 안개 속을 해쳐 나가는 기분이 든다.

  개발자들을 위한 자기개발서에서 꼭 나오는 얘기인, 블로그를 작성하라는 말을 구체적인 이유과 함께 언급하였다. 블로그에 글을 남기면서 자신의 생각을 논리적으로 정리하는 연습을 할 수 있기 때문에, 업무나 일상 생활에도 도움을 줄 수 있다는 장점을 어필한다. 올해 들어서 블로그를 꾸준하게 작성하고 있다. 블로그를 작성하고 있지만, 내 주변 사람들이 이 블로그를 보지 않고, 유명한 블로그도 아니기 때문에 기술적인 논쟁이나 코멘트 또는 피드백이 전혀 없어, 내 블로그에 대한 평가를 전혀 알 수 없다. 주변 사람들에게 억지로 읽게 할 수도 없고, 난감한 상황이다. 연예인에게 악플보다 무플이 좋지 않다는 말이 이 경우에도 통하는 것 같다.

  책을 읽으면서 메모로 기록한 단어 중에 썩은 사과라는 것이 있었는데, 정확히 어느 페이지에서 보았는지 기억이 나지 않아 다시 살펴보지 못했다. 아마도 겸손하지 않고, 자신이 제시하는 기술(기술의 출시 연도와 관걔 없이)이 항상 옳다고 주장하면서, 자신의 의견이 잘 받아들여지지 않을 경우, 프로젝트의 참여하는 태도가 좋지 않은 사람을 뜻하는 것 같다. 요즘 프로젝트를 진행하면서 비교적 신 기술인 JVM의 Scala나 Erlang 의 Beam 머신 위에서 동작하는 Elixir 와 같은 함수형 프로그래밍을 도입하자고 주장을 하고 있었다. 하지만, 기존의 프로젝트에서 막연하게 어떤 점이 좋다고 말하고 있지, 정작 문서나 수치 자료를 통한 근거를 이용하지는 않았다. 나의 주장에 힘을 내기 위해선 코드를 짜는 실력과 함께, 문서를 가지고 다른 사람을 설득하는 능력까지 갖춰야 할 것 같다.

  마지막으로, 책에서 가장 기억에 남는 문장을 적으면서 책에 대한 평을 마무리한다. 정확한 문장은 기억나지 않지만, 내용은 일맥상통한다.

  동료가 작성한 썩은 코드를 싫어해도, 그 동료를 싫어하진 말자!