일하는 사무실이 인원이 얼마없고 서로 업무간 연관/의존이 높고, 의사교환(솔루션 배경지식, 기획적인 부분부터 기술적인 부분까지)할것도 상대적으로 많은것 같아 자연스럽게 PP을 하겠다고 명시적으로 시작한적은 없지만 그런 문화로 고정이 되어버렸습니다.
PP에도 방법이 여러가지 있겠지만, 저희는 보통 한명의 코딩, 한명의 관찰. 이런식으로 교대로 작업을 해나갑니다. 서로 막히는 부분이 있거나 자신이 자신있는 부분에서는 알아서 나서는식이죠. 그리고 상대의 작업을 보면서 마음에 안드는 부분이나 질문이나 장난을 계속 하는 식이죠.
어떤 문제나 그런것이 어울리는것은 아니겠지만, 분명 어떤 형태의 문제들은 그렇게 풀어가는게 더 도움이 될때가 많은것 같아요. 구조의 설계나 api의 형태를 결정하는 부분과 같이 공동체에 영향을 많이 미치는 부분일 경우에 큰 도움이 된다고 생각해요.
어떤 수업인지는 잘 모르겠지만, 독단/독선이 배제되야지 그 결과도 만족스러운 결과물인 경우에 적용하는것이 좋다고 생각합니다.
깨비님께서도 말씀해주셨지만, 논쟁을 잘하는 기술(무조건 상대방을 이겨내는것이 아니라, 좋은 결론을 도출해내면서도 '말싸움'이 아니도록 진행해 나가는)이나, 상대를 받아들일줄 아는 마음가짐(양측모두!), 그리고 무엇보다 뇌살(!)적인 눈빛이 중요하다고 생각합니다.
TDD/BDD을 적용할때에 글자그대로 테스트케이스가 스펙을 결정하고, behavior을 먼저 결정하고 코드를 만들어 나가도록 주도적인 입장에 있어야만 그 의미를 알 수 있듯이(TDD/BDD에 대한 회의적인 입장들의 절반은 이를 적용하지 않은 경우를 상정할 경우인거 같구요, 나머지 절반은 이를 적용하기 힘든 환경, 혹은 그런 환경을 유도해 나가는 개발자의 문제일거 같애요. 어쨌든.) PP도 그 의의와 목적성을 상실한다면, 우정파괴밖엔 안될거라고 생각해요. ^^; 물론, 그 목적을 잃지 않으며 논쟁을 하면서도 서로를 존중할줄 알고, 자신의 틀림을 인정할수있을 정도로 자기자신을 이겨낼 수 있다면 이 춥고 어두운 세상에서 얻기 힘든 코딩프렌드를 얻을 수 있기도 하지요...
제대로 된 짝프로그래밍은 못해봤지만 짝프로그래밍을 시도하는 데 있어 꼭 한 컴퓨터에 같이 앉을 필요 없이 이런 방법을 쓸 수도 있습니다. (단, 리눅스 계열에서 터미널로 코딩할 때 한정)
조금 더 용기내고 그 용기에 대해 조금 더 배려해주고... 그런게 필요한 것 같더라구요. ^^;
제 생각에는 그냥 해보시면서 느끼는게 더 좋을 것 같네요. 아주 어려운 문제를 하나 놔두고 같이 풀어보세요. 좋은 점을 자연스럽게 느끼실겁니다.
일하는 사무실이 인원이 얼마없고 서로 업무간 연관/의존이 높고, 의사교환(솔루션 배경지식, 기획적인 부분부터 기술적인 부분까지)할것도 상대적으로 많은것 같아 자연스럽게 PP을 하겠다고 명시적으로 시작한적은 없지만 그런 문화로 고정이 되어버렸습니다.
PP에도 방법이 여러가지 있겠지만, 저희는 보통 한명의 코딩, 한명의 관찰. 이런식으로 교대로 작업을 해나갑니다. 서로 막히는 부분이 있거나 자신이 자신있는 부분에서는 알아서 나서는식이죠. 그리고 상대의 작업을 보면서 마음에 안드는 부분이나 질문이나 장난을 계속 하는 식이죠.
어떤 문제나 그런것이 어울리는것은 아니겠지만, 분명 어떤 형태의 문제들은 그렇게 풀어가는게 더 도움이 될때가 많은것 같아요. 구조의 설계나 api의 형태를 결정하는 부분과 같이 공동체에 영향을 많이 미치는 부분일 경우에 큰 도움이 된다고 생각해요.
어떤 수업인지는 잘 모르겠지만, 독단/독선이 배제되야지 그 결과도 만족스러운 결과물인 경우에 적용하는것이 좋다고 생각합니다.
깨비님께서도 말씀해주셨지만, 논쟁을 잘하는 기술(무조건 상대방을 이겨내는것이 아니라, 좋은 결론을 도출해내면서도 '말싸움'이 아니도록 진행해 나가는)이나, 상대를 받아들일줄 아는 마음가짐(양측모두!), 그리고 무엇보다 뇌살(!)적인 눈빛이 중요하다고 생각합니다.
TDD/BDD을 적용할때에 글자그대로 테스트케이스가 스펙을 결정하고, behavior을 먼저 결정하고 코드를 만들어 나가도록 주도적인 입장에 있어야만 그 의미를 알 수 있듯이(TDD/BDD에 대한 회의적인 입장들의 절반은 이를 적용하지 않은 경우를 상정할 경우인거 같구요, 나머지 절반은 이를 적용하기 힘든 환경, 혹은 그런 환경을 유도해 나가는 개발자의 문제일거 같애요. 어쨌든.) PP도 그 의의와 목적성을 상실한다면, 우정파괴밖엔 안될거라고 생각해요. ^^; 물론, 그 목적을 잃지 않으며 논쟁을 하면서도 서로를 존중할줄 알고, 자신의 틀림을 인정할수있을 정도로 자기자신을 이겨낼 수 있다면 이 춥고 어두운 세상에서 얻기 힘든 코딩프렌드를 얻을 수 있기도 하지요...
답변을 달아주신 모든 분들께 감사합니다 ^^ 어떻게 접근해야할지는 대충 윤곽이 잡히네요~
저도 몇번 시도해 본 바 있지만 거의 대부분 실패했었습니다. 이유는 언제나 결과가 빨리 나오길 바라는 조급함 때문이었던 것 같군요. 일반적으로 programming할 때 충분한 여유가 없는 경우가 많았기 때문이기도 하고요.
상대가 실력이 뛰어나면 저한테 설명해야 하는 답답함과 시간이 아까운 마음이 저절로 와닿더군요. 또한 실력이 없으면 자기가 이걸 꼭 이해해야 하나라고 생각하면서, 제게 결과만 내달라라는 식이 많았습니다.
PP의 경우 대게 그 강점을 장기적인 안목에서 바라보는 경우가 많은데 거기에 대한 합의가 없는 이상 기존의 방식을 고수할려는 저항은 필연적일지 모릅니다.
새로운 programming 언어를 배우는 부담과도 비슷하겠죠.