훌륭한프로그래머의딜레마

훌륭한 프로그래머는 가난하다. 그가 가난을 벗어나려면 그 "훌륭함"부터 벗어나야 한다.

"열심히"씨와 "훌륭한"씨는 각각 "엄청난소프트웨어회사"와 "허벌난소프트웨어회사"의 두 직원이다. 우연치 않게 두 회사에 정확히 똑같은 내용의 주문이 들어왔다. "열나어려운문제" 해결을 위한 프로그램을 작성해 달라는 것이었다.

열심히씨는 처음 예상 소요 시간인 3개월 동안 정말 열심히 일했다. 하지만 일을 하면서 예상 외의 장애를 직면했고, 밤샘 작업까지 해가면서 3개월의 마지막 날 매니져에게 이런 말을 할 수 있었다. "정말 열나게 프로그램을 짰슴다. 밤샘도 하고요. 제가 지금까지 작성한 프로그램은 2000줄입니다. 그런데, 새로운 문제가 기술적으로 불가피하게 발생했습니다. 복잡한 버그(프로그램의 오류)도 몇 가지 해결해야 하고요. 한 달 가량이 더 필요합니다." 그러고 한달 후 열심히씨는 몇 개의 버그와 더불어 나름대로 작동하는 프로그램을 매니져와 고객에게 자랑스럽게 보여줄 수 있었다. 벌겋게 충혈된 눈과 미쳐 깎지 못한 수염, 무지무지 어렵고 복잡해 보이는 2500여 줄의 프로그램과 함께. "예상보다 훨씬 더 복잡한 문제였군요. 정말 수고하셨습니다."라는 칭찬을 들으면서.

훌륭한씨는 매니져가 "의무적으로" 잡아놓은 예상 소요 시간 3개월의 첫 2달 반을 빈둥거리며 지냈다. 매니져는 훌륭한씨가 월말이 되어서 "정말 죄송해요. 아직 한 줄도 못짰어요. 너무 어려워요. 좀 봐주세요."라고 처량하게 자비를 구할 날을 손꼽아 기다렸다. 웬걸, 마지막 날 훌륭한씨는 예의 "너무도 태연스러운" 모습으로 나타났다. 150여 줄의 프로그램과 함께. 그 프로그램은 멋지게 "열나어려운문제"를 해결했다. 하지만, 매니져가 그 코드를 들여다 보자, 한마디로 "너무도 쉬웠다." 초등학생도 생각해 낼 정도였다. 매니져와 고객은 이름을 "열나쉬운문제"로 바꾸는 데에 전적으로 동의한다. 훌륭한씨는 "이렇게 간단한 문제를 3개월 씩이나 걸려서 풀었습니까? 왜 이렇게 성실하지 못하죠?"라는 비난을 들어야 했다.

둘 중에 누가 승진을 했을까?

열심히씨는 승진하고, 급여인상을 받았다. 훌륭한씨는 급여삭감을 직면하고는 퇴사해 버렸다.

훌륭한 프로그래머는 가난하다. 훌륭한 프로그래머의 딜레마인 것이다.

-- 김창준 이 이야기는 SE계의 잘 알려지지 않은 명작 ''Wicked Problems, Righteous Solutions'' 에 나온(원래는 CACM 기사였던) 일화를 직접 각색한 것이다

훌륭한 프로그래머는 어려운 문제를 "터무니 없을 정도로 간단한 문제"(see also RidiculousSimplicity)로 풀어내는 재주가 있다. 남들이 보기에는 그것이 너무도 당연한 해결법으로 보인다. 하지만 그들은 쉽게 생각해 내지 못한다. 그러고는 훌륭한 프로그래머를 우습게 본다.

중간치기나 하치기 프로그래머는 어려운 문제를 어렵게 혹은 더욱 어렵게 풀어내는 재주가 있다. 남들이 보기에는 그것이 너무도 기발한 해결법으로 보인다. 역시 그들은 쉽게 생각해 내지 못한다. 그러고는 중간치기 하치기 프로그래머를 대단하게 본다.

see also 노자 도덕경

과거 IBM사에서는 프로그램의 줄 수에 따라 급여를 계산했었다. (사실 지금도 이런 회사가 상당수 있다) 그런데 프로그램 줄 수가 늘어날 수록 숨겨진 버그 수와 유지관리에 드는 비용은 기하 급수적으로 늘어나게 된다. 이 문제를 해결하기 위해 프로그램 줄 수는 더 늘어나게 되고, 덕분에 프로그래머는 돈을 더 벌게 된다.

남들이 보기 쉽게 짤 수 도 있으나 어렵게 짜는 수를 일부러 부릴 때도 있는 것같네요. 위에 "훌륭한" 프로그래머가 이 세상에서 살아남기 위해선 "열심히" 프로그래머인 것처럼 해야하는 것이 아닐까요, 군발이 시절 3시간 정도 할 수 있는 일을 언제나 하루 정도 걸려서 끝마쳤죠. 만약에 그 일을 3시간에 정말 끝마쳐 버린다면 다음 프로젝트때는 그 일에 해당하는 시간을 2시간 정도를 주는 것으로 바뀌어져 버리니까요. 이건 곧 그사람의 직업관에도 연관 되는 문제가 아닐련지. -- rururara

훌륭한 프로그래머는 "터무니 없을 정도로 간단한 문제"로 풀어내는 재주가 있을 뿐더러, "터무니 없을 정도의 어려운 문제로 보이는 쉬운 문제"를 잘 섞어서 좋은 아이디어를 제시하는 재주가 있다. 당연히 중간치기, 하치기 프로그래머 모임에 있어서는 훌륭한 프로그래머가 해결안을 제시하기도 전에 간단히 배제가 되고 만다.

이유는??
중간치기, 하치기 프로그래머가 바라보는 시선이 이미 한정되어 있기 때문에, 그 범위 밖에서 문제를 해결한다거나, 뿌리를 잘라내는 얘기는 당연히 범위 밖의 바보같은 얘기이기 때문이다.^^

예로,
입술에 묻은 밥알을 떼기 위해서는 일반적으로 인간에게 있어 미세한 행동을 할 수 있는 손, 그 중에서도 엄지와 검지손가락이 필요하다는 전제하에서 이루어지는 중간치기 하치기 프로그래머들의 모임이 있다.

훌륭한 프로그래머의 "입술에 묻은 밥알을 혀로 떼어 먹으면 되잖아요"란 해답은 당연히 먹힐리 없다. "어깨 반경을 좁히기 위헤 손을 직선으로 올려 팔꿈치로 90도를 꺾으면 최단거리의 궤적이 나오고, 이때 밥알의 접착성을 이용해서, 검지로만 문제를 해결해야 하는데, 접착성은 상온에서만 유지되고 밥알은 굳기 이전의 14시간 내에, 습도 70%이상에서만 해결할 수 있는 문제이고, 그 이외의 문제는 나중에 해결하자"란 답이 그 회의에서의 정답이기 때문이다.

훌륭한 프로그래머는 훌륭한 중간관리자가없이는 훌륭해질 수 없다. -- cavin

훌륭한 프로그래머의 조건에는 자신이 한 일이 얼마나 중요하고 가치있는 일인지 설득할 수 있는 능력도 포함됩니다. 그가 한 일이 어떤 일인지 아무도 알아차리지 못한다면, 그는 대수롭지 않은 일을 해낸 것에 불과합니다.

관리자가 바보가 아니라면, 쉬운 일을 복잡하게 풀어내는 능력을 더 평가할 리 없습니다. 관리자, 평가자의 문제이죠. 보통 회사에서는 source code를 '갑'에게 보여주지 않습니다. source code를 길게 짜는 능력은 간혹 필요할 때만 쓰면 되는 능력이죠. 일을 간단하게 해결했어도 '갑'에게는 엄청난 연구개발 끝에 성공했다고 구라를 쳐야만 합니다.

보통 회사에서는 일이 끝나면 다음 일을 넘겨주기 때문에, 복잡한 일을 간단하고 쉽게 풀어내는 사람은 훨씬 더 많은 일을 하게 됩니다. 영업하는 사람이 바보가 아닌 다음에야 적정한 가격에 적정 규모 프로젝트를 수주하게 되고, 결국 일을 간단하고 쉽게 풀어내는 사람은 더욱 많은 매출을 올리는 기여를 하게 되고, 급여가 올라가게 됩니다.

회사 내부적으로도 프로젝트의 업무를 분담할 때 미리 회의를 통해 업무량을 가늠해보고 그에 맞추어 일정을 정하고 인력을 배정합니다. 예상보다 일을 빨리 끝내면 당연히 더 높은 평가를 받게 됩니다.

회사의 관리가 그렇게 비합리적이고 어설프지는 않습니다. 훌륭한 프로그래머는 자신만 그렇게 생각하는 것인지, 남들도 그렇게 생각해주는 것인지 고민해 보고, 남들이 왜 그렇게 생각해주지 않는지 분석해 볼 필요가 있습니다. 자신만의 착각일수도 있고, 남들에게 제대로 표현하지 못한 문제일 수도 있습니다. 어쨌거나 자신이 훌륭한 프로그래머라고 생각되는데 남들은 그것을 인정해주지 않는다면, 그것은 자신에게 문제가 있는 것입니다.

글을 읽다보니 프로그래머의 평가에 대한 부분도 고려해볼 문제네요~ SI나 관리, 운영에 있다보면 그룹웨어에 매일매일 올라가는 내용을 체크해보고, 분기별로 평가를 팀장-중간관리직-최고관리직이 한다던가라는 식이면 처리한 일의 분량과 가치별 적절히 판단할 수도 있겠다 싶지만, 이는 어디까지나 훌륭한 프로그래머가 일의 분량이 앞설 수 있는 상황이거나, 수행해 낸 결과물의 가치를 팀장을 포함한 그 윗선에서도 명확히 인식할 수 있을 때의 문제라고 생각되네요~

특정 프로젝트 수행에 대한 가치를 판단할 때에 팀장이나 혹은 그 위의 관리직 보기에 어려운 문제를 적은 시간내에 잘 해결했다라고 생각하는 것과, 쉬운문제를 그렇게 오랜시간에 빙글빙글 놀면서 풀었다라고 판단 하는 것은 어디까지나 일의 수행능력과 일의 처리능력의 문제가 아닌 평가 및 판단하는 사람의 입장에서 어떻게 받아들이는가의 문제가 아닐까요?

시간이 차차 지나면서 대부분의 훌륭한 프로그래머는 훌륭하다는 것을 주위 사람이 인식하기도 하지만, 그렇지 않은 경우도 위와같은 이유로 왕왕 있다는 잡담이랍니다. 특히나 연구 및 제품개발과 같이 분량의 차이보다 가치판단을 요하는 경우엔 말이죠~ 개인적인 생각입니다^^;

전에 봤던 우주에서 써지는 볼펜 이야기가 생각나네요. 우주에선 중력이 모자라 볼펜을 쓸 수가 없어 엄청난 비용을 들여 우주에서 써지는 볼펜을 만들어서 들고 올라갔더니 소련 우주비행사들은 연필로 쓰더라는 ...

한국에서 손꼽을 수 있는 프로그래머는 누구입니까? -- 아무개

자신이 프로그래머라고 생각하고, 또 자신의 일을 즐기는 사람이라고 생각한다면 그 사람은 이미 훌륭한 프로그램머로서의 선상에 놓여있는 것이라 생각합니다. 하지만, 의외로 적지 않은 사람들이 이런 말들을 젊었을 때 한때의 혈기로서 넘겨버리는 현실이 아쉽습니다. 저 역시 프로그램을 하고 있지만 솔직히 자신없습니다. 지금까지 해왔던 이 일을 얼마나 더 내가 즐기면서 할 수 있을지.. 훌륭한 프로그래머는 그의 솜씨가 남들보다 아주 특별났을 때 붙이는 이름보다는 조금 서툴더라도 즐겁게 자신의 일을 소화해 내는 사람에게 붙여주고 싶습니다.. -- 엉뚱

가끔...아주 가끔...정말이지 아주 가끔...나를잊어줘는 자신이 만든 프로그램이 아름답게 느껴질 때가 있다. 그런 때는 프로그램에 심취하여 가슴이 두근거릴 정도다. 이것이 현재 그가 프로그래머로 살아가고 있는 이유가 아닐까 싶다.

훌륭한프로그래머의딜레마 비하인드스토리

"중요한"씨는 "중요한프로젝트"를 하나 가지고 있었다. 그리고 이 프로젝트는 "어려운문제"를 가지고 있었다. 이 문제를 해결하는 방법은 A 프로세스를 이용하면 된다. 하지만 이 프로세스를 사용하는데는 실력있는프로그래머가 있어야 하며, 실력있는 프로그래머라도 2개월의 시간이 걸린다. 하지만 이 안에 "숨겨진어려운문제" 2개가 숨겨져 있고, 실제 구현단계가 되어서야 이 문제를 발견할 수 있을 것이다. "숨겨진어려운문제"까지 2개를 모두 해결하는데에는 6개월이 걸린다. 물론 "중요한"씨도 "숨겨진어려운문제"가 있다는 것은 몰랐다. 단지 실력있는프로그래머가 없기 때문에 다른 회사에 발주를 하기로 했다. "중요한프로젝트"는 꼭 성공해야 하기 때문에 "엄청난소프트웨어회사"와 "허벌난소프트웨어회사"에 동시에 발주를 했다.

발주를 받은 각 회사의 PM들은 "중요한프로젝트"를 면밀히 검토한 결과 2개월의 시간이 걸린다는 것을 파악했다. 하지만, "중요한프로젝트"가 "어려운문제"를 가지고 있다는 것을 잘 알고 조금더 안정적으로 진행하는 것이 좋다고 생각했다. 그래서 3개월의 시간이 걸린다고 통보했다. 두 회사가 똑같이 3개월을 원했기 때문에 "중요한"씨는 이 기간이 적당하다고 결정했다.

"열심히"씨는 "어려운문제"프로젝트가 정말 어렵다는 것을 알았다. A프로세스를 사용해야만하며, 적어도 2개월은 걸릴 것이다. 하지만 PM이 정해준 3개월이라는 기간은 충분한 기간이었다. 자신이라면 이것을 2개월에 할 수 있을 것이다. 3개월짜리 프로젝트를 2개월에 맞추면 자신의 능력을 인정 받을 것이고, 승진할 수 있을 것이다. "열심히"씨는 A프로세스 준비단계에 진입했다.

"훌륭한"씨도 "어려운문제"프로젝트가 정말 어렵다는 것을 알았다. A프로세스를 사용해야만하며, 적어도 2개월은 걸릴 것이다. 그리고 PM이 정해준 3개월이라는 기간은 충분한 기간이다. "훌륭한"씨도 A프로세스 준비단계에 진입했다.

"열심히"씨는 준비단계를 무사히 끝내고, 실무단계에 진입했다. 실무단계에서 "열심히"씨는 "숨겨진어려운문제"하나를 발견하고는 깜짝 놀랐다. 이 문제까지 해결하는 데에는 4개월이 걸릴 것이다. "열심히"씨는 이 문제를 PM에게 보고 하려다가, 자신이라면 3개월에 끝낼 수 있다는 것을 알았다. 좀더 일찍 끝내지 못하는 것은 아쉬웠지만, 프로젝트 기간은 3개월이고 PM에게 괜히 걱정을 끼칠 필요는 없다고 생각했다. "숨겨진어려운문제"를 PM이 알게되면 엄청 걱적할 것이고, 자신의 일에도 간섭할 수 있을 것이며, 이는 프로젝트 자체에 사족이 될 수 있을 것이다.

"훌륭한"씨가 막 준비단계를 끝내려고 했을 때, 여기에 내재된 "숨겨진어려운문제"를 하나 찾아냈다. 그리고 이 문제까지 해결하려면 4개월이 걸린다는 것을 알았다. 이 문제를 PM에게 보고하려고 하다가 자신이라면 3개월에 할 수도 있다는 것을 알았다. "훌륭한"시는 얼른 준비단계를 수정하기 시작했다. 그리고 준비단계가 끝나갈 때 쯤에, 마지막으로 남은 "숨겨진어려운문제"를 찾아냈다. 이 문제까지 해결하는 데에는 6개월의 시간이 걸릴 것이라는 것을 알았다. 이것은 자신이 해도 4개월은 걸릴 것이다. 3개월 안에 끝마칠 수 있는 방법을 생각해 보았지만 찾을 수 없었다. 늦게전에 PM에게 보고하고 방법을 찾기로 했다. 아마 기간을 최소 1개월은 연장하자고 해야할 것이다.

"열심히"씨는 정말 열심히했다. 준비단계를 다시 수정하고, 다시 실무단계에 진입했다. 그리고 열심히하고 있는 중에 마지막 "숨겨진어려운문제"를 발견했다. 여기서 까무라칠뻔 했지만, "열심히"씨는 곰곰히 생각해 보았다. 여기서 프로젝트가 6개월이 걸린다면 PM도 곱게 보지 않을 것이다. 어떻게 2개월짜리 프로젝트가 6개월이 될 수가 있겠는가? 전에 보고하지 않은 것도 문제가 될 것이다. 그냥 열심히 하기로 했다. 프로젝트가 끝나갈 때쯤 어떻게든 될 것이다. 자신은 어쨌든 열심히 하고 있지 않을가?

"훌륭한"씨는 PM에게 보고하러 가면서 마음이 편하지 않았다. 우선 "숨겨진어려운문제" 하나를 보고하지 않았었고, 프로젝트도 제시간 안에 할 수 었었기 때문이다. 하지만 PM은 자리를 비우고 있었다. 어쩔수 없이 돌아서는 순간 번뜩이는 아이디어가 생각났다. 이 아이디어가 가능한지를 테스트해 보려면, 몇 가지 확인할 것들이 있고, 테스트도 해 봐야 할 것이다. 그리고 실패할지도 모른다. 하지만 3개월이면 충분히 할 수 있을 것이다. 어쨌든 자신은 6개월짜리 문제를 3개월만에 해결하는 것이 아닌가?

"엄청난소프트웨어회사"의 PM은 "중요한"씨를 만나고 오는 중이었다. "열심히"씨가 무엇인가 문제가 있는 듯한 눈빛이지만 열심히하고 있었고, 벌써 실무단계에 진입했지 않은가? 그리고 중요한 것은 "열심히"씨가 실력있는 프로그래머라는 것을 자신도 잘 알고 있었다. "중요한"씨에게 프로젝트가 너무 잘되고 있어서 걱정이라고 이야기를 하고 왔다.

"허벌난소프트웨어회사"의 PM은 "중요한"씨를 만나러 가고 있었다. 하지만 불안했다. "훌륭한"씨가 무슨 일인지 몰라도 실무단계로 진입하지 않고, 준비단계만 계속 하고 있었다. 그것은 "훌륭한"씨 답지 않은 일이지만, 문제 보고도 하고 있지 않았다. PM은 "훌륭한"씨가 실력있는 프로그래머라는 것을 잘 알고 있었기 때문에 그를 믿었다. "중요한"씨에게는 프로젝트가 잘 진행되고 있다고 보고할 것이다.

"열심히"씨는 점점 초조해하고 있었다. 벌써 프로젝트가 시작한지 2개월이 훌쩍 넘어서 3개월이 다가 오고 있었다. 아무리 열심히 하더라도 최소한 1개월은 더 걸릴 것이다. 6개월짜리 프로젝트를 4개월에 끝낸다고 하더라도 정말 대단한 것이지 않은가?

"훌륭한"씨도 점점 초조해하고 있었다. 벌써 프로젝트가 시작한지 2개월이 훌쩍 넘었지만, 아직도 테스트를 다 하지 못했다. 거기다가 PM도 의심스러운 눈초리를 보내고 있다. 자신이 A프로세스를 하지 않고 있다는 것을 알고 있는 것이다. 하지만 조금만 더 하면 될 것 같다.

"열심히"씨는 밤을 새가면서 하기 시작했다. 어쨌든 1개월의 기간이 더 필요할 것이며, 예의상 마지막에는 더 열심히 해 주어야 한다.

"훌륭한"씨는 드디어 모든 테스트를 끝내고, 구현단계로 넘어갔다. 이제야 좀 마음이 놓인다. 그런데 PM이 자신을 보는 시선이 곱지 않다. 모 그렇게도 보였으리라. 많이 격어본 일이었다. 하지만, 3개월만에 문제가 해결된 것을 알면 그도 이해하게 될 것이다.

"열심히"씨가 열심히 했다는 것을 PM은 잘알고 있었다. 그리고 "숨겨진어려운문제"가 2개나 더 있다는 것을 알았다. "중요한"씨에게 이것에 대해서 보고를 할 것이다. 이 프로젝트는 6개월짜리였다고 말이다. 문제가 워낙 교묘히 숨겨져 있어서 찾기 어려웠고, 우리 프로그래머에게 1개월을 더 달라고 할 것이다.

"훌륭한"씨가 문제를 해결했다는 것은 인정하겠다. 하지만 그는 열심히 하지 않은 것 같다. PM은 "훌륭한"씨를 더이상 믿을 수 없게 되었다. 하지만 프로젝트는 끝이 났고, "중요한"씨에게 프로젝트 결과물을 넘겨 주었다. "중요한"씨가 조금 뜻밖이라는 표정으로 자신을 바라보는 것을 이상하게 생각했지만, 별로 대수롭지 않게 생각했다.

"훌륭한"씨는 PM이 자신을 믿지 못한다는 것을 알자 회사를 그만두었다. PM과 프로그래머의 마음이 맞지 않는다면, 회사, PM, 자신 모두에게 좋지 않다는 것을 알기 때문이었다.

"열심히"씨는 1개월 후에 프로젝트를 완성했다. 스스로 생각해도 자신이 대견하게 느껴졌다. PM도 자신을 칭찬했고, 승진도 확실하게 되었다. 비록 힘들었지만 보람이 있었다. "중요한"씨에게 결과물을 넘겨주자, 그렇게 반기지는 않았다. 아직도 1개월이 초과된 것에 대해서 불만을 가진 것 같았다. 6개월짜리를 4개월에 했는데도 불구하고 불만이 있다니. 중요한이라는 이름이 아깝다고 생각했다.

"중요한"씨에게 또 다른 "중요한프로젝트"가 생겼다. 그리고 이 프로젝트는 "더어려운문제"를 가지고 있었다. 하지만 걱정하지 않았다. "중요한"씨는 "허벌난소프트웨어회사"에 맡기면 된다는 것을 알고 있었기 때문이다. 그리고 PM을 만나서 이 프로젝트를 전에 했던 사람에게 맡겨주시오.라고 하면 충분하다고 생각했다.

"훌륭한"씨 당신은 우리 회사에 꼭 필요한 사람입니다. 다시 우리 회사에 들어와 주십시오. PM은 간절히 부탁하고 있었다. "중요한"씨에게 차마 그 프로그래머는 그만 두었다고 할 수가 없었다. "중요한"씨의 이전 눈빛의 의미를 이제야 알게되었다. "중요한"씨는 중요한 것을 확실히 알고 있었다. 그의 이름은 그에게 딱맞다고 생각하고 있었다. 그나저나 "훌륭한"씨를 어떻게 다시 설득하지? 그는 여전이 자신을 의심스러운 눈빛으로 보고 있었다. -- 박계홍

훌륭한 프로그래머의 딜레마는 다른곳에서도 많이 존재합니다. 대체로 "열심히"같은 사람은 문제의 해결을 시간을 통해서 해결하는 방안을 선호하며, "훌륭한"과 같은 사람은 문제를 다각도에서 관찰하고 고찰한후 그 모든 문제들 서로의 연관성을 파악하여 한번에 해결하는 방안을 선호합니다. 결국 문제는 시간과 노력으로도 직관으로 해결될 수 있겠지만, 전자의 경우 실패할 경우에도 일부 남는게 있는 반면 후자의 경우 실패할 경우 아무것도 남는게 없습니다. 따라서 결과가 성공이든 실패든 후자의 결과가 아주 획기적으로 관리비용을 줄여주는 등 부수적 효과가 없이 단지 문제의 해결에만 있는 것이라면 관리자는 전자의 경우를 선호하게 됩니다. --- munikang

회사에서 (언제나 그렇지만) 좀 무리한 일정으로 일이 들어옵니다.
덩어리 일에서 특히 어려운부분을 잘하는 A에게 줍니다. 자투리 일은 B에게 줍니다.
A가 고생고생해서 끝나가는데 B는 아직도 지지부진입니다. 상사는 A에게 빨리끝내고 B를 도우라고 합니다.
일이 성공적으로 끝났습니다. 상사가 A를 칭찬합니다.
A가 말합니다. 어휴, 힘들어 죽는줄 알았어요. 다음에는 좀 여유있게 하죠~
그러나 다음에도 상사는 제일 어려운 일을 A에게 주게 되지요.

소프트웨어 공학이란 수많은 "열심히"씨들만 가지고도 소프트웨어를 제작할 수 있도록 하기 위한 노하우라고 볼 수 있다. -- musiki

저희 협력업체 중에 여기서 말하는 훌륭한 프로그래머가 있습니다. 직급이 낮을 뿐 개발 능력으로 보면 그 팀 전체를 합한 것 보다 효율이 좋습니다 -_-;;.. 그런데 능력이 좋다보니 모든 일이 다 그 분에게 몰리더군요. 그냥 일만 많이 하는 거면 문제가 없는데, 일을 많이하다보니 위험에 노출될 기회도 많아집니다. 즉, 다른 사람보다 월등히 적은 버그를 만들어 내지만, 워낙 하는 일이 많다보니 결과적으로 남들보다 많은 버그를 만들어 내는 것 처럼 되어버립니다 -_-;;; ... 옆에서 보는 제가 다 안타깝더군요. -- Magicboy

see also 훌륭한경제정책가의딜레마

컴퓨터분류