좋은 개발자와 좋은 사람은 비슷한 말이다.
<Growth Developer : 주니어 개발자를 위한 성장지침서>
퇴사를 앞둔 저자에게 선물 받은 책이다. 문돌이인 나도 지하철에서 가볍게 볼만큼 읽기 쉬운 책이다. 주니어 개발자를 위한 조언이 담겨있지만, 나 같은 비개발자 입장에서 좋은 개발자는 어떤 사람일까 하는 힌트를 얻을 수 있는 책이기도 하다.
저자가 말하는 좋은 개발자는 이런 사람들인 것 같다.
- 문제의 원인을 외부가 아닌 나에서 찾으려는 사람. 그게 가장 빨리 찾는 법이니까.
- 어제보다 더 나아지기 위해 실천하는 사람
- 스스로 성장기회를 찾는 사람
- 트러블슈팅에서 문제를 재현하는 방법을 찾고 그것을 간단하게 할 수 있는 ‘체계’를 구축하는 사람
- ‘기술’이 아니라 ‘문제’에서 출발하는 사람
- 메모리를 효율적으로 할당하고 해제할 수 있는 사람
- 게으르지 않게 틈틈이 리팩토링하는 사람
- 개발과정에서 실수가 발생할만한 지점은 줄이고, 여러 과정을 자동화하는 사람
- 괜히 산만하게 만들지 말고 하나의 프로세스에서 출발
- 여러 사례를 학습해서 표준화할 수 있는 사람
- 개발을 모르는 사람과 대화가 가능한 개발자
- 나의 작업에 대해 제대로 된 일정을 산정하고 그 일정을 지키는 사람
- 고객과 사용자의 차이를 아는 사람
좋은 개발자는 결국 같이 일하기 좋은 사람인 것 같다. 나는 좋은 사람이 좋은 개발자, 좋은 리더, 좋은 직업인이 된다고 생각한다. 태도에서 시작하니까.
책에서 개인적으로 공감이 많이 간 부분은 좋은 팀에 대한 서술이었다.
“좋은 개발팀이란 그 존재의 목적에 부합하는 팀이다. 즉, 쓸 수 있는 소프트웨어를 만드는 팀이다. 진짜 쓸 수 있는 프로그램을 만들어 내지 못한다면, 주어진 문제를 해결해 내지 못한다면 그 팀은 어떠한 선진적인 문화와 우월한 조건을 갖추고 있다고 하더라도 좋은 개발팀이라고 할 수는 없을 것이다.”
“좋은 팀에게는 지켜야 하는 원칙이 있어야 한다. 나에게 얼마나 무한한 자유를 보장해 주는지 또는 얼마나 잘 대해주는 지를 기준으로 팀을 선정하지 말자. 오히려 절제된 통제 속에서 주어지는 자율적인 참여를 통해 나의 잠재력을 끌어내는 곳을 선택하는 곳이 좋다. 절제된 통제는 구성원 모두가 동의할 수 있는 적은 수의 몇 가지 원칙으로 나온다. 반면에 규칙이 많은 팀은 추천하고 싶지 않다.”
무언가 설명하는 것의 어려움을 개발자스럽게(?) 표현한 것도 재미있었다.
“뇌가 이해하고 있는 내용을 입이라는 기관을 출력하게 되면 데이터의 손실률이 엄청나다. 누군가에게 무엇을 설명을 할 수 있다는 것은 그것보다 10배를 더 알고 있다는 말이 있을 정도로 남에게 설명하는 것은 결코 쉬운 일이 아니다”
책을 읽고 나니 저자와 한 곳에서 이야기할 기회가 많지 않았고 남은 시간도 없다는 것에 더 아쉬움이 들었다. 플래너리 오코너 소설 제목 중에 <A Good Man Is Hard to Find>가 있다. 좋은 사람은 찾기 힘들다. 좋은 개발자도 찾기 힘들다. 그래서 아쉽다.
