코딩호러의 이펙티브 프로그래밍

“위대한 프로그래머는 다른사람을 설득함으로써 영향력을 확대한다. 명확한 설명과 기술적인 스펙을 통해 그들은 다른 프로그래머들이 새로운 코드를 작성하는 대신 자기가 작성한 코드를 사용할 수 있게 만든다.”

공동창시자 조엘 스폴스키

의사 소통의 능력은 중요하고 어렵다. 특히 글로 하는 의사소통은 더욱 그렇다. 글쓰는 능력을 키우려면 블로그를 해라. 마치 꾸준히 하는 운동처럼

모두가 아주 많이 글을 써야 한다. 블로그든, 책이든, 스택 오버플로우의 답글이든, 이메일이든 상관없다. 글을 쓰고, 그 글에 대해 잠시 생각을 하는 것이다. 글을 명확하게 하는 것은 자신의 내면적 사고의 흐름을 명확하게 하는데 도움을 준다. 어떤것을 다른 사람에게 정확하게 설명하고자 노력해 보면, 자기가 얼마나 많은 부분을 제대로 모르고 있었나 하는 것을 깨달으며 놀라게 된다. 바로 그 지점에서 완전히 새로운 발견이 시작되는 것이다.

매일 아침 당신은 참을 수 없는 열정과 함께 잠에서 깨어나야 한다. 만약 그렇지 않다면 당신은 그저 일을 하고 있는 것뿐이다.

다니엘 핑크의 동기부여 과학 = 당근과 채찍이라는 인센티브 제도는 사람이 반복적이고 기계적인 일을 할 때 의미가 있다는 연구결과 어떤 문제에 대한 명확한 해답이나 규칙이 없기 때문에 창의적인 문제 해결능력을 요구하는 경우에는 인센티브가 제대로 동작하지 않을뿐더러 오히려 상확을 악화 시킴.

“배를 만들고 싶다면 인부들을 재촉해서 나무를 끌어모으고 일을 분할해서 명령을 내릴 것이 아니라 그들이 저 넓고 끝없는 바다를 열망하게 만들어라”

앙투안 드 생텍쥐페리

어떤 능력을 얻는 최선의 방법은 그걸을 최대한 반복, 연습하는 것 하지만 코딩을 하는데 너무 바빠서 토론, 복습, 학습 등을 할 시간이 없다면 앞으로 나아가지 않는 것. 기술을 연마하는것과 기술을 활용하는 방식에 대해 사색하는 것 사이에서 균형을 잡아야 한다.

프로그래밍 블로그 읽기(Hacker News, Programming Reddit..)

물론 지나치게 톱날을 벼리거나, 혹은 아무 목적없이 무작정 톱날을 벼리는것은 또 다른 형태의 게으름에 해당할지도 모름. 하지만 이런 학습에 무관심 하다면 문제가 있다. 톱날을 벼리기 위해 약간 집착을 보이는 것. 이것이 프로그래밍에 대한 글을 쓰거나 논의 하는것 이라면 아무 문제 없다.

BBC 연구 결과에 의하면 그저 이메일이나 메신저가 우리를 방해하도록 내버려두는 것조차 업무에 지대한 영향을 미침

이메일이나 전화에 의해 방해를 받는 사람들의 IQ는 10 포인트 정도 하락. 마리화나를 피우는 것이 두뇌에 끼치는 영향에 두배 이상

특히 프로그래머는 업무 전환에 비용이 큼. 프로그래밍이라는 작업은 머리에 상당히 많은 정보를 넣고 수행하는 작업임. 머리에 변수의 이름, 데이터 구조, 중요 API, 함수 이름, 소스코드를 저장. 더 많은것을 기억할수록 생산성이 높아짐.

우리는 우리가 할 수 있는일을 과대평가하는 경향이 있다. 할 수 만 있다면 업무의 흐름이 끊기는 상황이나 여러 개의 프로젝트를 동시에 다뤄야 하는 상황을 피하는 것이 좋다.

겸손한 프로그래머가 되는 방법의 핵심은 어떤 상황에 처하더라도 결국 모든 잘못의 뿌리는 자기가 작성한 코드라는 사실을 인정하는것

코드의 소유권은 곧 코드에 책임을 지는것. 이것은 내가 작성했든, 아니든 일단 문제가 자기 코드에 있다고 간주하고 그에 합당한 조치를 취하는 태도를 의미. 그래야 존경과 신뢰를 얻을 수 있다.

1973년 1984년에 수행된 연구에서 에러의 대략 95%는 프로그래머들이 작성한 코드 때문에 나오고, 2%(컴파일러, 운영체제)시스템 소프트웨어에서 나옴. 1%가 하드웨어. 오늘날은 더 많을 듯.

에러와 버그를 계속 다른 사람, 다른 회사, 다른 소스에 전가하는 방식으로는 존경과 신뢰를 얻지 못한다. 문제가 나의것이 아니라도 그 문제를 파악하고 진단하는 기술을 익혀야 할뿐더러 자신의 주장을 위한 증거도 수집해야함.

문제의 해결책을 자기 중심에서 해결 하려는것은 신뢰와 존경을 얻는 빠른길.

너무 많은 코드를 작성하는 우리의 자연스러운 내적 경향을 억제.

물리적인 분량을 줄이기 위해 온갖 기법들을 동원하라는 의미는 아님. 프로그래머 개인이 읽고 이해해야 하는 프로그램 코드의 분량을 최소하 하라는 뜻. (복잡도를 올릴 수록 이해야하는 부분은 더 늘어날 수 있음)

당신이 새로운 코드를 한 줄 작성할 때마다 누군가는 디버깅, 누군가는 읽고 이해해야 하며, 유지보수 해야 한다.

당신이나 팀이 애플리케이션의 모든구석, 사소한 부분까지 자세하게 알고 있는것은 개발팀을 얼마나 훌륭하게 구성하는가에 달림.

아이디어만 있는것은 텅빈껍질. 성공은 아이디어의 질이 아닌 실행의 질에 의해 결정됨.

“그저 그런 그룹에게 좋은 아이디어를 제공하면 그들은 아이디어를 망쳐버릴 것이다. 하지만 훌륭한 그룹에게 그저 그런 아이디어를 제공하면 그들은 아이디어를 멋진 무엇으로 구현할 것이다. 혹은 그저 그런 아이디어를 밖으로 내던지고 뭔가 다른 것은 만들어 낼 것이다.”

좋은 팀을 잘가꾸고 만들자.

너무나 많은 회의. 불필요한 회의는 중요한 일들이 죽음을 맞이하러 가는 장소.

어떤 회의라도 한 시간을 넘으면 사형. 시간은 중요한 회사의 자산

회의를 한시간 내에 마칠 수 없다면 그 자리에서 수정. 이런일이 발생하는것은 회의를 다루는 범위가 너무 넓거나, 많은 사람이 관련되어 있거나, 회의의 초점을 유지시킬만한 동력이 부족.

모든 회의에는 명확하게 정의된 목표가 있어야 한다. 회의의 목표가 모두에게 명확하게 전달되게 하는것이 중요. 하나의 간결한 문장으로 요약 가능해야됨.

회의에 참석하기 전에 회의에서 필요한 일을 하라. 회의에 참석 하기전에 어떤 말을 해야 하는지, 어떤 정보를 공유 해야 하는지 준비를 완전히 끝마쳐야 한다. 해야 할 준비가 돼 있지 않은 사람은 회의에 참석하지 말아야 한다.