미움받지 않을 코딩
'사랑받는 개발자' 정말로 그런 개발자가 있을까? 주제를 정한 필자도 조금은 낯선 문장이다. 프로그래머들 사이에서는 능력 좋은 개발자를 좀 더 우대해 준다. 하지만 이번 주제는 개발자들 사이가 아닌 회사 내에서 사랑받는 그런 개발자이다. 기획자도, QA, PM에게도 사랑받는 그런 개발자이다. 사실 싸우지만 않아도 다행이지만 그래도 좀 더 나아가서 사랑받는 개발자가 되려면 어떻게 해야 할까 함께 고민하는 시간이 되었으면 한다.
인스타그램에서 발견한 '기획자가 본 개발자의 4가지 유형'이란 네 컷 만화 중 일부다. 현업에서도 실제로 저런 케이스들이 자주 등장한다. 나 또한 저 케이스 중에 한 사람일 것이다. 해당 만화를 반면교사 삼아 사랑받는 개발자가 되려면 어떻게 해야 할지 함께 생각해 보도록 하자
개발자와 기획자의 오해가 발생한 경우이다. 기획서를 꼼꼼히 살펴보지 않을 경우 일어나는 불상사이다.
혹은 사전 리뷰 때 이야기했던 내용들이 제대로 전달되지 않아서 생기기도 한다. 개발자 입장에서도 생각지도 못한 새로운 개발건을 발견하면 당황스러울 수밖에 없다. 이럴 경우에는 먼저 확인이 필요하다. 만약 개발건이 맞다면 다시 한번 확인 후에 일정에 넣어 개발을 진행한다. 하지만 협의되지 않는 추가건이라면 개발 PM에게 문의하고 결정을 기다리는 방법을 택하자
기획의도와 다르게 추측하여 개발하는 경우다. 보통 신입개발자들이 위축된 상태에서 많이 하는 실수다. 아무리 기획서가 꼼꼼히 잘되어 있다고 하여도 사람이 만든 것이기에 실수나 부족한 부분이 있을 수 있다. 그러므로 조금이라도 내용이 이해가 안 되거나 의아하다면 무조건 물어봐야 한다. 신입 때는 질문 없는 개발자보다 질문이 많은 귀찮은 개발자가 되는 게 더 현명하다.
비즈니스 모델이나 개발 이유에 대해서 의심을 품는 개발자 유형이다. 이런 유형에 개발자는 그래도 꽤 괜찮은 유형이다. 하지만 기획이나 개발건에 대한 부분에 의심을 과도하게 품는다면 실례가 될 수 있다. 예를 들면 기획자가 개발자에 코드에 과도하게 관심을 넘어 의심을 품는 거와 마찬가지다. 그러므로 어느 정도의 관심을 주되 의심으로 관계를 불편하게 만들지 말자
필자가 개인적으로 안 좋아하는 유형이다. 기계적으로 일하는 개발자이다. 그저 하라는 거에 대해 기계적으로 대응하고 애정 없이 코딩하는 부류이다. 예를 들면 기획이 잘못된 걸 발견했지만 기계처럼 잘못된 부분 그대로 만들고 책임을 전가하는 형이다. 보통 회사에 애정이 없는 개발자들이 이런 경우가 있다. 프로라면 어떤 경우라도 최선을 다하는 개발자가 되자
사실 사랑받는 개발자는 없다. 정말 그럴까? 회사에서 코딩을 하고 있다면 주변을 둘러보자 사랑받는 개발자가 있는가? 대부분은 없을 것이다. 처음부터 말한 것처럼 사랑받는 프로그래머는 유능한 프로그래머이다. 어쩌면 사랑받는 개발자가 된다는 건 유토피아에 가깝다. 하지만 나쁜 개발자가 될 필요는 없다. 실망을 주는 개발자 또한 될 필요는 없는 것이다. 조금 더 주변을 살피고 이해하며 솔선수범 하고 무엇보다 감동을 주는 코딩실력을 갖추고 문제를 누구보다 빠르고 정확하게 해결한다면 그것이 바로 사랑받는 개발자가 아닐까 생각한다.
"나도 사랑받는 개발자가 되고 싶다."