좋은 개발자가 알아야하는 9가지 포인트들 - 8. 결과를 내는데 집중하기

1. 기본기 확실히 하기

2. 학습 능력 키우기

3. 의사 소통 잘하기

4. 문제 정의 잘하기

5. 태스크 완료 시간 추정 잘하기

6. 운영을 고려한 코드 작성하기

7. 서비스 사고 대처 능력 키우기

8. 결과를 내는데 집중하기

9. 영향력 갖기 (코딩 멍키)

앞서 연차로 인한 압박에 관한 글을 쓰기도 했지만 아무래도 사교육과 선행학습이 일상인 환경에서 자라고 교육받다보니 다들 기술 지향적으로 뭘 배워두면 내 커리어가 안전해질까 등으로 항상 정답을 찾으려 많이 하려 하는 듯 하다. 다시 한번 학교 바깥의 세상에는 정해진 커리큘럼도 없고 시험처럼 정답이 정해진 형태의 테스트가 있지도 않다.

긴 커리어에서 더 건강한 관점은 내가 원하는 것이 무엇인지 고민하고 나에게 맞는 환경을 찾아 거기서 현재에 집중하며 맡은 업무 파악(의사 소통 -> 문제 정의)하고 그 업무를 성공으로 이끌어내는 경험을 하는 것이 중요하다. 피터 드러커의 "The Effective Executive"라는 책을 보면 모든 지식 노동자는 본인이 하고 있는 "공헌"이 무엇인지 고민해봐야 한다는 이야기를 한다. 여기서 포인트는 "맞는" 공헌을 하고 있는지 아니면 뭔가 잘못된 공헌을 하고 있는지 살펴봐야 한다는 점이다.

잘못된 공헌으로는 어떤 것들이 있을까?

1. 매니저로써 팀빌딩에 힘을 쓰기 보다는 개인으로 하는 코딩에 더 노력하는 것을 들 수 있다. 팀에 인력이 부족해서 라면 모르겠지만 대신할 사람이 있는데 그렇다면 큰 문제다.

2. 매니저로 모든 일에 직접 끼어들다보니 본인이 없으면 팀이 안 돌아간다면 결국 본인이 병목이 되면서 문제가 된다. 1, 2번에서 매니저라고 했지만 팀내 시니어 멤버라면 본인을 대입해서 생각해볼 필요가 있다. 프로세스로 돌아가게 하거나 나를 대신할 사람을 계속 찾는 노력을 계속해야 한다.

3. 불필요하게 새로운 프레임웍의 도입을 서두르는 것인데 일반적으로 이야기하자면 문제해결이나 가치창출에 집중하는 것이 아니라 너무 기술중심으로 가는 거다.

4. 주니어라면 처음에는 모르는 것들이 많을 수 있지만 동일한 질문이나 도움을 반복한다면 뭔가 잘못된 것이다. 팀에 공헌하는 사람이 되고 싶다면 발전하는 사람이 되어야 하며 때로는 모르거나 이해가 안되거를 대충 체면치레하며 넘어가지 말고 구체적으로 물어보고 이해해야 한다.

5. 다른 큰 범주는 문제정의를 잘 하고 맞는 방향으로 노력을 하는 것이 아니라 잘못된 "노력"을 강조하는 것이다.맞는 방향으로 노력했지만 결과가 안 좋았다면 그건 괜찮지만 열심히 했다는 이유만으로 모든 것이 인정되는 것은 아니다. 등산이라면 어느 산으로 올라가는지 먼저 파악해야지 아무 산이나 열심히 올라간 다음에 그걸 인정해달라는 건 말이 안 된다.

조직 사회에서 인정받고 자신감을 쌓는 제일 좋은 방법은 "결과"를 내는 사람이 되는 것이며 이는 내가 지금 할 수 있는 "맞는 공헌"이 무엇이 있는지 생각해보고 내 매니저나 동료들과 많이 이야기해보는 것이다. 개발자 관점에서 조심할 부분은 너무 기술적으로만 바라보는 것이다.