#acl +All:read

PairProgramming을 통해서 배우고 있는 것이 매우 많다.

PairProgramming을 통해서, 상대방이 어떤 사고의 과정을 거쳐서 프로그래밍을 하는지 엿볼 수 있다. 보통 전문가나 시니어와 같은 팀에서 일을 한다고 해도, 그들의 결과물만을 보고 감탄하거나 동경하는데서 그친다. 또는 그 결과물에 담긴 품질을 내 결과물에도 구현하기 위해 목표로 삼고 노력한다.

하지만 전문가는 초심자와 멘탈 모델이 다르다. 초심자가 보지 못하는 단서(cue)들을 볼 수 있고, 다른 전략(strategy)을 사용한다. 때문에, 초심자가 아무리 노력한다고 해도, 결과물만을 들여다 봐서는, 전문가가 어떻게 그 결과물을 만들어냈는지 그 사고 과정, 그 멘탈 모델을 들여다볼 수 없다.

그런데 PairProgramming을 할 때는, 전문가의 사고 과정이 드러나게 된다. 만들어가는 과정을 실시간으로 함께 하기 때문에. 그 과정에서, 전문가가 어떻게 생각하는지, 어떤 것을 알아채는지, 어떤 접근을 하는지를 파악할 수 있어서, 훨씬 효과적으로 학습할 수 있다.

꼭 전문가가 아니더라도, 짝이 서로 다른 접근법, 다른 노하우, 다른 강점을 가지고 있을 수 있기 때문에, 서로 배울 점이 있을 것 같다.

전문가 입장에서는, 짝과 같이 프로그래밍을 하면서 자신의 접근법에 대해 좀 더 명확한 이해를 할 수 있게 된다. 마치, 빠른 기차를 타고 갈 때는 미처 인식하지 못하던 풍경이, 천천히 자전거를 타고 갈 때는 보이는 것처럼, 자동적이고 무의식적으로 행하던 접근, 알아채던 단서들을 찬찬히 하나씩 조망하게 되면서, 의식의 차원으로 끌어올릴 수 있다.

페어를 하면서, 나는 당연하다고 여겼던 것들이 짝에게는 당연하지 않다는 것에 새삼스럽게 놀란다. 나는 별 감흥이 없었던 것들이, 짝이 '우와, 이렇게 접근할 수도 있군요!'라고 발견해주면, 그게 당연한 것이 아니라 계발된 전문성의 요소라는 것을 깨닫는다.

그저 '내가 이런걸 하고 있구나'라는걸 알아봤자 뭐가 좋을까? 뭔가 내가 하면 일이 잘 되는데, 왜 잘 되는지를 모르는 상태보다, 내가 어떻게 하길래 잘 되는지를 알아차리게 되면, 그것을 더 발전시킬 수 있다.

----

실시간 리모트 PairProgramming 도구를 만들어볼까? VSCode나, IntelliJ Emacs 확장을 통한?

Floobits의 클라이언트 부분은 오픈소스로 공개되어 있다.

GitHub에서 만든, Atom 확장 Teletype은 p2p 모드로 [[https://teletype.atom.io/#getting-started|동작]]한다고 한다.

 * [[https://github.com/atom/teletype|teletype]]
 * [[https://github.com/atom/teletype-crdt|teletype-crdt]]
 * [[https://github.com/atom/teletype-server|teletype-server]]
 * [[https://github.com/atom/teletype-client|teletype-client]]

teletype-crdt에서 참조한 논문

 * [[https://dl.acm.org/doi/10.1145/1180875.1180916|Data consistency for P2P collaborative editing]]
 * [[https://dl.acm.org/doi/10.1145/2660398.2660401|Supporting String-Wise Operations and Selective Undo for Peer-to-Peer Group Editing]]
 * [[https://dl.acm.org/doi/10.1145/2957276.2957300|High Responsiveness for Group Editing CRDTs]]


=== 짝 프로그래밍을 통해 자라기 ===

회사 기술블로그에 게재할 글.


우리 회사에서는, 짝 프로그래밍을 활발하게 한다.

<통화 요청하는 스샷>

코드 리뷰도 한다. 그러나, PR을 통해 비동기로 이루어지는건 별로... Tim Ottinger가 공유한 글.

<코드 리뷰 스샷>

코드 리뷰와 짝 프로그래밍은 약간 다르다. 짝 프로그래밍을 한다고 하면서, 코드 리뷰를 하게 되는 경우도 많다.

하지만, 짝 프로그래밍은, 조금 더, 같이 '만들어'간다는 점이 다르다. 누가 이미 '만들어' 놓은 것을 리뷰하는게 아니라.

아, 물론, 누가 만들어놓은 것을 짝 프로그래밍하는 경우도 있다. 조금 더 구조나 로직을 개선하기 위해서. 또는, 버그가 발생했을 때 같이 볼 수도 있다.

짝 프로그래밍을 통해서 배우고 있는 것이 매우 많다.

우선, 짝 프로그래밍을 하면, 상대가 어떤 사고의 과정을 거쳐서 프로그래밍을 하는지 엿볼 수 있다.

<창준님 페북 글 스샷 - 이보람씨? 온스테이지?>

팀에 전문가나 시니어가 있어서 함께 일을 한다고 해도, 보통은 그들의 결과물만을 보고 감탄하거나 동경하는데서 그치곤 한다. 또는, 그 결과물에 담긴 품질을 목표로, 나는 어떻게 저렇게 할 수 있을까 노력하기도 한다.

하지만, 전문가는 많은 경우 초심자와 멘탈 모델이 다르다. 전문가는 초심자가 보지 못하는 단서(cue)들을 볼 수 있고, 다른 전략(strategy)을 사용한다. 때문에, 초심자가 자신의 멘탈 모델 안에서 노력하더라도, 전문가의 결과물만을 들여다봐서는, 전문가가 그 결과물을 만들어내기 위해 사용한 사고 과정, 멘탈 모델을 파악하기 어렵다.

그런데, 짝 프로그래밍을 할 때는 전문가의 사고 과정을 엿보기가 훨씬 쉽다. 만들어가는 과정을 실시간으로 함께 하기 때문이다. 그 과정에서, 전문가가 어떻게 생각하는지, 어떤 것을 알아채는지, 어떤 접근을 하는지를 파악할 수 있어서, 훨씬 효과적으로 학습할 수 있다.

팀에 전문가나 시니어가 없더라도, 또는 짝을 꼭 주니어-시니어로 맺지 않더라도, 짝끼리 서로 다른 접근법, 다른 노하우, 다른 강점을 가지고 있을 수 있기 때문에, 서로 배울 점이 있더라.

그러면, 전문가나 시니어 입장에서는 좋은게 없을까? 시니어는 그냥 봉사활동만 하는 것일까?

전문가 입장에서는, 짝과 같이 프로그래밍을 하면서 자신의 접근법에 대해 좀 더 명확한 이해를 할 수 있게 된다. 마치, 빠른 기차를 타고 갈 때는 미처 인식하지 못하던 풍경이, 천천이 자전거를 타고 갈 때는 보이는 것처럼, 자동적이고 무의식적으로 행하던 접근, 알아채던 단서들을 찬찬히 하나씩 조망하게 되면서, 의식의 차원으로 끌어올릴 수 있다.

그렇게 의식의 차원으로 끌어올려진 노하우, 기술, 전문성, 멘탈모델은, 이제 이야기되고 가르쳐질 수 있는 것이 된다. 마틴 파울러의 '리팩토링'을 읽어보면, 비슷한 접근을 해온 것을 엿볼 수 있다.

짝프로그래밍 하면서, 나는 당연하다고 여겼던 것들이 짝에게는 당연하지 않다는 것에 새삼스럽게 놀라곤 한다. 나는 별 감흥이 없었던 것들이, 짝이 '우와, 이렇게 접근할 수도 있군요!'라고 발견해주면, 그게 당연한 것이 아니라 계발된 전문성의 요소라는 것을 깨닫게 된다.

<은지님과 페어 하면서, 백엔드-프론트가 같이 페어할 때 접근 방법이 달랐던 경험>

<민수님과 페어 하면서, 둘 다 예상치 못한 결과가 나왔던 경험>

우리는 이렇게 개발자들에게 숨겨져 있는 전문성을 계발하고 실력을 갈고닦기 위한 많은 활동들을 하고 있다.

<은지님과 DRT 한 것 스샷>

<비선형적 책 스터디>

부러우면 지원해라.

----
CategoryAgile