제럴드 와인버그 <프로그래밍 심리학> 8장-10장 요약

8장 개인의 성격

p. 277

비자아적 프로그래밍에서는 항상 자신의 성격에 최고로 잘 맞는 업무에만 투입될 가능성이 없다. 안정성을 위해 잠재적인 능률을 희생하는 셈이다. 그러나 잠재된 능률을 모두 잃는 것은 아니다. 처음부터 아무렇게나 배치하지는 않기 때문이다. 그리고 다른 사람의 신발을 신어 보는 것은 참을성을 기르는 좋은 방법이다. 

프로그래밍 업무는 매우 다양하기 때문에, 잦은 변화에 잘 적응하지 못하는 성격은 직업 프로그래머에 적합하지 않다. ​프로그래머는 하던 일이 중단되거나 외부 요인으로 인해 기존의 작업이 쓰레기가 되는 정신적 충격이 없는 평화로운 나날을 채 한 달도 보내기 어렵다. ​ 

프로그래밍에 꼭 필요항 성격에는 겸손함도 있다. 프로그래머가 몇 가지 간단한 기술을 익히고 스스로 전문가라고 자만하다가 컴퓨터 앞에서 박살나는 이야기는 소포클래스가 쓴 비극에 못지않게 눈물겹다. 

p. 128 

겸손함과 동전의 양면처럼 대를 이루는 성격이 자신감이다. 프로그래머의 업무는 뭔가를 되게 만드는 것이라 할 수 있다. 그 과정에서 때때로 장애물을 만나면 그것를 피하거나 넘거나 타파해야 한다. 그러나 겸손함이 지나쳐 자기비하를 쉽게 하는 사람은 자싱이 택한 방법이 틀릴 수도 있다는 비판 정신을 지나치게 발휘해 자신감을 상실한다. 

9장. 지능 또는 문제해결력

p. 304

객관적인 척도가 부족하기 때문에 프로그램 난이도를 판단할 때 담당 프로그래머가 얼마나 열심히 하느냐를 기준으로 삼곤 한다. 그 기준에 따르면 능력이 가장 떨어지는 프로그래머가 최고가 된다. 능력이 떨어지면 열심히 일하는 수 밖에 없기 때문이다.

한 신생 회사에서 한 프로그래머가 하루에 14시간씩 일주일에 6일을 근무해 가며 8주 만에 작은 프로그램을 하나 완성했고, 그는 보상으로 특별 승진을 했다. 나중에 다른 프로그래머가 그 프로그램에 기능을 추가하는 업무를 맡았는데, 코드를 보니 너무 엉망이라 이해하고 수정하느니 차라리 처음부터 다시 만드는 편이 낫겠다고 판단했다.

프로그램을 처음부터 다시 만들고 디버깅을 완료하는 데까지 걸린 시간은 정확이 일주일이었다. 초과근무를 하지 않고도 말이다. 프로그램을 처음 만들 때보다 두 번째 만들 때가 더 쉽다고는 하지만 차이가 너무 컸다. 게다가 새로 만든 프로그램이 이전보다 8배나 빨랐고 용량은 잔이었으며 코드 줄 수도 절반이었다. 예전의 그 프로그래머는 일을 엉망으로 하고도 상을 받은 것이다. 상이 그런 식으로 엉뚱한 사람에게 돌아갔음이 밝혀지자 그 곳에서 일하는 프로그래머들의 사기가 크게 떨어졌다.

p. 305

문제의 일부 요소를 간과하는 것은 잘못된 가정를 하는 경우에 해당한다. 즉 어떤 요소가 중요하지 않은 요소를 중요하다고 가정하는 것도 문제 해결을 어렵게 만들기는 마찬가지다. 다른 사람이 작성한 프로그램을 많이 디버깅해 본 사람은 그 문제에 대한 원작자의 설명을 새겨듣지 말아야 함을 안다. 

가정을 전혀 하지 않기보다는 주어진 문제에 맞춰 적절히 가정하는 편이 더 지능적인 편이다. 여러 공식을 갖춰 놓고 특정 공식에만 집착하지 않는 쪽이 지능적인 행위다. 

p.317
프로그래머에게는, 특히 디버깅할 때에는, 일상적이지 않은 패턴을 찾아내는 능력이 필요하다.

p.327
프로그래밍의 성공에 영향을 주는 요소는 지능 외에도 많다. 나는 지능은 좀 떨어지는 것처럼 보이는데 훌륭하고 유용한 코드를 지속적으로 만들어 내는 사람들을 꽤 보아 왔다. 

나는 지능보다는 성격이나 업무 습관, 훈련이 더 관련 있다고 믿는다. 그런 것들은 지능과 다르게 삶의 경험을 통해 바뀔 수 있다. 그렇다면 문제는 어떤 사람을 프로그래머로 뽑느냐가 아니라 어떻게 프로그래머를 양성할 것인가로 바뀐다.


​​10장. 동기 부여와 훈련, 경험

p. 330

동기 부여는 훈련과 교육에 많은 영향을 미친다. 동기 부여가 되지 않은 사람을 가르치기가 얼마나 힘들지 상상해 보라. 반대로 스스로 동기가 있는 사람이라면 배우는 것을 막을 도리가 없을지도 모른다.

p. 337

프로그래밍 정규 과정을 거치지 않고, 다양한 이력을 가지고 있는 사람들로 구성된 팀이 성공하는 경우를 종종 볼 수 있다.

이러한 팀들이 존재할 수 있었던 중요 요인은 언제나 같다. 바로 헌신적인 리더 밑에서 실질적인 프로젝트를 위해 수년 동안 함께 일해 온 것이다. 그리고 이 시간은 일반적이거나 일상적이지 않은 훈련과 경험을 의미한다. 이 과정에 녹아 있는 정수를 파악할 수 있다면 동일한 성취를 이룰 수 있을 것이다.

p.343

너무 특수해서 확장성이 전혀 없는 기술은 끝이 막힌 ( dead-end ) 기술이라 할 수 있다.

프로그래밍에서 일정 규모의 문제들을 성공적으로 해결해 왔지만 그 규모를 넘어서는 문제는 제대로 해결하지 못하는 프로그래머를 심심치 않게 볼 수 있다. 그리고 그 반대의 경우도 꽤 있다.

​어떤 끝이 막힌 기술 또는 프로그래밍 언어에 숙달된 프로그래머가 새로운 기술을 배우려면 잠시나마 현재 맛보는 만족감 중 일부를 버릴 각오를 해야 한다. 새 기술을 배우는 초기에는 실행착오가 많을 테고, 그럴 때마다 마치 예전의 초보자 시절로 돌아가는 듯한 느낌을 받을 것이다.

​새로운 것에 대한 두려움과 실패에 대한 걱정, 자신의 약점을 인정하고 싶지 않은 마음은 모두 학습에 악영향을 미친다.

p. 347
스스로 발전하려는 프로그래머는 정식 훈련과 필요한 교육을 받을 수 있도록 지원해두는 관리자의 배려에 의존하지 않을 수 없다. 순수하게 경험에 의존하면 안 되는데, 경험한다고 반드시 뭔가를 배우는 것은 아니기 때문이다. 프로그래머가 자신이 경험한 것을 배움으로 발전시키려면, 학습하는 방법을 배워야 한다.

p. 351
학습은 능동적인 추구다. 프로그래밍을 학습할 때 능동적으로 배움을 추구해야 하는 경우가 두 가지 있다. 프로그램이 정확하게 동작할 때와 그렇지 않을 때다.
프로그램이 정확하게 동작할 때에는 3보 정도 뒤로 물러서서 달성한 성과를 전체적으로 관조해야 한다. 다른 비슷한 프로그램에서는 좀 더 문제가 많았는데 이 프로그램은 왜 성공했을까? 왜 전에는 그렇게 문제가 많았을까? 처음부터 다시 시작한다면 이 프로그램을 좀 더 효율적으로 작성하거나 더 나은 문서를 도출할 수 있을까? 만약 그렇다면, 지금 당장 실행할 수 있는 일은 무엇일까? 

프로그램이 동작하는 것이 업무가 끝났음을 의미하지 않음에도, 빨리 결과를 내라는 관리자의 압력 때문에 위와 같은 고민을 하지 못하는 일이 자주 일어난다. 그러나 프로그램으로부터 뭔가를 배우려는 프로그래머라면 그런 압력에 굴복하지 말고 자신의 성과를 되돌아볼 시간을 접해야 한다. 관리자도 프로젝트가 끝났을 때 프로그래머에게 하루쯤 휴가를 주는 것이 좋다. 그리고 이것은 보상의 의미가 아니라 프로그래머에게 프로젝트의 결과를 평가할 기회를 주는 것이다.

프로그램이 정확하게 동작하지 않으면 더 많은 것을 배울 기회가 생긴다. 그러나 결과를 내는 게 급선무라는 압박감 때문에 프로그래머는 가저 동작만 하도옥 봉합하는 선에서 문제를 마무리하고 싶은 유혹을 받는다. 결국 새로 배워야하는 기술은 사용하지 않게 된다. 이렇게 문제를 해결하면 제대로 배울 수 있는 황금 같은 기회를 놓치는 것이다. ​뭔가 필요한 시기 만큼 배움에 적합한 시기는 없다.

그러나 현실적으로는 문제가 있다. 필요한 모든 기술을 익힌 후에만 프로젝트가 시작되는 것도 아니고, 관리자는 새로운 기술을 적용했을 때 아무리 좋은 결과가 예상될지라도 눈앞의 일정이 지연되는 것을 용납하지못한다. 이렇게 모순적인 상황에서 프로그래머는 어떻게 해야할까?
새로운 기술을 적용해 보고, 실패하면 그 이유를 조사하는 데 어느 정도의 시간을 쓰고, 만약 성과가 없다면 기존의 기술로 대체하여 문제를 일단 무마한다. 대신 나중에 재시도할 수 있도록 테스트 케이스를 만들어 놓는다.