코딩 시간을 늘리고, 만들어진 코드를 최대한 노출시켜 피드백을 받는다?

 

홀맨님과 오후 시간에 진행한 타운 홀 미팅에서 WakaTime에 기록된 모두의 코딩 시간을 공유하며 이야기를 나누는 시간이 있었다. 자리에서 확인한 내 주간 평균 코딩 시간은 현업 개발자 아샬님이 업무와는 별도로 개인적으로 진행하시는 코딩 시간보다는 많았지만, 수련을 하는 입장에서 이 정도는 해야 충분히 한 것이라고 하기에는 다소 부족한 수치였다.

 

미팅에서 코딩 시간에 대해 들은 이야기를 내가 이해한 바는, 우리처럼 수련을 하는 입장에서는 실력의 상승이 코딩에 투입하는 시간과 비례하기 때문에 에디터에 코드를 입력하는 절대적인 코딩 시간을 늘려야 한다는 것이었다.

 

절대적인 코드를 쳐야 한다는 부분에 동의하지만, 지금처럼 매 주 목표를 잡고 구체적인 결과를 내야 하는 프로젝트에서는 코딩에 투입하는 시간만큼 코딩을 하기 위한 설계를 하는 데에도 시간을 들여야 하지 않나 하는 부분이 고민이 있다. 무작정 코드를 치기 시작했다가 작업 진척도가 미궁에 빠져 프로젝트를 뒤엎거나 리팩터링에 며칠씩 시간을 들여야 했던 두 번의 경험이 있었기 때문이다.

 

아마 사실 내 입장에서는 설계를 한다고 한 게 올바른 설계가 아니었을 가능성이 크다. 그렇다면 관점을 설계에 투입하는 시간에 초점을 맞추기보다는 내 상태를 공유하고, '이렇게 하면 안 된다'는 피드백을 하나 둘 쌓아가면서 어떻게 더 나은 설계를 해야 하는지 하나 둘 잡아가는 식으로 보완하고, 그렇게 받을 수 있는 피드백의 양을 늘리기 위해 최대한 많은 코드를 치고 최대한 많이 상황을 공유하는 데 초점을 맞춰야 하는 것일까?

 

이것만큼은 확실하다고 할 수 있는 지점들은, 그 두 번의 대규모 리팩터링은 내 상태가 어떤지 보여줄 수 있는 결과물이 있었기 때문에 리팩터링을 받을 수 있었던 것이고, 리팩터링 결과는 실제로 이후 작업에 좋은 방향으로 영향을 끼치고 있다는 점이다.

 

 

그렇다면 다음의 루프를 따를 수 있을 것 같다.

 

 

'코드를 최대한 치면서 결과를 만들어내고 (소위 똥을 만들어내고) -> 만들어낸 결과를 최대한 자주, 많이 공유시켜 피드백을 받고 -> (고통스럽지만) 받은 피드백을 바탕으로 작업 설계 방식을 조금씩 더 낫게 개선한다. -> 그리고 다시 코드를 최대한 치면서 결과를 만들어낸다'

 

관건은 '최대한 자주, 많이 공유'한다는 부분인 것 같다. 그리고 지금까지의 나에게 가장 어려웠던 부분이 바로 이 '공유'였던 것 같다. 생각이 너무 많아 질문하기 위해 텍스트를 구상하고 치는 데 한 세월이었다. 그 과정에서 생기는 비용과 스트레스 때문에 질문을 해야 할까 싶다가도 주저하고 이내 속으로 끓이고 말았던 적이 많았다. 내 상태를 공유하는 게 뭐 그리 어렵다고... 어짜피 다 드러나게 될 것들이였는데...

 

민낯을 계속해서 드러내는 데 부끄러워하지 않았으면 한다. 부끄러움을 덜어낼 수 있다면, 최대한 많은 민낯을 만들어 노출시킬 수 있도록 코드를 치고 또 치고 또 치자. 다음 번에 치는 코드가 피드백을 받고 더 나아질 것이라는 확신을 가질 수 있게 된다면, 그게 나에게는 쉬지 않고 코드를 쳐도 지치지 않고 코딩을 이어갈 수 있는 원동력이 되어줄 수 있을까?