좋은 개발자

좋은 개발자란 무엇일까

 

아직 1년도 안된 주니어 개발자 입장에서 생각해 볼 떄 좋은 개발자는 누가 바라보느냐에 따라 크게 달라질 것 같다.

 

기획자, 디자이너, 동료 개발자 등 다양한 직군 만큼 좋은 개발자의 기준은 달라질 수 밖에 없다.

 

그 중에서도 동료 개발자가 바라보았을 떄 좋은 개발자에 대해 생각해보았다.

동료 개발자로서 좋은 개발자

문제 해결 능력

실무를 경험하면서 가장 중요하다고 느낀 것은 문제 해결 능력이었다. 같은 문제를 두고 어떻게 해결하느냐에 따라 하루가 걸리기도 하고 사흘이 걸리기도 했다.

내가 문제 해결 능력이 부족하면 결국 물어보는 곳은 사수이고, 이는 동료 개발자의 시간을 뺏는 결과를 초래했다.

 

질문 자체는 문제가 아니다.

그러나 문제 해결 능력을 배양하지 못한 채 발전 없이 시간이 흐른다면 결국 부족한 개인은 팀과 회사에 악영향을 끼칠 것이라 생각한다.
개발자도 결국 팀원이자 사원이고, 문제 해결 능력을 바탕으로 사내 여러 문제를 해결한다.

회사가 우리에게 보상을 제공하는 이유는, 우리가 직면하는 도전적이고 복잡한 문제를 해결하며 가치를 창출하기 때문이다. 경력이 쌓이면서 우리는 더 높은 수준의 과제에 직면하게 되며, 이는 개인적인 성장과 발전의 기회를 제공한다.

프로젝트 관리 능력

개발자의 일도 코딩이기 이전에 업무이고, 마감 기한 내에 우선 순위를 저울질할 줄 알아야 한다.

 

가장 먼저 마감 기한을 우선으로 두고, 코드의 질과 재사용성도 함께 잡도록 노력해야 한다. 미흡한 코드는 기술적 부채이나, 마감 기한을 초과할 경우 실질적인 부채다. 업무는 연관되어 있다. 타 부서의 다른 업무와의 연관성과 내 다음 업무까지 고려해야 한다. 물론 기한 내 기술적 부채를 최소화한 코드가 가장 좋은 코드다.

커뮤니케이션 능력

커뮤니케이션 능력이 중요한 이유는 결국 비용이기 때문이다.

 

적절치 못한 커뮤니케이션 능력은 두 가지 문제를 야기할 수 있다.

첫 번째는 지체되는 소통이다. 적절한 문서화와 핵심 요약으로 해결될 문제를 쓸데없는 말과 이해하기 어려운 장황한 설명으로 결국 당사자 간 이해라는 목표 달성이 늦어질 수 있다.
두 번째는 소통의 실패이다. 각기 다른 방향으로 이해하게 되면 문제가 커진다. 나중에서야 누락과 문제가 발견되고, 이는 결국 실무자의 고생으로 이어진다.

결론

나는 좋은 개발자일까? 라고 스스로 질문해보았을 때 맞다고 대답할 수 있도록 좋은 개발자가 되기 위해 방향성을 가지고 노력하는 개발자가 되어야겠다.