이번에는 나의 회고록 중 하나로 앞으로 개선해야 하는 사항을 작성하고자 한다. 그동안 나는 코딩과외를 받고, Github 프로젝트와 사이드 프로젝트, 재능기부 프로젝트와 사이트를 직접 파견을 통해 개발 숙련도를 올리기 위해 나는 꾸준히 그 덕분에 개발 숙련도는 작년보다 몇 배 이상 올릴 수 있었고, 상황에 맞는 개발을 어느 정도 할 수 있는 수준의 경지까지 달성할 수 있었다. 불과 몇 년 전까지만 해도 나는 자신감을 많이 상실하였고, 좋지 않은 곳에서 연이어 겪어 오다가 자살 충동까지 겪었던 경험을 보유하였었다. 그 당시 난 잘되고 싶은 마음 하나뿐이었고 제대로 된 업체에서 진심으로 잘 배우고 잘하고 싶었던 것이었고 잘 나가는 개발자가 되기를 간절히 바랐던 상황이었다. 시간이 흘려도 아직도 개선사항이 많..

이번 포스팅에서 입사 지원 할 때 개발 실력은 뛰어나 보이는데 불합격 주는 이유를 받아봤을 것이라 생각한다. 물론 본인이 얼마나 노력했고 이 중 성장을 위한 과정을 잘 담겨 있는 지표는 물론이고 개발 숙련도를 올리기 위해 어떻게 담았고 묻지 마 지원 대상이 아닌 서류가 전제조건이 된 상태에서 작성을 하고자 한다. 이 중에 불합격 사유를 보내는 거 보면 무통보로 불합격 내는 예의 바르지 못한 업체도 경험해 본 반면 이중에 그나마 불합격해도 다시 지원하고 싶은 업체도 있었다. 매크로 답변이 아닌 업체에서 직접 불합격 사유의 대한 답변을 받아본 적이 있다. 이 중 그나마 양심적으로 답변한 리스트 중에 아래와 같이 내가 느꼈던 점의 대해 남겨보도록 한다. 1. 업체 사정상 채용 인원이 제한되고 어쩔 수 없이 탈..

이번 포스팅에서는 업체가 왜 헤드헌터에게 채용 대행을 하는지의 대해 나의 관점과 지금까지 헤드헌터에게 연락온 데이터베이스를 토대로 작성하고자 한다. 나도 가끔씩 헤드헌터에게 채용 안내 연락을 받아본 적은 있지만 내키지 않는 경우가 대부분이기도 하였다. 그래서 헤드헌터에게 연락을 받으면서 아래와 같이 주제를 다뤄 보겠다. 업체가 헤드헌터에게 채용 대행을 두는 이유? 1. 업체에서 제대로 된 개발자를 뽑을 능력이 없는 경우 => 업체 내부에서 개발자를 뽑는 방법을 전혀 모르는 경우가 간혹 존재하기도 한다. 이 경우 개발자를 어떻게 뽑아야 할지 모르는 경우를 말하기도 한다. 대부분 개발자 뽑는 기준은 연차 하나로만 보고 기술 스택만 명시되어 있는 경우에만 의존 하고 뽑는 경우를 말한다. 혹은 CTO가 아예 없..

그 동안 나는 꾸준히 Github와 재능기부 프로젝트, 및 고객사 프로젝트를 통해 잘하지도 못하지도 않은 개발자가 되어 있었다. 사실 그 과정이 매우 험난했다. 좋지 않은 업체에 들어가서 안 좋은 경험도 겪었었고, 한 때 si 파견을 다니면서 개발 업무를 맡으며 퍼포먼스를 낼 수 없는 시절이 있었다. 나는 정말 힘들었고 큰 트라우마를 겪은 적도 있었고 지병 생기기 일보 직전까지 갔었다. 나는 그동안 트라우마를 겪었던 이후 이런 생각을 하면서 더더욱 독하게 달려온 적이 있었다. 남들보다 못하면 어쩌지? 다른 사람들에게 뒤처지기는 정말 싫고 오로지 개발 숙련도를 위해서만 장기간 하루도 쉬지 않고 매일 개발하는 것이 늘 일상이 되었다. 어쩌면 지금 까지 일 중독처럼 지내온 것같이 생각이 든다. 이렇게 개발 커..

소프트 스킬의 대한 어떤 것을 체크해야 하는지 회고록 형식으로 작성을 해 보았다. 개발자로써 살아가는 길은 지난 포스팅에서 계속 강조해왔던 소프트 스킬이 필요하고 나의 견해를 작성한 것에 이어 이번에는 어떤 체크리스트를 작성을 해야하는지 혹은 나만의 과제가 무엇인지 작성하도록 한다. 내가 생각하는 소프트 스킬 체크 리스트를 어떤 것이 있는지 조금 더 구체적으로 작성해보고자 한다. 1. 프로젝트 오픈일이 얼마 안남았을 때 고객이 몇가지 기능을 추가시켜야 하는데 추가 시키는데 시간이 오래 걸린다. 어떻게 대처할 것인가? 2. 본인은 프로젝트를 진행하면서 가장 기억에 남는 프로젝트? 혹은 어떤 과정을 걸쳤고 어려운 점이 무엇이며 어려운 점을 해결한 것은 무엇인가? 3. 개발이란 무엇인가? 당신은 개발을 시작한..

이번 포스팅에서는 개발자로서 갖춰야 하는 소프트 스킬 중 하나인 문서화 스킬의 대해 회고록을 통해 다뤄보고자 한다. 문서화 스킬은 개발자 간의 커뮤니케이션을 위한 도구 중 하나이며 말로 전달하는 것이 어려울 때 문서를 통해 전달하는 수단 중 하나이다. 또한 법적 근거를 남기기 위한 수단 중 하나이기도 하다. 대표적으로 요구사항 문서, RFP, WBS, 결함 문서, 업무일지 등 하나하나가 문서라고 표현할 수 있다. 따라서 나는 문서화 스킬을 기르기 위해 Github README.MD를 통해 다루고 외주 프로젝트 및 재능기부 프로젝트를 위해 요구사항 정리와 요구사항을 건네줄 문서화를 통해 진행을 하곤 하였다. 이때까지만 해도 문서화 스킬에 조금씩 자신감을 가지면서 할 수 있었다고 생각을 한 적이 있었다. 본..