- 소프트웨어 개발에서 코딩은 컴퓨터에 할 일을 지시하는 마지막 단계에 가깝고, 먼저 필요한 일은 무엇을 어떻게 만들지 정하는 것임
- 코드 편집기를 열면 바로 구현에 몰입하는 기능 모드로 들어가기 쉬워, 창의적 사고를 위해 컴퓨터에서 떨어진 시간이 필요함
- 노트에 글을 쓰고 스케치하면 막연한 아이디어가 글과 그림으로 구체화되고, 이해의 빈틈을 건너뛰기 어려워짐
- 새 문제의 초기 해법, UI 스케치, 플로차트, 기존 코드베이스의 데이터 흐름과 상호작용을 노트에서 정리하며 구현 방향을 잡음
- 코드를 설명하듯 글로 정리하면 설계 불일치, 나쁜 구조, 실수를 찾기 쉬워지고 나중에 돌아볼 사고 과정 기록도 남음
컴퓨터 밖에서 더 잘 되는 개발 사고
- 소프트웨어 개발에서 코드 작성은 필요하지만, 먼저 결정해야 할 핵심은 어떤 코드를 쓸지와 어떻게 접근할지임
- 코드 편집기가 열려 있으면 바로 동작하는 무언가를 작성하는 상태가 되고, 그 상태에서는 창의적 사고가 잘 흐르지 않음
- 문제를 풀 때는 컴퓨터에서 벗어나 산책하거나, 노트를 들고 소파·야외 파티오에 앉아 생각함
- 산책 장소로 San Francisco Bay, Spree, Aurajoki 같은 물가 주변이 언급됨
- 노트에서는 새 문제의 초기 해법을 구상하고 접근 방식을 설계하며, UI 스케치나 플로차트를 그림
- 기존 코드베이스를 다룰 때도 데이터 흐름과 상호작용을 노트에 정리하고, 이를 바탕으로 버그 수정이나 새 기능 추가 방법을 찾음
글쓰기와 스케치가 남기는 효과
- 글쓰기와 스케치는 막연하고 추상적인 생각을 단어와 그림으로 바꾸는 사고 도구임
- 머릿속으로만 생각할 때는 건너뛸 수 있는 지식이나 이해의 빈틈도, 글로 쓰면 쉽게 피하기 어려움
- 코드를 작성한 뒤에는 다른 사람에게 설명하듯 글로 정리하는 방식을 선호함
- 가능하면 블로그 글로 공개함
- 공개할 수 없을 때도 같은 방식으로 쓰면 코드의 불일치, 나쁜 설계, 실수를 찾는 데 도움이 됨
- 관련 글로 how writing is my favourite refactoring tool을 남김
- 글로 생각하면 사고 과정 자체가 기록으로 남아 별도 메모를 새로 만들 필요가 줄어듦
- 나중에 쓰기 좋게 재정리하고 다듬는 정도만 하면 됨
- 2주, 6개월, 2년 뒤에 특정 결정을 왜 했는지 물어보면 노트를 다시 보고 당시 생각을 확인할 수 있음
- 그 질문을 하는 사람이 미래의 자기 자신인 경우도 많음
- 업무 노트의 내용에 더 초점을 둔 별도 글 how I take work notes as a developer도 있음