개발자 원칙

강현석·2023년 1월 14일
0

book-review

목록 보기
2/10
post-thumbnail

개발자 원칙

한줄평(★★★★★) - 개발자로써 내가 잘 하고 있는건지 궁금하다면?


개발 관련 신간을 구경하다가, 한번쯤 들어봤을 법한 회사에 종사하고 계시는 테크 리더 9분의 경험이 녹아있는 "개발자 원칙"이라는 책을 발견하게 되었다.
그리고 각 리더분들이 말하고자 하는 핵심 메시지들이 있고, 이것이 이 책의 목차이다.
나의 기준으로 핵심 메시지 중 가장 관심있는 메시지는 4가지가 있었다.

  • 덕업일치를 넘어서
  • 오류를 만날 때가 가장 성장하기 좋을 때다
  • 이직, 분명한 이유가 필요해
  • 제어할 수 없는 것에 의존하지 않기

덕업일치를 넘어서

덕업일치란, 쉽게 말하면 자신이 좋아하는 일을 직업으로 삼는 것을 의미한다.
나 또한 개발이 좋아서 개발자가 되었고, 10년차인 지금도 개발하는 것이 재미있다.
읽으면서 새로 알게된 점은 "하이프 사이클"이라는 개념이다.
신기술에 관심이 많기도하고 회사 프로젝트에도 적극 적용하고 있기에, 하이프 사이클 주제를 읽을 때에는 집중이 잘 되었다.

컴포즈로 예를 든다면, 어디까지나 나의 기준이지만 "부풀려진 기대의 정점" 위치에 있는 것 같다.
그래서 컴포즈 도입이 시기상조인가 싶지만, 도입할 기회가 흔치 않다는 생각이 더 컸다.
마지막으로 저자는 코로나로 인하여 개발자에게 호황기가 왔지만 호황기가 끝나게 되면 진짜 실력으로 만들어내는 성과에 따라 평가가 되는 때가 온다고 한다.
요즘 회사 분위기도 그렇고 재택을 없애는 회사들도 생겨나고 있고 인원 감축을 하는 뉴스를 종종 보니, 계속해서 실력을 키워야겠다는 생각을 하게 되었다.

오류를 만날 때가 가장 성장하기 좋을 때다

정말 공감하는 메시지이다.
나는 시행착오를 많이 겪어본 사람이 전문가라고 생각한다.
하지만 나는 연차에 비해 시행착오를 많이 겪어보지 않은 것 같아, 스스로 아쉬운 부분이기도 하다.
저자는 오류를 만나게 되면, 왜 그런지 자료를 찾아보고 소스 코드를 확인하고, 오픈 소스에 기여하고, 블로깅을 하는데, 특히 블로깅이나 오픈 소스 기여를 반드시 하라고 한다.
하지만 나는 오류를 만나게 되면 단순히 자료를 찾아보고 소스 코드를 확인하는 데에만 그치는 것 같다.
늦었지만 최근에 시행착오를 겪은 부분들에 대해서 블로깅을 하게 되었다.

이직, 분명한 이유가 필요해

첫 회사는 4년을 근무하였지만, 그 이후에는 2년의 공백과 의도하지 않았지만 1년 단위의 이직을 하였다.
그래서 10년차임에도 불구하고 지금 직장이 5번째 직장이고, 잦은 이직은 늘 최종 면접에서 발목을 잡는다.
저자는 3년은 채우고 이직을 해야 커리어 관리가 된다고 한다.
또한, 새로운 회사를 모색하기 전에는 항상 기존 조직에서 내 성장을 위한 변화를 시도할 수 있는지 찾고, 선배 혹은 상위 리더와 고민을 나누는 시간을 충분히 가지라고 한다.
그래도 내 성장을 위한 계획이 뚜렷하게 그려지지 않는다면, 그 때 새로운 회사와 환경을 찾을 결심을 하라고 한다.
스스로 되돌아보니, 기존 조직에서 찾기보다는 주로 나의 기준에서 판단을 해왔던 것 같다.
물론 선택은 스스로 하는 것이겠지만, 앞으로는 내 주변을 적극적으로 돌아봐야겠다.

제어할 수 없는 것에 의존하지 않기

일정을 지키고자 버그를 많은 소프트웨어를 출시하는 것이 마음에 들지 않습니다. 어떻게 하면 일정을 연기해서 안정된 소프트웨어를 내는 것이 더 중요하다고 리더들을 설득할 수 있을까요?

위 내용은 저자에게 자주 요청하는 질문이라고 한다.
2022년을 돌아보며 회고글에도 작성하였지만, 나 또한 최근까지도 고민하고 있는 내용이다.
이에 저자는 윈도우95 프로그래머 나카지마 사토시의 이야기를 전달한다고 한다.

프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을 기한 내에 완성하는 일이다.

이 내용을 읽고, 십 년 묵은 체증이 내리듯 마음 한 구석이 후련해졌다.
나는 내가 작성할 수 있는 가장 좋은 코드를 빠르게 작성해야 하며, 빠르게 작성하기 위해서는 반복만이 살 길이라고 생각해왔다.
그래서 개인 시간에 토이프로젝트를 통해서 반복을 해왔다.
하지만 그 시점에 가장 좋은 코드를 작성했어도, 몇개월 뒤에 내가 짠 코드를 보면 "왜 이렇게 못짰지"하는 생각을 한다.
긍정적으로 본다면 몇개월 전의 나보다 더 성장했다고 볼 수 있지만, 부정적으로 본다면 리팩터링 대상이 되는 코드를 만들고 있다는 점이다.
그렇기에 나카지마 사토시의 말은, 방향성을 바로잡아주는 느낌이 들었다.

그리고 저자는 빠듯한 일정으로 주어져도 80~90점짜리 프로그램을 출시하는 분들의 공통점을 찾은 결과는 아래와 같았다고 한다.

  • 경험과 학습으로 체득한 현재 상황에 적합한 기준과 원칙이 있다.

이렇게 하면 고민거리의 숫자가 줄고, 정말 중요한 곳에 시간을 더 투자할 수 있다고 한다.
이 내용을 읽고, 나의 기준과 원칙은 무엇인지 생각을 하게 되었다.

마지막으로, 저자의 핵심 메시지인 "제어할 수 없는 것에 의존하지 않기"를 코드뿐만 아니라 이직 및 조직과 매니징에도 적용하며, 외부의 요소, 이미 발생한 사건, 결정권이 없는 일 등은 제어할 수 없으니, 이들에 의존해서는 안된다고 한다.

나도 제어할 수 없는 것이 무엇인지 생각을 해보고, 제어할 수 없는 것에 의존하지 않는 연습을 해야겠다.

profile
볼링을 좋아하는 안드로이드 개발자

0개의 댓글