멘토님들이 슬랙에 이런 주제의 링크들을 자주 올려주시는데, 보통 볼 때만 좀 감명 깊게 보고 공부할 땐 그냥 하던 대로 돌아가게 되는 것 같다.
그래서 최근 읽은게 기억나는 내용들을 정리해보고 그걸 어떻게 적용할지를 생각해보는 시간을 가지려고 한다.
파인만 테크닉 https://youtu.be/sQYQgiHVyAM
다른사람에게 내가 배운 개념을 설명하지 못한다면 배운 게 아니다
- 1. 이해하고 싶은 개념을 선택해서 적기
- 2. 개념을 모르는 사람에게 가르친다고 생각하고 강의 내용을 만들어서 적기
- 3. 막히면 다시 읽고, 다시 배우기
- 4. 설명이 복잡한 부분을 쉽게 정리하기
+ 이해가 되지 않는 부분을 찾아서 생생한 이야기로 만들어서 단순화하기
+ 참고자료를 보지않고 설명할 수 있으면 더 좋음
어떤 개념을 남에게 설명할 수 있는 사람이라면 그건 그 사람이 해당 분야의 전문가 수준일 것이다.
이 테크닉은 이걸 반대로 생각해서 전문가 수준이 되기위해서 남에게 설명하는 연습을 하는 것.
과제를 하는동안 내가 이해했다고 생각하고 넘어가지 말고 평가자에게 설명하는 연습을 하면서 최대한 쉽게, 그리고 참고자료를 안 보고 설명할 수 있게 연습하면서 공부해야겠다.
파인만 알고리즘
1. 문제를 쓴다. Write down the problem.
2. 매우 깊게 생각한다. Think very hard.
3. 답을 쓴다. Write down the solution.
(2)에서 해결이 안된다면 잠을 자고 일어나서 깊게 생각한 다음 답을 쓴다.
1번 "이해하고 싶은 개념을 선택해서 적기" 까지 봤을때 이 알고리즘이 생각났다.
이 방법이 잘 먹히는(?) 이유는 세가지로 생각된다.
우선 문제를 글로 쓰는 작업은 그 자체로 문제의 해결에 도움이 된다. 어떤 문제가 잘 안 풀려서 다른 사람에게 조언을 구하기 위해 설명하던 도중 문제의 해결책이 불현듯 떠오르듯이, 이러한 생각의 환기가 문제를 해결하는데 도움이 된다.
두 번째로는 구체적인 to-do list를 작성할 수 있다는 점이다. 어떤 문제를 해결하기 위해 문제를 적었다면 그걸 자연스럽게 쪼개서 적을 수도 있다. 이렇게 단계별로 쪼개서 적으면 당장 처리할 수 있는 문제 먼저 처리할 수 있고, 일정을 계산하기도 쉬워진다.
세 번째로는 문제를 생각하다가 안 풀리면 잠을 자는 점에서 책 [몰입](링크는 저자 직강. 16분부터 선잠에 대한 설명)과 비슷하다. 어느 과제를 계속 생각하다가 졸려서 잠에 들었을 때, 잠에서 깨고 나면 뭔가 해결책이 생각나는(그 해결책이 맞는지는 검증을 해야 하지만) 경험이 종종 있는데 이것도 비슷한 이야기인 것 같다.
[라 피씬 후기] 에서도 비슷한 얘기를 했었다. 그땐 반대로 불면증이 심해서 문제였지만...
이건 이전에 본 글인데 이걸 본 이후로 과제를 노션에 적고 Microsoft To Do에 단계별로 쪼개서 정리해서 과제를 진행하고 있다. 이 방법은 과제를 뭐부터 시작해야 할지 막막할 때 좋다.
배우는 즉시 내 것으로 만드는 3가지 방법 https://youtu.be/Vl7K_kqvFiU
피드백은 두려우면서도 유용하다. 피드백이 두렵다면 더 많은 피드백을 받자.
- 피드백의 예시 : 어학 공부를 할때 방금 배운 단어를 바로 사용해보기, 프로그래밍을 할 때 배우자마자 만들어보기
자신이 못하는 부분을 집중적으로 공부하는게 중요하다.
1. 드릴 : 내가 약한, 어려운 부분을 집중적으로 연습하기.
2. 체이닝 : 학습 도중 막히면 이전으로 돌아가서 개념을 다시 익히고 반복 학습하기.
3. 미리 시험보기 : 시험을 먼저 보고 공부하기.
드릴은 이미 어느정도 알고 종종 실천하던 부분이었는데, 예전에 당구 열심히 칠 때 앞돌리기를 쳐야 하는 공이 나올 때마다 꼭 놓쳐서 하루 날 잡고 앞돌리기만 연습한 적이 있다. 지금도 포인터 헷갈려서 버그 나는 경우가 한 두세 달에 한 번씩 있어서 포인터 책을 빌려다가 보고 있다.
체이닝은 생각해본 적은 없지만 중요할 거라고 생각한다. 앞으로도 학습 도중에 막히면 개념을 좀 더 찾아보고 정리하는 습관을 길러야겠다.
미리 시험 보기는 이걸 본 이후에 실천 중인데, 과제를 시작할 때 평가표를 보고 정리한 다음에 과제를 시작한다. 이러면 어떤 점을 물어볼지를 더 깊게 생각하면서 코딩을 할 수 있고, 평가 연습을 할 때도 도움이 된다.
이 사람은 다른 영상에서도 피드백 루프를 아주 강조한다. 피드백을 바로바로 많이 받는 것이 학습에 도움이 된다고 주장한다. 어떻게 보면 42에서 평가를 받는 과정이 피드백이라고 볼 수 있을 텐데, 이 학습 과정을 만든 사람들도 피드백을 중요하게 생각한 것 같다.
프로그래밍 언어 배우기의 달인 http://egloos.zum.com/agile/v/5664879
튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다.
공부할 때 표준 라이브러리 소스코드를 읽는다.
공부중 다른 사람의 코드에 내가 필요한 기능을 추가한다.
프로그래밍을 빠르게 공부하기 위해서는 공부하기 전에 뭘 만들지 생각해보고 바로바로 만드는 게 중요하다고 이야기하고 있다. 뭘 만들지 미리 생각하고 바로바로 만들어보기도 하고, 다른 사람의 코드에 기능을 추가하기도 한다.
이게 프로그래밍에서 가장 쉽게 피드백을 받을 수 있는 방법이라고 생각한다. 프로그래밍은 누구라도 바로 시작해서 작은 프로그램을 만들 수 있고, 다른 사람의 프로그램에 기능을 추가하는 것도 쉬운데, 다른 분야에서는 이러한 학습이 어렵기 때문이다.
읽기를 강조하는 것도 특이하다고 생각했다. 해당 언어의 표준 라이브러리 코드가 해당 언어의 철학을 가장 깊게 담고 있다는 부분에서는 작게 놀랐다. libft 과제를 하면서 c libc 소스 코드를 정말 많이 봤는데, 이것도 학습 과정을 만든 사람들이 생각한 부분일까? 나중에 물어볼 기회가 있다면 물어보고 싶다.
결론
앞으로 과제를 할 때 주의사항들
아무 생각 없이 시작하지 말고 과제에서 서브젝트와 평가지를 읽으면서 요구사항들과 학습해야 할 내용들을 써서 정리한다.
과제를 단계별로 쪼개서 todo list에 적고 차근차근 진행한다.
테스터기를 사용해서 더 자주 피드백한다.
막히는 부분이 있다면 개념부터 다시 학습하고, 같은 부분에서 자주 막힌다면 해당 부분을 중점적으로 연습하는 시간을 가진다.
개념을 전부 정리한 다음 과제를 시작하지 말고 과제를 진행하면서 개념들을 정리한다.
평가 준비를 할 때 미리 설명하는 연습을 하면서 참고자료를 안 보고 유창하고 쉽게 설명할 수 있을 때까지 연습한다.