[프로그래머의 뇌] - 11 / 12 / 13

CH. 11

업무 중단 책을 읽으면서 '업무 중단이 생각보다 더 큰 영향을 주는구나'하고 생각했다.
사실 업무 중단은 없을 수가 없다고 생각한다.
외부적인 요인이 많겠지만 물을 받으러 가거나, 화장실을 다녀오는 등 자리를 비우게 되는 경우도 적지 않게 일어나기 때문이다.

그래서 업무가 중단되는 시점을 컨트롤 할 수 없다면 최대한 커밋을 꼼꼼하게 남기거나, 어느 지점까지는 완료하고 중단하는 등 의도적인 쉼표를 찍으면 괜찮지 않을까 하고 생각했다.
나중에 할 일 혹은 지금 하다가 중단한 일을 잊지 않기 위해 책에서 제시한 방법처럼 주석을 남기기도 했었는데, 이는 나한테는 그다지 효과적이지 못했다.
일단 주석의 위치를 기억하지 못하거나, 주석을 보더라도 메세지가 그 당시 떠올린 메세지를 요약하면서 남겨 생각보다 '왜 이렇게 주석을 작성했는가'에 대한 것을 추적하기 어려웠다.
그렇다고 주석을 너무 상세하거나 길게 작성하자니 비효율적이라는 생각도 들고, 그 자체로 이미 업무 중단이 아닌가 싶다.
최근에는 연습장에 이후에 해야할 일들이 눈에 띄기 싶도록 작성을 하고 별표나 원을 그려넣는 등 화려하게 해서 기억하려고 한다.

멀티태스킹 나는 멀티태스킹을 못한다.
이전에는 내가 멀티태스킹에 능하다고 생각했는데, 언제부터였는지 하나에 집중하면 다른 하나는 집중하기 어려웠다.
어쩌면 이전에 능하다고 생각했던 것도 놓치는 것이 많았는데 그렇게 기억하는 것일수도 있지만 책에서는 그러한 점에 대해 여전히 멀티태스킹이 가능하다고 생각하냐? 고 접근한다.
그래서 코드를 작성하거나 책을 읽을 때, 음악을 안 듣거나 듣더라도 유튜브에서 재즈 같은 것을 많이 듣는다.
그것도 특정 가수의 어떤 재즈곡이 아닌 무작위 플레이리스트를 선택해서 듣는다. 가사가 있으면 나도 모르게 집중하게 되버린다.

CH. 12

• 일을 더 쉽게 할 수 있게 해준 것은 무엇인가?
• 일을 더 어렵게 만든 것은 무엇인가?

라이브러리 등을 새로 도입하면서 공부하는 경험에 비추어 얘기하면,
일을 더 쉽게 해준 것은 내가 필요로 하는 기능에 대한 예제였다.
그것이 누군가가 블로그에 정리한 것이든, 공식문서의 친절한 설명이든 예제는 실질적으로 도움이 되었고, 필요한 부분의 코드를 따라가다 보며 맞춰가는 것이 도움이 되었다.

반대로, 일을 더 어렵게 만든 것은 불친절한 설명이었다.
자세한 설명이 없고 공식문서에서 내용을 잘 다루지 않고 있으면 접근하는 데 어려움이 있었다.
직접 콘솔을 찍어보거나 이것저것 사용해보면서 확인해야 되기 때문에 일단 시간이 많이 소모되는 점이 일을 어렵게 만들었다

오류 경향성 일관성 없는 규칙, 모호한 이름...
내가 어려움을 겪는 것들이다.
변수명 규칙은 여전히 가장 힘든 작업 중의 하나이고,
자율성이 확보되는 널널한 규칙에서는 부자연스러운 이름이나 동작을 작성하거나,
너무 강한 규칙에서는 예외가 허용되지 않는다는 점이 압박이 되었다.
어쩔 수 없이 하나의 예외를 인정하기 시작하고 나중에 보면 많은 예외가 생겼을 때, 다시 이것들을 바로 잡으려면 정말 많은 시간이 들어가겠구나 싶다.

그리고 책을 읽으면서 인지적 차원 파트를 읽다가 인지 부하가 온 것 같다.
'오류 경향성', '일관성', '분산성', '숨겨진 의존성', '잠정성', '점도', '점진적 평가', '역할 표현력', '매핑 근접성', '힘든 정신 활동', '보조 표기법'... 이 파트를 읽는 것이 가장 힘든 정신 활동이었다.
어느새부터인가 내용을 받아들이는 것이 아닌 언제 끝나나의 독서가 되었다...

CH. 13

13장의 내용은 상급 개발자가 아닌 나로써는 어려움을 겪는 후배 개발자의 입장이 되어 책을 읽었지만,
좋게 말하면 적응하기에 너무 많은 정보의 양이 없었고, 나쁘게 말하면 아무것도 없었던 환경이었기에 내가 당면한 문제라기보다는,
나중을 생각하며 읽는 시간이 되었다.

• 새 팀원에게 너무 많은 정보를 주어 높은 인지 부하를 유발 (팀원들, 도메인, 워크플로, 코드베이스)
• 소개 직후 질문을 하거나 과제를 주는 것. (작은 버그를 고치거나 작은 기능을 추가하는 것)

이로 인해 관련 청크의 부족과 자동화 기술 부족으로 새 팀원은 인지 부하가 높아지며 적응에 어려움을 겪는다고 한다.
역시 적응 기간과 적응을 돕는 교육 등이 중요하구나 싶었다.
전문가는 이미 많은 시간과 학습을 통해 익숙해져있기에 초보자의 접근 방식과 많이 다를 수 있다.
좋은 선수는 좋은 감독이 못된다는 말처럼, 오히려 잘하는 사람은 어려움을 겪는 사람이 왜 어려워하는지 잘 이해하지 못할 수 있다.
그래서 외국어 강사 중에는 원어민보다 차근차근 공부해서 잘하게 된 사람이 초보자의 어려움을 이해한다는 식의 마케팅이 많다.

적응 지원 개선 상급 개발자가 된 내가 후배 개발자의 적응을 돕기 위한 방법의 첫 번째이자 가장 중요한 것은 교육을 받는 사람들의 인지 부담을 의도적으로 관리하는 것이라고 한다.
"파이썬에서는 청킹이 안 되는 것 같아요"의 대화는 도저히 동의할 수 없지만, 하나의 활동으로 작업을 제한하는 것은 괜찮다고 본다.
꼭 책에서 소개한 5가지 활동이 아니라, 어떤 작업이든 순차적으로 적응할 수 있도록 부여하는 것이 좋다고 생각한다.

또, 반드시 선배, 후배 개발자의 입장이 아닌 스스로의 인지 부하 관리나, 책에서 다룬 전반적인 작업의 인지 부하를 방지하기 위해서라도 프로젝트를 함에 있어서 보다 명확하게 코드와 관련된 규칙들을 정하고 내용들을 정리하는 작업이 필요하다고 생각한다.

드디어 프로그래머의 뇌 끝!