처음보는 언어로 하루만에 테트리스를 못짜면 뭔가 문제가 있다구요 ? ^^; 난 때려치워야 하나? --
그로밋
기분이 상하셨다면 죄송합니다. 테트리스를 상용화된 테트리스 처럼 짜기보다는 텍스트에서 작동해도 상관없으니 (바를 #### 이렇게 표현해도 되는 식으로) 기본적인 테트리스의 기능만 가지고 실행만 된다면 만들 수 있으실 겁니다. GUI는 상관없이 문법의 차이만 익히면 되니까요. -- 박기태
약간 과장된 수사적 표현 같습니다.
프로그래머로(혹은 어떤 일이건 지식 노동자로) 성공하기 위해 학습능력이 필수적이다라는 주장에는
피터드러커를 포함 아무도 이견을 달지 않을 것입니다. 하지만 과연 학습능력과 지능지수(I.Q.)에 어떤 긴밀한 관계가 있는가 하는 것에는 의문이 남습니다(I.Q.의 신빙성에 대해서는 많은 논쟁이 있었고, 현재 I.Q.는 그 자체로는 학계에서 큰 의미를 갖고 있지 않다고 알고 있습니다). 또, 프로그래머로서의 성공 가능성과 지능지수 간에 또 필연적 관계가 있는가 이것 역시 확실하지 않습니다(별 관계가 없다는 연구 결과가 많이 있습니다).
그리고 마지막으로 테트리스를 처음 접하는 언어로 하루만에 작성하는 것이 그 사람의 학습능력(혹은 지능지수)과 어떤 연관이 있는가 하는 문제가 있습니다.
저는 큰 연관이 없다고 봅니다. 제가 사람(개발자)을 뽑을 때, 어떤 알고리즘 중심의 문제를 내어 주고, 그 문제를 자신이 익숙하게 쓰는 언어와는 가장 이질적인 언어를 하나 골라서 풀어보라고 했습니다. 시간은 특별한 제한을 두지는 않습니다. 일종의 연구과제 같은 것이죠. 그리고 숙제를 제출할 때에는, 완성된 소스코드와 함께, 문제 풀이 과정의 타임 로그(언제 뭐 했는지를 기록한 것), 그리고 이 문제 풀이(새 언어를 학습하는 것 포함)를 통해 자신이 배운 교훈을 보고서 형태로 정리해서 제출토록 했습니다.
이때, 어떤 문제를 주는가가 무척 중요합니다. 가급적 GUI나 시스템 호출이 필요없는 문제를 주는 것이 좋습니다. 그렇지 않으면 어떤 언어를 고르건 해법이 비슷해 지거나, 아니면 쓸데없는 데에 시간을 허비하기 쉽상입니다. 평가시에는, 얼마나 빨리 학습했는가도 중요하지만, 어쩌면 그것보다 더 중요한 것은 어떻게 학습했는가, 그리고 무엇을 학습했는가, 학습한 것을 어떻게, 얼마나 적용했는가, 그리고 학습과 실습 간을 오가며 피드백을 어떻게 받는가, 자신의 실패에서 교훈을 얻어서 자기개선을 하는가, 자신의 기존 지식을 비울 수 있는가(
UnlearnTheLearned) 등입니다. 이 모두가 프로그래머로 성공하기 위해 중요한 요소들(동시에 학습 능력에 있어 중요한 요소)이라고 생각합니다.
이런 복잡한 것을 과연 하루만에 테트리스를 짜는가 마는가의 흑백으로 판가름을 할 수 있을런지 의문스러울 뿐 아니라, 제가 알고 있는 이미 성공한 프로그래머들이 이 테스트를 통과할런지도 확신이 서지 않습니다.
김창준님의 글을 보니 제가 좀 극단적인 표현을 쓴것 같네요.
테트리스를 처음 접한 언어로 만들 수 있는지 테스트 하는 건 테트리스의 경우 누구나 다 해본 게임이기 때문에 어떤 구조로 작동되고 어떠한 프로세스가 필요하고 어떠한 알고리즘(특히 알고리즘이 필요할 만한것도 없지만)이 필요한지 알 수 있기 때문에 한가지 언어에 완전히 익숙해진 사람의 경우 다른 언어에 대한 접근을 문법의 차이나 사용법의 차이 및 그 언어 만의 프로그래밍의 방식를 알게 되면 만드는 과정은 매우 쉽게 이루어질 수 있기에(이 과정에서 학습능력이 떨어진다면 쉽게 만드는 과정이 이루어질거라 보지 않습니다.) 그런 얘기를 했습니다. 그리고 테트리스를 꼭 GUI로 만들라는 얘기는 아니였습니다. 러시아에서 만들어진 최초의 테트리스는 텍스트에서 실행되는 프로그램이였습니다. #이나 *같은 걸로 박스와 바를 만들어 그걸 떨어뜨리고 쌓아서 작동시켰죠. GUI는 전혀 상관없이 테트리스를 만든 다면 시스템 호출이나 GUI의 사용법의 차이때문에 오는 문제는 피할 수 있습니다. 그리고 테트리스는 제가 생각하는 가장 쉬운 예라 생각했고 위의 표현에 최소한이라고 되어 있죠. 실제로 문제를 낸다면 저렇게 쉬운 문제를 내지는 않을 겁니다.
그리고 제가 생각하는 I.Q.란 얼마나 패턴을 잘 찾느냐로 정의를 합니다. 예를 들어 경제의 다양한 변수들(원유가, 나스닥지수, 환율의 변화 등등)과 한국 시장간의 관계를 규명하기 위해서는 단순 비교로는 되지 않고 다양한 방식으로 관계를 알아내야 하는데 그 때 패턴찾기에 능한 사람과 그렇지 않은 사람간의 차이는 극명하게 들어납니다.
개인적으로 I.Q.란 복잡하게 보이는 현상속에서 규칙을 찾아내고 단순화 시킬 수 있는 능력이라 생각합니다.
실제로 중고등학교에서의 I.Q.문제와 멘사의 I.Q.문제는 매우 다릅니다. 멘사의 I.Q.문제는 말그대로 패턴찾기로 논리회로나 기계어를 약간 공부한 해서 XOR,OR,AND의 비트연산의 응용만 잘하면 95%이상은 맞출 수 있는 문제들 입니다. (제가 멘사의 회원이기 때문에 압니다.) 근데 그 I.Q.란 충분히 신빙성이 있다고 생각합니다. 특히 프로그래머에게 있어서는.
--박기태
다큐먼트 모드의 글이 좀 주관적인 것 같습니다. 쓰레드의 내용을 적절히 반영할 필요가 있는 듯 합니다.
전 프로그래머의 능력을 지식, 학습 능력, 사고 능력 세 가지 정도로 판단할 수 있다고 봅니다. 저보고 프로그래머를 뽑으라면 이 세 가지 영역을 판단할 수 있는 테스트를 할 것입니다. 지식 테스트로는 리팩토링을 할 줄 아는지, 몇몇 널리 쓰이는 디자인 패턴을 알고 있는지, XP에 대해 아는지, 자신 있는 언어의 장단점에 대한 의견을 피력할 수 있는지를 물어볼 것입니다. 학습 능력 테스트로는 새로운 언어, 혹은 새로운 프레임웍을 던져주고 이를 이용해서 간단한 과제를 수행해보게 할 것입니다. 사고 능력을 판단하게 하기 위해서는 이제껏 팀내에서 발생했던 문제들을 던져주고 어떻게 해결하는지를 보겠습니다. 이런 테스트에서 좋은 결과를 보여줄 수 있는 사람이라면 좋은 프로그래머로 판단해도 좋으리라 생각합니다. 비중은 20:30:50 정도로 주면 되지 않을까 합니다.
반대로 이야기한다면 좋은 프로그래머가 되기 위해서는 이런 테스트를 통과할 수 있는 능력을 기르는 게 좋을 것입니다. 기초적인 지식들을 쌓고 학습 능력과 사고 능력을 키우는 것이죠.
인지심리학 쪽에 이와 관련한 연구가 많이 진행되었습니다(특히 70, 80년대 전문성expertise 연구에서). 체스의 대가들에게 진행 중인 체스 게임의 판 배치를 10초 이하로 보여주고 그걸 똑같이 기억해 내보라는 주문을 하면 별 어려움 없이 쉽게 해냅니다. 하지만 체스판의 말이 무작위로 배치되면 일반인의 기억능력과 통계학적으로 유의미한 차이를 보이지 않습니다. 즉 특출난 기억능력이나 패턴 인식 능력은 해당 도메인 내에서만 유효하다는 것이고, 특정 분야의 전문가가 일반적인 지적 능력에 있어 더 똑똑하다고 말하기는 어렵다는 것이죠. 다른 연구에서는, 뛰어난 체스 플레이어와 대가(전세계에서 손에 꼽는)를 구분하고자 할 때, 통상적인 I.Q.가 유효한 구분자가 되지 못했습니다. --
김창준
프로그래밍에는 기술적인 측면 말고도 사회적인 측면이 있기 때문에 그 부분을 고려해야 할 것입니다. 예를 들면 협업이라든가 의사소통능력 같은 것 말이죠. --
김창준
제가 만약에 사람을 뽑아야 하는 입장이라면, 그 사람이 리팩토링이던, 알고리즘이던 분명히 남보다는 뛰어나지 않더라도, 협업이 잘되고 의사소통이 잘된다면 반드시 뽑을것 같아요. 협업과 의사 소통이 잘되는 사람은, 금방 배울수도 있지요 ^^(이런글 달아도 되겠죠? ^^;) -
귀천
그렇게 생각해보니 사실 프로그래머는 일반적으로 좋은 지식 노동자의 자격만 있으면 된다고도 말할 수 있겠네요. 학습 능력이나 사고 능력도 따지고보면 지식 노동자에게 필수적인 덕목일테니까요. 지식 노동자에게 일반적으로 적용되는 내용과 프로그래머에게만 적용되는 내용으로 나누어서 생각해보면 어떨까요.
근데 의사소통을 잘하는지는 어떻게 판단할 수 있을까요? 면접자들끼리 토론 시켜보기?
HowToBeAProgrammer에서는 최소한 두 시간 이상 구두 시험을 실시해보라고 하는데 이것도 상당히 좋은 방법이라는 생각이 드는군요.
그런데 좋은 의사소통 능력이 어떤 것인지를 구체적으로 말한다면 어떻게 표현할 수 있을까요? 상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것? '일'에서의 토론은 어떻게 해야 잘하는 것일까요? 전 아직 어떤 게 좋은지 잘 모르겠습니다. 예전엔 상대를 설득하거나 혹은 내가 설득당할 때까지 밀어붙이는 게 회사를 위하는 길이라고 생각했는데 회의라는 것이 여러 사람의 시간을 한꺼번에 쓰는 것이다보니 토론이 소모적으로 흐를 때도 많은데 무작정 시간을 갖다 붓는 게 좋은지 회의가 들더군요.
지식 노동자..^^ 피터드러커님의 서적에서 본 표현 이군요 :-). 두시간 이상 구두 시험이라... 그러고 보니 Daum에서 면접을 볼때에도, 한두시간씩 면접을 보더군요...
상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것. 그게 핵심 아닐까요. 후자는 대부분 갖추 더라도, 전자는 그렇지 못한 경우가 많습니다. 상대방의 의견에 대해 제대로 듣고 이해하고 생각할수 있다함은, 어쩌면 바로 협업과도 연결될수 있는것 같습니다. '일'에서 토론 할때도 마찬가지 겠지요, 심지어, 코딩 스타일에 대해 회의를 하더라도... 상대방의 입장에서 왜 그게 좋은지 한번 심각하게 생각한 뒤에 자기 자신의 생각도 전달하고, 그리고 적당히 수용 할줄도 알아야 겠죠.
중대한 일에 대해서는, 만약 다른 사람의 의견이 선택 되었을때, 그 결정에 대한 영향이 위험할수 있고 막대하다면 논리적으로 설명하고 설득 해야 하겠지만, 그렇지 않을 때에는 큰 문제가 없다면 그냥 받아들일때도 있어야 한다고 봅니다.
어떤 논제에 대해 이야기 하다가 삼천포로 빠져 버리는등의 일을 피하기 위해, 회의를 하다가 계속해서 "지금 우리에게 중요한 것이 무엇이며, 핵심은 무엇이다. 이것을 정확히 결정 해야만 한다"는 생각을 계속 하는게 좋을듯 합니다. 그래야, 회의도 효율적으로 되지 않을까요? 당장
중요한것은 기간내에 훌륭한 프로그램의 개발하는 것이지, 내 코딩스타일이 왜 유용한가가 중요한게 아니거든요.^^(매우 주관적인 생각 이었습니다. ^^;) --
귀천
저는 사람을 뽑을 때에 그 사람의 협동 능력, 의사 소통 능력을 측정하기 위해 집단 토론과 집단 문제 해결을 하게 했습니다.
집단 토론은 찬반 양론으로 갈릴만한 사안을 주고 한쪽을 택하게 한 뒤 테이블 양단에 서로 마주보고 앉아 토론을 합니다. 대략 30분 정도면 많은 정보를 얻을 수 있습니다.
집단 문제 해결은 답이 딱 정해져 있지 않은 문제(ill-defined problem. 예컨대 새로운 핸드폰을 디자인해 봐라 등)를 내어 주고, 피면접자 4-5명이 한 팀이 되게 해서 팀별로 문제 해결을 하는 것입니다. 시간은 1시간 정도 주면 됩니다. (초반 10분-20분 정도 됐을 때에는 몇몇 분은 자신이 생각하는 "이상적인 팀원의 모습"을 연기하려고 노력합니다. 그러다가 중반이 지나고 다른 의견과 충돌이 있거나 데드라인이 가까워지면서 심리적 압력이 높아지면 원래의 자기 모습이 드러납니다.)
이런 과정을 다 끝낸 뒤에는, 피면접자 모두는 "평가서"를 작성합니다. 평가서에는 다른 사람들의 강점, 약점 등을 분석해서 적도록 합니다. 다른 피면접자를 포함 자기 자신에 대한 분석도 포함됩니다. 그리고 마지막으로 자기가 새롭게 배운 것이나 교훈 등을 적도록 합니다.
면접자(평가자)는 새로 뽑을 사람과 같은 팀에서 일할 사람 모두 입니다. 그들은 이런 면접 시간 중 손에 종이와 펜을 들고 이리저리 자리를 옮기고 사람들의 대화를 관찰하며 평가를 합니다.
see also
면접
예전엔 상대를 설득하거나 혹은 내가 설득당할 때까지 밀어붙이는 게 회사를 위하는 길이라고 생각했는데 ... 토론이 소모적으로 흐를 때도 많은데 무작정 시간을 갖다 붓는 게 좋은지 회의가 들더군요.
상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것. 그게 핵심 아닐까요.
이상적으로는 잘 이해하고 잘 전달하는 것이 좋은 의사 소통을 의미하는 것이겠죠. 하지만 현실 상황에서는 무수히 많은 제약이 있고, 그 제약 내에서 최선을 택해야 합니다. 특히나 그 제약에 시간이 걸려 있으면 최선보다는 그럭저럭 좋은 것을 택하는 경우가 현실적으로 더 낫기도 합니다.
모든 선택에는 트레이드오프가 있는 것이고 그 균형을 잘 잡는 것이 뛰어난 퍼포먼스와 직결되는 것 같습니다.
앞서 언급한 제가 시행한 면접 방식을 진행해 보면, 가장 우수한(창의적, 현실적 면에서) 결과를 발표하는 팀의 경우 어떤 특징이 있습니다. 그것은 정해진 시간 내에서 나름대로 괜찮은 안을 결정하고 모두가 즐겁게 동참하는 팀입니다. 그런 팀의 분위기를 만드는데 일조하는 사람의 패턴이 있을까요? 네, 있는 것 같습니다. "유도"(무술)를 잘하는 사람에 비유할 수 있을 것 같습니다.
조금 원 주제에서 멀어지는 것 같긴 하지만, 그 패턴에 대해 좀더 자세히 말씀해주실 수 있나요? 어떻게 하면 그런 사람이 될 수 있는지 알고 싶습니다. 전 스스로가 상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것은 잘한다고 생각하지만 그리 효율적인 토론을 하고 있진 못합니다. 어떤 경우는 어려운 문제를 아주 효율적으로 결론내리기도 하지만 어떨 때는 간단한 문제인데도 질질 끌면서 스트레스만 받는 경우도 많거든요. 그런 경우 속으로 그 책임을 참여자 중 몇몇에 전가시키기도 하는데-_- 그런 경우도 효율적인 토론을 이끌어낼 수 있는 사람이 되고 싶습니다. 그러려면 어떻게 해야할까요?
간단하게 설명할 수 있는 그런 종류의 것은 아닌 것 같습니다만 위험을 무릅쓰고 몇가지 떠오르는 내용을 끄적거려 보겠습니다. 상대가 가려고 하는 힘의 벡터가 일시적으로 장애가 된다고 할 때 그 힘을 막아선다기보다 흐름의 결을 따라 받아 넘기는 기술이 중요한 것 같습니다. 정면으로 받아내면 나에게도 타격이 있고 상대에게도 타격이 있습니다. 그리고 진지함과 유치함을 자유롭게 오가는 것도 필요한 것 같습니다.
테트리스를 예로 드신 것이 적절치 않다 여겨지는 이유는 텍스트로 구현한다해도 스크린 임의의 위치에 문자를 써넣고 키 입력을 처리하는 것은 GUI 못지 않게 특정 OS, 특정 터미널 그리고 (리눅스의 ncurses같은) 특정 라이브러리에 의존적인 (그쪽이 업이 아닌 이상 레퍼런스 찾아보면 되고 기억할 필요는 없는) 지식들을 필요로 하기 때문입니다. 뭐 라이브러리 레퍼런스를 뒤지는 능력도 능력이긴 하겠지만 사실 그 정도는 기본기겠죠. 프로그래머로서의 코어 능력을 테스트하기에 테트리스는 여전히 군더더기가 많고 많은 자질을 증명해주지도 않는다 여겨집니다.
--
또마 2008-06-12 14:30:03
![[http]](/ns/imgs/http.png)
How to Design Programs를 추천합니다.전자는 concurrent programming를 비롯하여 multiparadigms를 보여줍니다.후자는 design recipe등 매우 재밌게 프로그래밍을 배울 수 있습니다. StructureAndInterpretationOfComputerPrograms라는 훌륭한책의 문제점을 해결하기 위해 만들어진 책이라고 합니다.그 외에 
