마틴 M. 브로드웰 <학습을 위한 가르침 Teaching for Learning>
-
무의식적 능력부족 unconscious incompetence
업무를 올바르게 수행할 역량도 안 되고 자신의 부족함을 인지하지도 못하는 상태 -
의식적 능력부족 conscious incompetence
업무를 제대로 수행하지는 못하지만 자신의 부족함은 인지하는 상태 -
의식적 능숙 conscious competence
노력을 통해 해당 업무를 수행할 역량이 갖춰진 상태 -
무의식적 능숙 unconscious competence
해당 업무를 수월하게 수행할 수 있는 역량이 갖춰진 상태
코드 동작을 이해하기 위해 다양한 실험을 해보자
이렇듯 디버거는 강력한 기능을 제공하지만, 가끔은 로그나 print 문을 적재적소에 넣어두는 것이 코드의 동작을 이해하는 가장 쉬운 방법이 되기도 한다. 아마 여러분도 이런 방법을 충분히 활용해봤을 것이다. 다만 멀티스레드 애플리케이션 같은 복잡한 상황에서 print 문을 이용한 디버깅은 잘못된 결과를 도출할 수도 있다는 점에 유의하자. 운영체제는 표준 출력으로의 쓰기를 버퍼링하므로 콘솔로의 출력이 지연될 수 있으며 여러 스레드가 표준 출력에 뭔가를 쓰면 그 메시지가 뒤섞일 수 있다.
문서 읽는 습관은 몸에 배야 한다
매주 일정시간을 할애해 자료를 읽는 습관을 들이자. 팀 문서, 설계 문서, 코드 티켓 백로그, 서적 기사, 기술 블로그 등이다. 다만 이 자료들을 한 번에 모두 읽을 생각은 하지 말기 바란다. 먼저 팀 문서와 설계 문서부터 시작하자.
론 제프리스는 "코드는 결코 거짓을 전하지 않는다. 하지만 주석은 간혹 거짓을 말할 때가 있다."고 말했다. 코드를 읽자. 설계 문서가 항상 현재 버전의 코드를 반영하지는 않기 때문이다. 회사의 코드베이스뿐만 아니라 고품질의 오픈소스 코드, 특히 여러분이 사용하는 라이브러리 코드를 읽자. 코드는 소설처럼 처음부터 끝까지 쭉 읽는 것이 아니다. IDE를 이용해 코드의 이곳저곳을 훑어보자. 주요 기능에 대해서는 코드의 흐름과 상태를 다이어그램으로 그려보자. 코드의 데이터 구조와 알고리즘을 파헤쳐보자. 예외 상황을 어떻게 처리하는지도 잘 살펴두자. 그러면서 팀의 코딩 스타일과 용어도 꼼꼼히 확인하자. 그래야 내부 의사소통이 원활해진다.
제대로 질문하자
모든 엔지니어는 질문을 해야 한다. 질문은 배움에 있어 매우 중요한 비중을 차지한다. 신입 엔지니어는 팀 동료에게 폐가 될까 싶어 모든 것을 혼자 알아내려고 한다. 이 방법은 느릴 뿐더러 비효율적이다. 질문을 효과적으로 한다면 오히려 다른 사람에게 아무런 폐를 끼치지도 않으며 빠르게 배우는 데 도움이 된다. 질문을 할 때는 먼저 스스로 찾아보고, 명확히 질문하며, 질문에 대한 답을 들을 때까지 적절히 시간을 기다리는 세 가지 단계를 밟아가야 한다.
스스로 문제를 해결해보고
제한 시간을 정하고
자신이 시도한 방법을 공유하며
동료를 방해하지 말고
비동기식 멀티캐스팅 의사소통을 시도하자
동기식 요청은 한 번에 보내자
입사 초반에 이런 실수를 많이 저질렀던 것 같다. 다들 너무 바빠보이고 하니까 질문하는 걸 못 해서 나 혼자 고민해봤자 절대 모르는 것들에 지나치게 많은 시간을 썼었는데 이 책에서 제안하는 것과 같이, 스스로 문제를 최대한 해결하려고 노력해보되 자신이 정한 일정한 제한시간이 지났다면 어떻게 시도하였는지를 정리하여서 질문을 해야 하는 것이 올바른 방법이라고 생각한다.
사실 누가 이런 방법을 가르쳐주지는 않았지만ㅋㅋㅋ 나는 성격 급하고 못하는 것에 대해 엄청 답답해 하는 편이라서 일을 좀 해보다보니까 이건 몇 시간 정도 고민할 일(아주 간단한 에러메세지인데 너무 아무데서나 날 수 있어서 모르겠는 것), 이건 하루 정도 고민할 일(운영보수에 관한 코드의 결점을 찾는 일), 이건 3일 고민할 일(페이지 신규 개발건 중 대충은 만들겠으나 여기저기 좋지 않은 코드가 있는 것을 알기는 앎) 이런 식으로 윤곽이 정해지더라. 이렇게 문제해결의 고민시간에 대한 스스로의 기준이 확실해지고 난 다음에는 질문하기가 훨씬 편해졌었다.
그리고 각 이슈의 업무에 대해서 나 혼자 일지같은 거를 계속 쓰면서 작업하니까 나중에 질문할 때도 내가 어떤 방법을 시도했는지 정리를 해서 한 번 머리속으로 사수분께 어떤 식으로 말해야하는지 돌려본 다음에 질문할 수 있었다. 그래도... 여전히... 바보같은 질문 개많이 하기는 했지만... 이걸 안 했다면 더 많이했겠죠^^! 그런 마음으로 산다^^!
성장의 장애물을 극복하자
가면증후군
가면증후군은 점점 더 강화되는 경향이 있다. 모든 오류는 자신의 능력 부족에 대한 증명으로 여기는 반면, 모든 성공은 남을 '기만'하는 증거로 바라본다. 누구든 이런 사이클에 한 번 빠지면 헤어나기가 어렵다. 이때 '자기 인식'은 도움이 된다. 여러분에게서 이런 패턴이 발견된다면 의도적으로 이 패턴을 깨뜨릴 수 있다. 여러분이 뭔가를 달성했다면 그건 실제로 여러분이 그 일을 잘 해냈기 때문이지, 그저 운이 좋았기 때문이 아니다.
칭찬과 성과를 애써 외면하지 말자. 아무리 작은 일이라도 기록해두자. 여러분의 동료도 모두 능력자들이므로 그들이 뭔가 긍정적인 얘길 해준다면 분명 그럴 만한 이유가 있었기 때문이다. 부정적인 생각은 재구성하는 연습을 하자. "경합 상태 문제를 해결하느라 다리아를 귀찮게 했네."가 아니라 "내가 다리아에게 도움을 청한 덕분에, 이제 경합 상태를 해결하는 방법을 완전히 알게됐다!"라고 생각하는 것이다.
여기서 제일 기억할 문구는 "내가 다리아에 도움을 청한 덕분에, 이제 경합 상태를 해결하는 방법을 완전히 알게됐다!" 라고 생각하는 부분이었다! 당장 오늘만 해도 npm 관련한 버전 이슈 때문에 지난주까지 잘 돌아가던 프로젝트가 돌아가지 않아 node와 npm을 삭제하면서 오전시간을 통으로 날려먹었는데 설정... 관련한 부분은 진짜 모르겠어서 동료의 도움을 많이 받는다고(쓸만한 블로그 다 찾아다 줌) 내 시간 뿐만 아니라 동료의 시간도 엄청 뺏어먹었다. 너무 미안해서 오후에 빵 사줬는데 여전히 항상 시간 뺏어서 미안하다고 생각했어서... 근데 퇴근 후에 남아서 공부하다가 이 부분을 읽게되니까 너무 큰 깨달음을 얻게되었다.
나는 나에 대해서 부정적으로 생각하는 것은 아주 쉽게 하는데 그래서 누가 나를 칭찬해도 에이, 그냥 해 주는 말이겠거니, 라고 생각하는 편이 많다. 그런데 이것은 나에 대해서도 무례한 일이지만 나를 칭찬한 상대방에 대해서도 그 진심을 깎아내리는 것이므로 무례한 일이라는 것을 알게 되었다. 내 동료들도 다 사리분별이 확실한 능력자들이고 그들이 나를 보면서 좋은 면이라고 생각하는 부분이 있다면 그것은 진짜일텐데도 인정하지 않는 것이지 않은가! 이 깨달음을 자주 기억하고 돌아봐야겠다고 생각했다. 오늘 이와 같은 문제를 동료와 같이 해결하였기에 동료도 나도 다음 번에는 어떻게 하면 node와 npm을 빠르게 삭제하고 재설치할 수 있는지, 참고할 블로그는 무엇인지에 대해 확실히 알게 되는 계기가 되었을 것이다.
