Junior Developer?!
유튜브에서 우연히 본 주니어 개발자들이 저지르는 실수 3가지 를 참고하여 거울로 삼아보자.
뭔가 막히면 바로 물어본다?
개발 환경을 세팅한다거나 다른 사람의 코드를 보다가 막히는 부분이 있으면 바로 핑이 들어온다.
스택 오버플로우, 커뮤니티, 구글 등 검색을 조금만 해보면 거의 Usage가 나오기 마련이다. (물론 팀에 특화된 세팅이 있는 경우도 있긴 하지만.)
문제는 에러가 발견되자마자 바로 물어보는 점(검색하지 않고).
그 반대로 혼자 끙끙 앓기?
위와는 정 반대의 상황이다.
혼자서 해결하기 위해 끙끙 앓고 찾아보는 자세는 물론 좋은 태도이다.
하지만 해결되지 않는 문제를 잡고 거의 하루의 대부분을 날려버리는 것 역시 비효율적이고 비생산적인 방법이다.
1시간 정도 찾아보고 찾아본 내역과 질문에 대해 정리 및 고민을 해본 뒤 질문을 하도록 하자
딱 한 가지 방법으로만 문제를 해결하려고 한다.
처음 문제보다는 조금 더 복잡한 문제.
예를 들어 내가 모바일 앱을 만드는 과제를 하고 있다고 가정하자.
이 문제를 해결하기 위한 방법이 A, B, C, D가 있다.
위와 같은 상황에서 만약 내가 A 방법만 알고 있다면 주니어 개발자들은 대부분 A 방법으로만 쭉 진행을 한다.
그리고 나중에 만들어 놓고 보니 다른 방법들(B, C, D)이 훨씬 더 좋은 방법이었다?
무엇을 개발하던지 간에 여러가지 방안을 찾아놓고 그 방안 중 어떤게 가장 최적의 방안인지 검증하는 절차를 거쳐야 한다.
주니어 개발자들이 특히나 많이 놓치는 방법이고 실력 향상을 위해서도 여러가지 방안을 찾아보고 검증해보는 방향이 옳다.
개발을 하면서 계속적으로 훈련을 해야한다.
‘아 이런 문제가 있네? 그럼 방안이 몇개가 있지?’ 라고 스스로에게 물어보고 리서치를 계속 해봐야 한다.
만약 위와같은 훈련이 되지 않는다면 똑같은 문제에 대해 항상 똑같은 방법으로 접근하게 된다.
개발 기간을 짧게 잡는다.
다르게 말해서 개발 기간을 너무 짧게 잡는다.
이부분은 사실 시니어 개발자들도 어려워 하는 과정이다.
어떤 서비스를 만들기 위해서 주니어 개발자들은 기간을 상당히 짧게잡는다.
예를들어 페이스북을 개발한다고 할 때 주니어 개발자들은 ‘어? 한 달이면 될 것 같은데요?’ 하고 질러버린다.
분명 2주정도 지났을때 ‘이거 한 달로 안될 것 같은데..’ 이 때에도 자신이 아직 매니저에게 말을 안한다.
그리고 4주차가 다 되었을때 ‘어.. 1주일 정도 더 걸릴 것 같아요..’ 라고 말하게 된다.
그리고 위와 같은 1주 1주가 늘어나고 결국 ‘사실 두 달은 더 필요할 것 같아요..’ 라고 말한다.
위와 같은 상황은 시니어 개발자들에게도 어려운 태스크 중 하나이다.
절대 주니어 개발자가 본인의 실력을 과대평가한다거나 과제를 과소평가 하는 것이 아니라 단순히 경험이 부족해서 개발기간을 가늠하지 못하는 것.
즉, 개발 과정에서 발생하는 이슈 및 버그들을 전혀 생각하지 않는다는 점이다.
위와 같은 상황을 고려해서 개발 기간을 가늠하자.