brunch

You can make anything
by writing

C.S.Lewis

by 김태호 Feb 10. 2024

기록하지 않으면, 단 한 줄의 코드도 쓸 수 없다

바닥났던 업무 생산성 심폐소생을 위해

24년 1월 29일의 기록


0122~0126 지난주 동안, 바닥났던 업무 생산성 심폐소생을 위해.


2가지 문제가 있었는데   

Did 데이터가 없다. (개인 Todo 회고와 같은 내용)

만들어낸 결과도 없다. ⇒ 이게 진짜 말도 안 되는 거임..


‘Did 기록조차 못하고, 올인했는데도 개발을 못했는데… Did 데이터를 남기면 안 되지 않을까?’

라고 생각하는 사람은 장담하건대 발전할 수 없다.


효율성이고 나발이고, 지금보다 비생산적인 것은 불가능하다.

아니. 이보다 비생산적인 업무일을 단 하루라도 더 보내는 순간,

    ‘난 이 조직에서 필요 없는 인간’이라고 생각하자. (그리고 이것이 꽤나 명백한 사실이다)


제1원칙: 기록하지 않으면, 단 한 줄의 코드도 쓸 수 없다.

비록, 2시간 동안의 삽질로도, 해결은 못했으나,

위와 같은 업무 과정의 특장점은

    빠르면 30초 길면 10분마다, 개발에서 한 걸음 떨어지는 시간이 발생한다는 것이다.


무슨 말이냐면,   

시도의 결과를 적어야 하니까, 그 짧은 찰나에 나는 몰입에서 벗어난다.

그다음 시도 역시, 적어야만 실행할 수 있기 때문에, 어떤 시도를 할지 짧게나마 사고하게 된다.

    >> 이전처럼 무지성으로 ‘하나만 파거나’ ‘했던 시도인데 까먹고 다시 한다거나’ ‘까먹지는 않았지만 효과가 어땠는지 기억 안 나서 다시 해본다거나’ 등의 이런 헛웃음이 나오는 짓들을 하지 않을 수 있다.


Did를 적는 그 찰나의 비용으로, 1시간에 10분마다 메타 인지를 할 수 있게 됨


Todo를 시간대별로 적는 이유는, 그걸 그 시간에 완벽히 해내기 위함이 아니다. 그 시간에 무엇을 해야 할지 "진지하게" 고민하는 것이 목적이다. 돌발 상황이 발생해 Todo가 어그러져도 된다. 괜찮다. 다시 자리에 앉아, "진지하게" 고민하라.
<딥워크>


제2원칙: 특정 버그 해결에 1시간이 지나면, 반드시 다른 일을 진행한다.

[Todo 적기 → 실행하기 → Did 적기] 루틴은 나의 가장 강력한 생산성 도구이다.


그러나. 특정 시점 이후부터는 이 사이클 그 자체에 매몰된다.

시도했던 Todo들이 머릿속에 차곡차곡 쌓여서,

    ‘진짜’ 문제를 해결할 수 있는, 해왔던 시도와는 결이 다른, Todo를 떠올리지 못하게 된다.


난 1시간으로 잡는다. 10분의 메타 인지 이후에도 해결이 안 되는 것은

그 순간의 내가 뭔 짓을 해도 해결할 수 없는 것이다.



여러분의 개발 생산성 체계에는 어떤 것이 있나요!

매거진의 이전글 Did List는 체크된 Todo-List가 아니다.
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari