[요약] 죽을 때까지 코딩하며 사는 법

요구사항을 관리하자

• 프로젝트의 복잡성은 요구사항과 개발기술의 변화에 의존한다.

• 프로젝트의 요구사항은 지속적으로 변화한다.

• 요구사항을 관리하지 않으면 기술변화에 대처할 수 없으며, 혼돈으로 가버린다.

  • 새로운 기술 도입에 있어서 '프로젝트 일정 밀리면 너가 책임 질꺼지?' 가 되어버린다.

위기에 대응하기

• 1957년대 미국 500대 기업 중 200년대에 500대 기업으로 남은 기업은 단 47개 뿐
• 위기가 찾아올 때, 그에 대비하였다면 더욱 성장하고 가치가 높아지지만, 대비하지 않았다면 몰락한다.
• 바람은 촛불을 꺼버리지만, 모닥불은 키운다.

모닥불 개발자 되기

L모드와 R모드

L모드 : 좌뇌 사용, 순차적인 사고방식, 실제 구현 시

• 코드와 마법수

  • 마법수 : 인간이 단기기억하기 쉬운 단위의 수는 4
  • if 문 중첩이든, 콜 스택이든, 클래스 상속 구현이든 동시에 봐야 하는 부분이 4단계를 넘어가면 읽기 힘든 코드가 된다.

R모드 : 우뇌 사용, 설계시

• UML을 사용하자

  • 원활한 의사소통을 위해 만들어졌지만, 의사소통은 L모드의 내용이다.

• R모드를 잘 사용하는 법

  • L모드를 끄자, R모드를 시작하기 : 샤워 등산, 조깅 등

R모드를 적극적으로 사용하는 법

• 함수형 프로그래밍

  • 논리의 순차적 전개가 어려움
  • 지역변수를 사용하지 않음

• 어떤 패러다임을 충실히 따르고, 주력 언어가 패러다임을 지원하지 않더라도 패러다임의 원리를 추구하며 코딩하자

  • C에서 구조체를 객체지향적으로 사용해보기
  • js 클래스를 클래스 지향이 아니라 객체지향으로 사용하기

• 클래스 지향과 객체지향 판별하기 : 조합보다 상속을 많이 쓴다면 클래스지향일 가능성이 높다

  • 객체란 서로 메세지를 주고 받는 생물학적 세포와 비슷해야 한다
  • 상속의 대상도 언제나 인터페이스 또는 추상 클래스여야 한다

• 변수를 최소화하기

• 코드의 세가지 기능

  • 구현한 목적에 맞게 실행
  • 유지보수 가능
  • 읽는 사람이 작성 의도를 파악할 수 있어야 함

낮선 사람 효과

• 몇 년에 한번씩 이직하기, 좋은 관계를 유지한 상황에서 네트워크의 범위를 넓힌다

  • 네트워크의 가치는 사용자 수의 제곱에 비례한다
  • 약한 연결 : 가끔 한번 연락하는 관계
  • 동호회 모임이나 컨퍼런스 등

• 적응 : 새로운 환경에 적응하는 과정에서 학습효과가 상당하다

• 낮선 것을 익히기

  책, 기사, 블로그 트윗을 읽어라. 컨퍼런스에 가라. 여러 모임에 참가하라. 스터디 그룹에 들어가라. 익숙한 영역을 벗어나 낯선 것을 익혀라. .NET 프로그래머라면 자바를 배워라. 자바 프로그래머라면 루비를 배워라. C 프로그래머라면 리스프를 배워라. 두뇌를 유연하게 만들고 싶다면 프롤로그와 포스를 배워라 - 로버트 C 마틴, <클린코더>, 58p

• 바벨 전략

  • 바벨에 바퀴 두 개가 있는 것 처럼, 두 개의 생존전략을 확보하여야 한다.
  • 백엔드라면 프론트엔드를 해보기 등
  • 인공지능도 좋을 수도
  • 나는 ETL 파이프라인도 좋을 것 같다.

독서의 중요성

• 통찰력이 없으면 안된다.

• 개인의 생각을 깊게 해주는 훈련도구이다.

• 특정 주제에 대해 다양한 저자의 책을 읽기

  • R모드에가 이렇게 쌓이는 지식 속에서 통찰을 제공한다.

• 다른 견해를 접하면서 스스로를 성장

• 새로운 아이디어 얻기 : 읽기 L모드이다가 잠깐 다른 곳 보면 R모드가 되어서 내용을 섞어서 의견을 내놓음

• 책에 메모하기를 권장 (!!)

전문가로 살기

• 스스로의 한계를 알고 그걸 제어할 방법을 알아야 한다.

• 전문적인 지식 노동자 : 자기 두뇌의 정신 에너지를 아껴 쓰는 방법 알기

  • 주커버그, 오바마 : 옷 갈아입기 귀찮

• 집중력 마나 : 엉뚱한 일 - 회의, 개인 스트레스- 등에 에너지를 쏟으면 지식 노동을 수행할 수 없다

• 집중력 마나를 효율적으로 쓰려면 몰입이 필요하다

  • 마하이 칙센트 미하이 교수의 <몰입의 기술>에서, 몰입 상태의 모델은 행동능력(기술, x축)과 행동 기회(도전, y축)이 비례로 상승하게 될 때에 몰입이 유지된다고 함
  • 어떤 도전을 통해 성취감을 느끼면서, 기술이 함께 성장할 수 있는 일을 해야 한다.

• 몰입하지 못할 경우

  • 도전 기회만 많은 경우나 기술만 많은 경우에는 불안을 느낀다
  • 기술에 비해 도전 기회만 많은 경우 근심을 하게 된다 -> 더 공부하기
  • 기술에 비해 도전 기회가 없으면 권태를 느끼게 된다 -> 더 일 만들기

• 뽀모도로 사용하기

  • 집중 시간을 1시간 30분 이상 유지하면 마나가 더 빨리 없어진다고 한다
  • 화이트 노이즈가 도움이 된다.
  • 10개 선에서 왔다갔다 조절해보고, 하루 최대 많이 할 수 있는 뽀모도로 수를 알고 있는 것도 중요

• 인터럽트 줄이기

모닥불 조직

로젠탈 효과

• 샘 라이트 스톤 <프로그래머로 사는 법>

  • 마리사 메이어의 성공 환경

    • 사고의 자유를 만끽하고 자기 의견과 생각을 자유롭게 공유할 수 있는 곳에 있기
    • 자신에게 투자해주고 도전거리를 주는 사람과 있기
    • 똑똑한 사람과 일할 수 있는 곳에 있기
    • 아직 준비되지 않은 일을 할 수 있는 곳에 있기

• 천재를 만드는 조직

  • 평범한 사람이 비범한 일을 하게 만드는 조직의 능력 == 조직을 평가하는 기준
  • 구성원이 가진 능력에 주목하고, 그 능력을 최대한 발휘하게 하기

• 로젠탈 효과

  • 누군가의 기대를 받는다는 것만으로 지능지수가 상승하는 효과
  • 조직문화 속에 기대감이 흐르고 있다면?

멘토

• 멘토가 하는 일

  • 당신에게 투자하는 사람과 당신에게 도전거리를 안겨주는 사람을 위해 일하세요. - 샘 라이트 스톤 <프로그래머로 사는 법>
  • 도전거리를 주고 학습하도록 유도 -> 몰입 상태에 머물게 해주기
  • 조언도 해주기
  • 책임을 부여하기

대중의 지혜

• 대중의 지혜의 요소

  • 의견의 다양성 : 다양한 개개인의 정보를 가질 것
  • 독립성 : 각자 독립적으로 의견을 가질 것
  • 분권화 : 개개인의 개별적 지식에 의존할 것
  • 통합의 매커니즘 : 각자 의견을 집단 결정으로 전환시키는 구조를 가질 것

• 전문가는 못보는 것이 있다. 전문가의 의견만을 취합하는 것은 아주 큰 위험을 함께 가져가는 것

• 대중의 지혜를 구축하기 위해서는 구성원 개개인에게 독립성을 보장하고 권한을 이야하는 과정이 필요

오른쪽을 보시오

• 전문가의 문제 : 자신이 무엇을 알지 못하는지를 모른다.

• 리처드 몬손 하펠, <소프트웨어 아키텍트가 알아야 할 97가지>

• 전문가들이 현실을 무시하곤 한다.

• Mangement By Objectives

  • 조직이 목표를 빠르게 처리하려면 조직 구성원에게는 적당한 여유가 필요한데, 이를 톰 드마르코는 슬랙이라 부름
  • 슬랙을 방해하는 조직내 문제점 해결: MBO를 버려라
  • 변화가 없다, 성과를 단순하게 정의할 수 있다는 두가지 가정을 기틀로 MBO가 만들어짐
  • 목표는 한달만 되어도 바귈 수 있음
  • 원래 의도는 비전이 있는 목표를 세우자였음

• 식스시그마 : 품질경영 기법

  • 원래 의도는 창의력 없애기가 아님
  • 오류율을 최소한으로 줄이기 위해 시스템을 짜내는 족쇄가 아니라, 오류율을 빌미로 시스템에 문제점을 찾아 해결하는 쪽

• 변명

  • 마이크 콘 <경험과 사례로 풀어낸 성공하는 애자일>
  • 익숙하지 않아서 안하는건데, 비효율적이라고 변명하기 - 다양한 회피 방법

• 10배 법칙 - 대중의 지혜를 조직문화에 흡수시키기

  • 10퍼센트 나은 결과는 과거의 방법을, 하지만 10배 더 나은 것은 기존 전제를 버리고 모든 것에 새로운 방식으로 접근하기
  • 당연하다고 여기던 프로세스 방식을 모두 다시 검토하기

목표에 대해서

• 간트 차트 : 공정별로 일정을 기입하고 그 일정을 연결하는 방식

  • 공정에 집중하게 만듬, 병목이 발생하는 공정이 있다고 해도 알아차리기 힘듬

  • 마이크 콘 < 불확실성과 화해하는 프로젝트 추정과 계획> 에서의 간트 차트의 문제점

    • 어떤 공정이 고객에게 어떤 가치를 제공했는지 알 수 없음
    • 계획 검토 시 어떤 기능을 빠뜨렸나가 아니라 무얼 하지 않았나가 검토 관점이 됨
    • 일정을 어기게 되면 공정을 시간 안에 맞춰야 하기 때문에 소프트웨어의 질을 포기하게 됨

  • 간트 차트 일정으로 개발팀을 관리하면 소프트웨어의 질은 떨어지고 요구사항에는 빈틈이 생김

모닥불 조직 == 애자일을 제대로 하는 조직

• <맨먼스 미신>, 폭포수 모델은 틀렸다

• 크레이그 라만, <UML과 디자인 패턴 활용> - 폭포수모델을 버리고 IID 를 표준으로 채택한 사례들

• 소프트웨어 개발 목표

  • 고객은 뭘 원하는지 말해줄 수 없다.
  • 동작하는 소프트웨어를 보기 전까지 고객은 스스로 원하는 것이 뭔지 모름
  • 애자일 선언 : 작동하는 소프트웨어로 고객과의 협력을 하며 변화에 대응하겠다

• 애자일과 제약이론

  • 정확한 목표 -> 전체 공적 그림 -> 병목구간 파악 -> 병목 해소

• 마이클 거버 <사업의 철학>

죽을 때까지 코딩하기

두 개의 마음

• 습관 만들기 -> 마음가짐

• 마음가짐

  • 고착 마인드 세트 : 성장 가능성에 한계를 정하는 것

    • 노력이나 도전에 큰 의미를 두지 않음

  • 성장 마인드 세트 : 성장 가능성에 한계를 두지 않음

    • 오늘보다 내일, 더 성장해 나갈 수 있다고 믿는 것
    • 노력과 도전이 많은 의미를 지님

  • 칙센트 미하이 <몰입>의 부제 : 미치도록 행복한 나를 만나다

• 마음가짐의 결과

  • 과정에 대한 칭찬이 필요하다
  • 결과에 대한 칭찬은 고착 마인드 셋을 가져온다

머니볼

• 개개인이 슈퍼맨이 아니라 조직이 이길 수 있도록 개개인의 능력을 살린다

• 인력이 부족한 개발팀, 기존의 방식

  • R&R을 나누고
  • R&R에 맞게 작업 분배
  • 관리자는 일정 모니터링
  • R&R에 맞게 열심히 하면 성공할 것이라 기대

• 병목구간을 찾을 수 없기에 개선의 여지가 없음

• 목표를 정하고 목표에 다라 공정을 재배열해야함

  • 목표 : 자기가 뭘 원하는지 모르는 고객이 원하는 걸 이해하고 가치를 충족하게 하는 것
  • 따라서 요구사항은 지속적으로 변화할 것이다

• 스크럼과 스프린트

  • 2주 단위의 스프린트 -> 요구사항의 변화를 막는다, 목표 고정
  • 병목구간을 찾아서 개선할 수 있다
  • 데일리 스크럼에서 '한 일', '할 일', '방해요소'를 이야기하기
  • 방해요소는 병목구간을 가리킨다

• 애자일 하지 않을 경우 역효과 - 브룩스의 법칙

  • 간트차트와 R&R을 보면서 플젝 -> 인력 부족 -> 일정 밀림 -> 인력 추가 -> 일정 밀림
  • 이유 : 인력 투입 시 적응 시간 필요, 기존 개발자의 도움 필요, 커뮤니케이션 비용 증가

• 프로세스 개선의 외적인 방법 : 프로그램 제대로 만들기

  • 제대로된 소프트웨어를 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다 - 로버트 C 마틴, <클린 아키텍쳐>

새로운 미래가 온다

• 비전의 역할

  • 라이트 형제와 랭리의 비교

    • 지원과 학위와 인맥이 막강한 랭리보다 자전거 수리공 라이트 형제가 먼저 비행기 발명
    • 비전의 차이 : 라이트형제는 비행기를 발명하면 세계 역사의 흐름을 바꿀 수 있다고 생각, 랭리는 단순히 돈벌려고

  • 비전이 변연계에 심어진다

• 비전이 없는 조직

  • 자기에게 이익이 되지 않는 일은 하려하지 않음
  • 비전이나 열정을 가진 사람은 소외됨
  • 일을 시키기 위해 R&R과 간트차트 사용
  • 진화가 어려워짐

• 죽을때까지 코딩하기

  • 프로덕트에 대해 '왜'를 설명할 수 있는 기업

  • 자기계발의 습관을 가지기

    • L모드에서 R모드로
    • 순차적 논리 전개는 빈틈이 만흥니 공간적, 직관적, 총체적 방식으로 코딩하기
    • TDD를 사용하고 소프트웨어 개발 패러다임을 공부하고 익히기
    • 애자일에 익숙하기

  • 창조와 공감이 필요한 소프트웨어 - 자기가 뭘 원하는지 모르는 고객들이 뭘 원하는지 알게 만들기

  • 성장 마인트 셋 가지기

레퍼런스 책 중 읽어볼 책

• 구글의 아침은 자유가 시작된다, 라즐로 복
• 생각하지 않는 사람들, 니콜라스 카
• 클린 시리즈, 로버트 C 마틴
• 실용주의 프로그래머, 앤디 헌트
• 맨먼스 미신, 프레더릭 브룩스
• 경영의 실제, 피터 드러커
• 객체지향의 사실과 오해, 조영호
• 고객과 함께 하는 도메인 특화 언어 DSL, 마틴 파울러
• 구글의 미래, 토마스 슐츠
• 나는 왜 이 일을 하는가?, 사이먼 사이넥
• 리스크, 피터 L. 번스타인
• 린 소프트웨어 개발, 톰 포피딕
• 린스타트업, 에릭 리스
• 모든 기획자와 프리젠터가 알아야 할 사람에 대한 100가지 사실, 홍윤주,
• 몰입, 미하이 칙센트미하이
• 미래를 만든 Geeks, 엔디 허츠펠드
• 불확실성과 화해하는 프로젝트 추정과 계획, 마이크 콘
• 블랙스완, 나심 니콜라스 탈레브
• 사업의 철학, 마이클 거버
• 소프트 스킬, 존 소메즈
• 소프트웨어 아키텍트가 알아야 할 97가지, 리처드 몬손헤펠
• 소프트웨어 공학의 사실과 오해, 로버트 글래스
• 스위치, 칩 히스, 댄 히스
• 슬랙, 톰 드마르코
• 실용주의 사고와 학습, 앤디 헌트
• UML과 패턴의 적용, 크레이그 라만
• CODE COMPLETE, 스티브 맥코넬
• 테스트 주도 개발로 배우는 객체 지향 설계와 실천
• 프로그래머로 사는 법, 샘 라이트스톤,
• 프로그래머의 길 멘토에게 묻다, 에디웨일 오시나이, 데이브 후버
• 피플웨어, 톰 드마르코, 디모시 리스터
• 코딩 호러가 들려주는 진짜 소프트웨어 이야기, 제프 앳우드