1. 끊임없이 왜? 를 묻기
단순 코드 작성을 넘어, 내가 마주한 문제의 본질을 파헤칠 때 전문적인 한 개발자가 된다.
왜 이 일을 해야하는 모르는 채로 의사결정이 필요한 여러 복잡한 조건 속에서 잘못된 의사결정을 내리고
결국 잘못된 방향으로 업무를 이끌어가게 된다.
개발자는 자신이 작성하는 코드로 성과를 만들어내는 사람이다.
왜 이 기술을 사용해야하는 가? 과 같은 본질적인 부분을 들여다보기 시작하면
자신의 성장과 학습에 필요한 큰 방향을 잡아갈 수 있다.
장기적인 공부의 효율을 높이고 피상적인 이해만으로는 불가능한 빠른 성장을 이끄는 동력이 된다.
면접을 볼때도 마찬가지다.
면접관의 질문에 대해
본인의 기술적 선택을 이론에 근거해 설명할 수 있을 때, 좋은 평가를 받는다.
뛰어난 개발자들이 면접에서 이런 것들을 물어보는 이유는 현업에서도 일을 할 떄 꼭 필요한 능력이기 때문이다.
AOP로 구현할 수 있음에도 왜 Interceptor를 사용했는지?
똑같은 JVM언어인데도 왜 자바가 아니라 코틀린을 사용했는지?
개발자는 선택을 해야하는 상황이 아주 많습니다.
깊은 고민을 하지 않은 이들의 경우
사람들이 많이 쓰는 트렌드한 것을 썼다.
사용하기 쉬워서 썼다. 식의 답변을 많이 합니다.
개발자가 자기 선택에 대한 근거가 없다면,
최상위 개발자들이 보기에는 단순히 고민을 하지 않았다.
더 나아가 직업적인 전문성이 결여되었다는 평가를 내릴 수 있다.
멘토링을 진행할 때도 본인이 하고 있는 하나하나에 대해서 아주 세밀하게 왜?를 던져봐라.
- 애초에 내가 왜 이 책을 읽는 거지?
- 내가 왜 이 기술을 알아야하는거지?
- 내가 왜 이 작업을 해야하는 거지?
- 왜 멘토님은 나에게 이걸 알아오라고 한거지?
trade off를 고려
개발을 하면서 정답은 없다.
간단한 기능 하나를 구현함에도 여러가지 방법이 존재한다. 이 중에서 하나를 선택해야 한다.
하지만 앞서 언급한 대로
많은 개발자들이 다른 개발자들이 많이 사용하는 방법을 별다른 고민 없이 선택한다.
문제 해결 방법이 무엇이 있는지?
방법들의 장단점은 각각 무엇인지?
우리의 요구 사항은 어떤 것이 있는지?
우리의 요구사항을 봤을때 어떤 방법이 제일 잘 맞을지?
를 계속해서 비교하고 trade off를 고려해야한다.
이렇게 하려면 오랜 준비와 학습이 필요하다.
하지만 이런 고민을 통해 퀄리티 코드를 만들어 낼 수 있을 뿐만 아니라, 새롭게 학습한 내용은 반드시 이후에도 다시 쓰이게 된다.
이렇게 쌓인 내공은 좋은 개발자로 꾸준히 성장하는 든든한 기반이 된다.
어려운 것들을 하기
일반적으로 어려운 것을 피한다.
그 문제를 해결하는 과정이 고통스럽고, 시간도 오래 걸리기 때문이다.
사람들은 누구나 할 수 있는 쉬운 것을 선택한다.
당신이 개발자라면 이론을 공부하지 않고, 문법만 익혀서 당장 개발하는 것은 가능하다.
빠르게 결과물을 만들어 낼 수 있기 때문에 많은 분들이 이런 선택을 한다.
하지만 이런 경우,
성능, 유지보수를 고려한 개발이 되기 어렵다. 단기적인 코드 작성에만 급급하는 것은 개발자 시장에서 스스로를 도태시키는 위험한 방법이다.
채용시장은 철저히 수요와 공급을 따른다.
연봉을 많이 주는 회사는 자선사업가가 아니다.
그들은 그 연봉에 맞는 뛰어난 사람을 원한다. 뛰어난 개발자가 부족하기 때문에
최고 수준 실력자의 연봉은 더 높아지지만, 누구나 할 수 있는 구현 능력만 갖춘 개발자들은 이런한 연봉 상승 열풍에서 소외는 현상이 발생한다.
어떤 기술을 사용하더라도
그 기술을 왜 사용해야 하는지?
내부적으로 어떤 원리로 동작하는 건지?
이 기술을 잘 사용하려면 어떻게 해야하는지?
등을 계속 호기심을 가지고 파헤쳐야한다.
시간이 오래 걸려서 비효율적이라고 느껴질 수도 있다.
하지만 그 시간에 비례하는, 뛰어난 개발자로 성장하고 채용 시장에서도 성공하는 데 필요한 내공을 갖게 될 것이다.
스스로 성장하는 법을 습득
배울게 정해져 있는 방식의 학습은 정해진 것 외에는 얻을 수 있는 것이 없다.
성장에 한계가 있을 수 밖에 없다.
개발자로써 공부해야할 게 무궁무진하다.
정해진 분량만 마친다면, 미션을 완료했다는 심리적인 만족감을 얻을 수 있겠지만, 지식 수준은 딱 그 수준에서 멈춰버린다.
내가 무엇을 모르는지 파악
모르는 것에 대해 탐색
지식을 나의 것으로 만들기
멘티가 무엇을 모르는 지 멘토님이 계속해서 질문으로 짚어줄 것이다.
그러면 모르는 것을 계속 찾아보고, 찾아본 내용을 바탕으로 답변을 만들어 보아라.
자발적인 사람
멘토가 제시해주는 것만 하지마라.
스스로 학습해야한다.
먼저 도입하면 좋을 만한 것들을 찾고, 멘토에게 먼저 제안할 수 있다면
당신은 특별한 성장을 시작한 것이다.
자발적으로 할 수 있는 것
1. github의 readme, wiki에 문서화 하기
2. 문서를 더 근사하게, 읽기 좋게 이모지 달기
3. 코드에서 비효율적인 부분 -> 개선방안 찾기 -> 리팩토링
4. 상호 성장과 퀄리티 향상을 위한 코드리뷰 적극적으로 하기
내가 하고 있는 프로젝트를 어떻게 하면 다른 사람들에게 더 잘 보여줄 수 있을까?
어떻게 해야 지금 내가 짜는 이 코드의 가독성을 높일 수 있을까?
같은 본질적인 것들에 대해 계속 고민하다보면 도움이 된다.
꾸준히 기록
게속해서 질문을 받을 것일 텐데
질문에 대한 답변을 못할 것이다.
질문은 곧 == 딥다이브를 위한 키워드 이므로 꾸준히 키워드에 대해 기록해라.
적극적 커뮤니케이션
가이드 -> 행동 -> 피드백
이 사이클을 반복 할 수록, 더 많은 성장을 이뤄낼 수 있다.
어색해서, 불편해서, 내향형, 상대가 불편해서
커뮤니케이션에 소극적이 되는 경우가 많다.
하지만 회사에서 업무를 할 때에는 적극적인 커뮤니케이션이 꼭 필요하다.
억지로 말을 하는 것이 아니라, 업무 진행을 위해서는 서로의 생각을 공유하는 과정이 반드시 필요하다.
멘토님이 코드리뷰 등의 피드백을 해주지 않았으면 적극적으로 요청하시고, 내가 했던 작업을 꾸준히 공유하라.
더 빠른 커뮤니케이션을 위한 방법도 고민해봐라.
에컨대 슬랙으로 애기하는 것은 상대방이 보고 답변할 때까지 기다려야 한다.
하지만 시간을 정하고 구글밋으로 이야기 한다면 빠른 의사소통이 가능하다.
독서법
느려도 좋으니 꼼꼼하게 읽어달라
깊게 읽어두면 그 개념이 한 곳에서 쓰이는 것이 아니라, 여러 곳에서 쓰인다는 것을 발견하게 된다.
깊게 공부해두면 다른 기술을 공부할 때에도 그 개념을 다시 만날 일이 생긴다.
이러한 경험을 반복하면, 개발이 점점 재미있어진다.