-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Docs: Add temp The Psychology of Computer Programming 02
- Loading branch information
Showing
1 changed file
with
152 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,152 @@ | ||
## 2부 사회 활동으로 보는 프로그래밍 | ||
|
||
> ...(중략) 그 과정에서 나는 지시와 규율에 따른 행동과 상호 이해에 따른 행동의 차이를 점차 깨닫게 됐다. | ||
> 목표는 수많은 의지가 모여 만드는 모진 노력으로만 성취할 수 있다. | ||
> : 피터 크로포트킨 | ||
프로그래머는 혼자 일하지 않는다. | ||
|
||
1인 프로그래머와 2인 프로그래머의 차이는 단순 능률의 2배의 문제가 아니다. (3배 이상으로 늘어난다고 생각) | ||
|
||
프로그래밍 팀이란 더 나은 제품을 만들기 위해 함께 일하는 프로그래머의 모임이다. | ||
|
||
### 4장 프로그래밍 그룹 | ||
|
||
프로그래머들을 공식적인 팀 또는 프로젝트 조직화한다 해도, 그 내부에서는 비공식적인 관계들이 비구조적인 그룹에 있는 만큼이나 많이 생겨난다. | ||
|
||
사실, 우리가 사회 심리학에서 가장 먼저 배워야 할 것은 공식 그룹과 비공식 그룹의 차이점이다. | ||
|
||
#### 공식 조직과 비공식 조직 | ||
|
||
프로그래머 간의 상호관계가 조직도를 있는 그대로 따라 그 좁고 단선적인 통로를 통해서만 형성된다면 프로그래밍 작업에 진척이 있을 리 없다. | ||
|
||
트리형태가 아닌 그래프형태로 이뤄져야 한다. | ||
|
||
공식적인 구조만이 어떤 조직 내의 유일한 구조라는 생각은 위험하다. | ||
|
||
프로젝트에서 비공식 구조는 대부분 작업의 구조에 영향을 받아 결정된다. | ||
|
||
그 프로젝트가 얼마나 잘 조직화되었느에 따라 조직도에 가까운 모습이 될 수도 있다. | ||
|
||
그러나 비공식 구조는 항상 기존 공식 구조의 기능을 정정하고 보완하는 방향으로 자라난다. | ||
|
||
*현명한 상급자라면 비공식 구조를 공식화하기도 한다.* | ||
|
||
- 여비서의 사례 (긍정적) | ||
- 서비스가 필요함을 깨닫게 된 관리부가 공식적인 시스템으로 사용 (B레벨) | ||
- 종합대학 자판기의 사례 (부정적) | ||
- 자판기를 원위치 시키는 대신 조교를 늘림 | ||
|
||
위 두가지 사례의 요점은 비공식적인 조직은 항상 존재하며 그것을 깊이 이해하지 않은 상태에서 바꿔 버리면 위험하다는 것이다. | ||
|
||
그렇게 하면 원할하게 돌아가던 전체 시스템을 교란시키는 꼴이 되기 때문이다. | ||
|
||
또한 깊이 이해하지 못했으므로 그 비공식적인 조직을 비슷한 비용의 공식적인 조직으로 대체할 수도 없을 것이다. | ||
|
||
**그런 교란 가운데 많은 경우가 물리적인 배치를 변경하여 발생한다.** | ||
|
||
#### 물리적 환경과 사회적 조직 | ||
|
||
우리는 물리적 환경이 프로그래밍 작업의 양과 질에 영향을 끼침을 모두가 알고 있다. | ||
|
||
*소음이나 빛, 온도 등과 같은 요소가 아닌 작업 공간의 배치를 말한다.* | ||
|
||
프로그래머를 한군데 모아 놓으면 분명 중요한 이점이 생긴다. | ||
|
||
그러나 관심을 가져야할 부분은 작업 공간의 배치가 사회적인 상호작용에 미치는 영향이다. | ||
|
||
그 상호작용이 다시 작업 결과에 영향을 주기 때문이다. (재귀적) | ||
|
||
- 승강기 기사의 사례 | ||
- 기사와 대화를 통해 유용한 정보의 전달이 있었다. | ||
|
||
단말기 시스템의 원격에서 작업할 수 있는 측면은 어쩌면 축복이 아닌 저주일 수 있다. | ||
|
||
*1장에서 나온 내용처럼 생각하거나 정보를 나눌 기회가 줄어들고 있다.* | ||
|
||
#### 프로그램의 오류와 프로그래머의 자아 | ||
|
||
프로그래밍은 개인의 행위인 동시에 사회적 상호작용을 많이 요구한다. | ||
|
||
프로그래머는 대부분 고립된 장소에서 혼자 일하는 편을 더 선호하는 경우가 많다. (대다수) | ||
|
||
물론 프로그래밍 업무에서 상당 부분이 홀로 그리고 창조적으로 해야 하는 것이므로 그런 프로그래머를 선택하는 것이 좋다. | ||
|
||
그러나 종종 이런 고립성이 너무 지나쳐 사람들에게서 고립되고 자신의 프로그램에 애착을 두는 경우가 있다. | ||
|
||
자신이 작성한 프로그램을 자신의 것으로 여기는 데 무슨 문제가 있을까? | ||
|
||
실제 작가, 건축가, 프로그래머는 사람에게 존쟁을 받고 실력이 떨어지는 사람들은 그 작품을 모방하여 발전하곤 한다. | ||
|
||
하지만 사람들은 프로그램을 읽지 않기 때문에 어떤 프로그래머를 흠모한다고 해서 그 프로그래머의 작품을 모방하게 되지 않는다. | ||
|
||
*단지 매너리즘을 부추길 뿐이다.* | ||
|
||
**모두 어떤 화가처럼 보이는 방법은 알고 있지만, 그 화가처럼 그리는 방법을 아는 사람은 거의 없다.** | ||
|
||
누구의 것이냐를 중시하는 프로그래밍에서 나타나는 실질적인 문제점에는 또 다른 원인이 있다. | ||
|
||
어떤 그림이나 소설, 건물이 열등하다는 생각은 취향의 문제다. | ||
|
||
**그러나 어떤 프로그램이 열등하다는 생각은 적어도 잠재적으로 객관적인 증명 또는 반증이 가능하다.**(좋은 프로그램을 정의하기가 어렵다는 사실은 자치하고) | ||
|
||
최소한 우리는 프로그램을 컴퓨터에서 실행해 나오는 결과를 볼 수 있다. | ||
|
||
화가의 경우에 따라 비판을 수용하지 않을 수도 있다. 그러나 프로그래머가 컴퓨터의 판단을 무시할 수 있을까? | ||
|
||
표면상 컴퓨터의 판단은 의심할 여지가 없다. | ||
|
||
그렇다면 자기 프로그램에 대한 프로그래머의 애착은 자화상에 심각한 손상을 남길 수 있다. | ||
|
||
컴퓨터가 자신의 프로그램에 오류가 있다는 결과를 내면, 프로그래머는 이렇게 생각할 것이다. | ||
|
||
"이 프로그램에는 결함이 있어. 그런데 이 프로그램은 내 일부야. 나의 외연이란 말이지. 심지어 내 이름도 물려받았어. 그러니까 결함은 나에게 있어." | ||
|
||
**자신의 프로그램이 자아의 외연이라고 진심으로 믿는 프로그래머는 프로그램에 있는 모든 오류를 찾아내려 하지는 않을 것이다.** | ||
|
||
**오히려 그 프로그램의 정확성을 증명하려 노력할 것이다.** | ||
|
||
좋은 프로그램을 만들기 위해서는 확실한 반증이 있음에도 자신의 프로그램은 부정확하다고 믿으려는 완전히 정상적인 사람의 성향에 대해 뭔가 조치를 취해야 한다. | ||
|
||
#### 비자아적 프로그래밍 | ||
|
||
직접적인 공격이 이 문제에 대한 해결책이 될 수는 없다. | ||
|
||
공격은 언제나 방어를 부르고, 그런 방어 자세는 우리가 없애려 노력해야 할 대상이기 때문이다. | ||
|
||
자아 문제는 사회적 환경과 더불어 프로그래머들의 가치 체계를 재구성함으로 극복해야 한다. | ||
|
||
- 빌의 사례 | ||
- 남이 오류를 찾는 것은 그에 대한 개인적인 공격이 아니라 코드를 개선하기 위함이었다. | ||
- 비자아적 프로그래밍이 더 널리 실천되지 않은 이유 (그룹이 희귀하게 여겨짐) | ||
- 협업을 근간으로 방식 자체를 성공적이라는 지식 자체를 가지고 마치 그들만의 지적소유권이 있는 정보라고 생각한다. | ||
- 이런 방식으로 일하는 그룹의 구성원들은 스스로 매우 만족하며 안정감을 느끼는 경향이 있기 때문에 일자리를 옮기지 않는다. | ||
- 협업의 결과와 개인 프로그래머의 고립된 결과에 대한 질적 차이를 연구한 적이 없다. | ||
|
||
자신의 코드를 읽어야 하는 모든 사람을 위해 프로그램을 명확하고 이해하기 쉽게 만들려고 항상 노력했던 것이다. | ||
|
||
비자아적 프로그래밍 방식으로 개발된 프로그램이 그렇지 않은 프로그램보다 효율성에서 뒤쳐질 이유가 없음은 확실하다. | ||
|
||
프로그램의 전체 효율성은 원작자가 고안한 구조에 주된 영향을 받겠지만, **다른 사람의 검토를 거치면 적어도 너무 뚜렷하게 비효율적인 부분은 미리 없어지기 때문이다.** | ||
|
||
또한 다른 사람이 작성한 프로그램을 읽는 사람에게도 좋은 영향을 미친다. | ||
|
||
프로그램 읽기에 내포된 가치를 제대로 평가했다면, 비자아적 프로그래밍 방식으로 작성된 프로그램을 읽는 사람은 더 나은 프로그래머가 되지 않을 수 없다. | ||
|
||
#### 프로그래밍 환경의 조성과 유지 | ||
|
||
조성된 환경을 그냥 유지하는 것은 비교적 쉽지만, 기존 그룹을 새로운 환경으로 이끌려면 사회적 구조의 정착 또는 고착화 현상이라는 난관에 부딪힌다. | ||
|
||
*고착화는 어떤 상황이 자신을 유지하기에 더 적합한 환경을 만들어 내는 것을 말한다.* | ||
|
||
한 회사에서 프로그래밍 언어를 한 가지만 사용하는 것은 프로그래밍 환경에 관련된 사회적 고착화 현상의 전형적인 예다. | ||
|
||
사회적 환경은 비자아적 프로그래밍을 장려하거나 또는 억제하는 방향으로 조성될 수 있다. | ||
|
||
ex) 조언에 대해서 냉소적인 반응, 서로 협력하는 관계 | ||
|
||
우리가 취하는 행동에서 상당 부분은 환경적인 영향을 많이 받기 때문에 프로그래밍 그룹에 새로 합류한 사람은 그 그룹의 철학에 맞춰 사회화된다. | ||
|
||
|
||
|
||
|