세 번째 수업 이모저모

  • 수업은 2017-04-10 19:00:00 +0900에 시작.
    • 이번에는 이론 수업, 실습 순으로 진행되었다.
    • 실습 시간에 요구사항을 마저 구현하고, 리팩토링도 하는 것이 목표.
  • 편안하고 자유로운 분위기의 수업을 지향.
    • 예 : 다 한 사람은 집에 가도 된다.
    • 나는 숙제로 요구사항을 다 구현해 왔고 리팩토링도 했으므로, 교수님께 구현한 내용을 보여드리고 실습 생략하고 집에 갔음.
  • 이론 강의
    • HTTP 기본, OSI 7 계층, 콘텐츠 효율성 최적화, 보안 등.

단상 : 좋은 개발자란?

  • 박재성 교수님과 다른 사람들의 의견을 들어볼 수 있는 시간이었다.
  • 유명한 책들을 봐도 그렇고, 좋은 개발자의 유형은 거의 뚜렷한 것 같다.

나의 생각 : 좋은 개발자란?

좋은 개발자의 이데아

"행복한 가정은 모두 모습이 비슷하고, 불행한 가정은 모두 제각각의 불행을 안고 있다."

안나 카레니나의 첫 문장이다. (레프 톨스토이, 안진희 역. [안나 카레니나] 1권, 민음사 2009)

좋은 개발자에 대한 논의도 이와 비슷하다고 생각한다.
좋은 개발자들은 대개 비슷한 특성을 갖고 있을 것으로 예견된다.
그러나 보통 좋은 개발자와 거리가 좀 있는 개발자들은 다 나름의 독특한 이유들이 있다.
코딩을 못한다거나, 성격이 나쁘다거나, 공부를 안한다거나, …

너무 뛰어난 개발자의 딜레마

회사에서 일하는 개발자의 조건에 한정하여 고용주 관점에서 생각해보면 어떨까. 좋은 개발자는 1인분 이상의 일을 하는 개발자일까? 회사의 모든 것을 알고 모든 업무에 지원이 가능한 static public 개발자는 어떨까?

제럴드 와인버그는 프로그래밍 심리학에서 다음과 같이 썼다.
(제럴드 와인버그, 조상민 역. [프로그래밍 심리학] 6장. 프로그래밍 프로젝트, 인사이트 2008)

절대 없어서는 안 될 프로그래머가 있다면, 한시라도 빨리 그를 프로젝트에서 제거하라.

의미는 뚜렷하다. 대체 불가능한 프로그래머는 고용주와 관리자에게 리스크가 된다. 뛰어난 개발자이면서 동시에 핵심 인력인 사람은 회사의 대들보가 되기 마련이지만 어느날 갑자기 그가 예상치 못한 중병에 걸려 쓰러진다면? 교통사고를 당한다면? 회사는 위기에 처하게 된다.

따라서 고용주 입장만 고려했을 때

  • 리스크 최소화를 위해 개발자는 모듈화 되어야 한다.
  • 개별적으로 뛰어나지만 대체 가능한 인력들로 팀을 구성해야 한다.

소프트웨어 개발과 통하는 점이 있다는 생각이 든다. 소프트웨어만 리팩토링이 필요한 것이 아니다. 회사의 많은 인력들이 한 사람에게 의존하고 있다면, 좋지 못한 소프트웨어에서 나는 나쁜 냄새가 조직에서도 발생한다고 말할 수 있을 것 같다.

그 외 생각들 메모

  • 개발자는 훌륭한 프로그래밍 원칙을 삶에서도 실천하는 사람이 되어야 할까?
    • YES. 나는 일관성을 중요하게 생각한다.
  • 한 사람의 개발자의 POWER가 과거보다 줄어든 것은 사실이다.
    • 그렇다면 현재 시점에서는 좋은 개발자보다 좋은 팀에 대한 논의가 좀 더 의미있지 않을까?

Links