ohyecloudy 때로는 코드의 주인이 누구인가에 따라서 디버깅의 방향을 달리하는 것이 도움이 되기 때문이다. 겉으로 드러내놓고 말하진 않아도 한 팀에서 일하는 사람들의 마음속에는 누구를 신뢰할 수 있고 누구를 신뢰할 수 없는지 이미 정해져 있기 마련이다. 이런 속사정 때문에 다소 수상한 냄새를 풍기는 객체라도 신뢰할 수 있는 프로그래머가 작성한 코드면 일단 무혐의 처분을 받고, 그렇게 수상하게 보이지 않아도 신뢰할 수 없는 프로그래머가 손을 댄 코드면 곧바로 구속수사를 받게 된다. 이것을 단순히 편견이라고 말하긴 어렵다. 편견이 아니라 프로그래머의 경험과 직관에 근거하는 판단의 일부라고 보아야 하기 때문이다. 2007-11-05   (0)

ohyecloudy 실수는 아픈 고통을 안겨주지만 성장하는 사람은 그것을 자신의 일부로 끌어안고 실수와 함께 나아간다. 실수 자체는 비웃을 일이 아니다. 다만 실수와 함께 성장하지 못하는 사람은 웃음거리가 될 만하다. 2007-11-05   (0)

ohyecloudy 경험이 부족하거나 담력이 약한 프로그래머는 자신의 코드에서 치명적인 실수가 발견되면 심히 당황하여 정상적인 판단능력을 상실한다. 사태를 수습하기 위해서 힘을 모으는 것이 아니라 다른 사람을 비난하거나 자기를 변호하기 위해서 힘을 낭비한다. 2007-11-04   (0)

ohyecloudy 이상한 일이지만 프로그래밍 솜씨가 뛰어난 사람일수록 자신의 코드를 믿지 못하여 반복해서 테스트를 수행하고, 프로그래밍 솜씨가 떨어지는 사람일수록 자신의 코드가 완벽하다는 순진한 믿음을 갖는다. 2007-11-04   (0)

ohyecloudy 그러나 생각해 보면 팀에 기여를 하는 사람은 예의를 갖추고 시킨 일만 하는 사람이 아니라 뻔뻔스러울 정도로 당당하게 자기주장을 내세우는 그들이었다. 그들은 항상 질문하고, 항상 실패하고, 항상 성공했다. 실패도 그들의 몫이고, 성공도 그들의 몫이었다. 2007-11-04   (0)

ohyecloudy 프로그래머로서 일하는데 있어서 중요한 것은 주어진 질문에 대한 정답을 찾는 능력이 아니라, 질문 자체를 정확하게 구성하는 힘이다. 2007-11-04   (0)

ohyecloudy 그러고 보니 유닛테스트라는 것이 폴의 말처럼 잡초를 예방하는 데이만 도움이 되는 것이 아니라 이미 솟아오른 잡초를 뿌리째 뽑아낼 때에도 도움이 되는 것이겠구나. 2007-11-04   (0)

ohyecloudy 페어프로그래밍은 항상 할 수 있는 것이 아니지만 그것이 많을수록 좋다는 생각을 가지고 있었다. 페어프로그래밍이 의미를 갖는 것은 물론 공평한 규칙이 지켜지는 것에 한해서이다. 공평한 규칙의 요소는 '실력'이 아니라 '열정'이다. 2007-11-04   (0)