1. 실용주의 철학

Item 1. 고양이가 내 소스코드를 삼켰어요

가장 큰 약점은 약점을 보일 것에 대한 두려움입니다.

책임지기

• 책임은 적극적으로 동의하는 것.
• 다른 사람의 문제가 있더라도 그에 따른 대책을 제공해야합니다.(contingency plan)

Tip 3. 어설픈 변명을 만들지 말고 대안을 제시합니다.

• 변명 대신에 대안을 제시합니다.
  • 프로토타입, 포스트잇, 리팩터링, 테스트 코드, 유비쿼터스 자동화 등을 만듭니다.

Q. 은행원이나 자동차 수리공, 혹은 점원이 여러분 앞에서 어설픈 변명을 늘어놓는다면 어떻게 반응하겠는가? 그들에 대해서, 그리고 결과적으로 그 회사에 대해 어떤 생각을 갖게 되는가?

• 신뢰의 하락, 그로 인한 프로젝트 결과물의 투자비용 증가, 회사에 대한 애사심이 사라지게 됨.

Item 2. 소프트웨어 엔트로피

• 소프트웨어의 부패 : 소프트웨어의 무질서도가 증가하는 경우, 깨진 창문 이론에 따라 갑니다.

Tip 4. 깨진 창문을 내버려두지 말아라.

• 소프트웨어가 깨끗하다면 엉망이 되지 않도록 노력할 확률이 높습니다.

Q. '깨진 창문' 두세 개를 고른 다음, 여러분의 동료들과 함께 무엇이 문제고, 그걸 고치기 위해서 뭘 할수 있는가?

• 시간을 투자해서 고치는 방법.
• 고칠 곳은 많다... 시간과 우선순위 부족으로 인한 문제가 많을 뿐.

Q. 언제 창문이 처음 깨졌는지 말할 수 있는가? 여러분의 반응은 무엇인가? 그것이 다른 사람의결정 혹은 경영진의 명령인 경우에는?

• 누구를 원망할 문제는 아니라고 생각
• 어떤 식으로 문제를 해결할지에 대해 이야기하는 것이 좋다고 생각합니다.

Item 3. 돌멩이 수프와 소프트웨어

• 큰 무리 없이 요구할 수 있을 만한 것을 찾아내고 그것을잘 개발합니다.

Tip 5. 변화의 촉매가 되어라.

• 의욕과 팀 자체의 파괴는 종종 작은 것의 누락에서 옵니다.

Tip 6. 큰 그림을 기억하라.

Q. 개구리를 점진적으로 속이는 경우 나쁜 일이 생깁니다. 변화를 촉진시키는 과정에서 이 방향이 옳은지 어떻게 결정할래?

• 이 부분이 왜 개발자가 공부를 계속해야하고, 방향을 잘 읽어야하는 지를 알아야 하는 원인이라고 생각
• 이슈를 공유하고 변화의 방향을 협의하여 좋은 방향을 갈 수 있도록 이야기를 해야합니다.
• 다 같이 변화의 방향을 인지하고 필요성을 느끼면 결국 변화할 수 있는 것 같습니다.

Item 4. 적당한 괜찮은 소프트웨어

우리는 종종 뭔가 나아지게 하려다가 괜찮은 것마저 망칩니다.

• 현실에서 완벽한 것을 만드는 것은 불가능에 가깝습니다. 그렇게에 적당히 괜찮은(요구사항은 다 만족) 소프트웨어를 만드는 것이 방법입니다.

타협과정에 사용자를 참여시켜라

• 시스템의 범위(scope)와 품질은 해당 시스템 요구사항의 일부로 명기되어야합니다.
• 빠른 솔루션의 결과가 피드백을 참고해 더 좋은 결과를 만들 수 있는 경우가 많습니다.

Tip 7. 품질을 요구사항으로 만들어라,

언제 멈춰야할지 알라

• 언제 멈출지를 모르면 그림 그리는 것을 망치는 것처럼 개발도 똑같습니다.

Q. 사용자로 (1) 그들이 모든 버그를 제거할 때, (2) 복잡한 소프트웨어를 사용하면서 어느 정도 버그를 감당할지, (3) 결함이 더 적은 간단한 소프트웨어를 선정할지.

• 사실 사용자 입장에서는 버그가 없는 것이 무조건 좋다고 생각합니다.
• 다만, 버그가 없을 수는 없기 때문에 좀 더 빨리 소통이 잘되고, 문제가 적은 소프트웨어를 고를 것 같습니다.

Item 5. 지식 포트폴리오

지식에 대한 투자가 언제나 이윤을 냅니다.

지식가치가 떨어지면 회사나 클라이언트에 대한 자신의 가치에 떨어집니다.

이는 금융의 포트폴리오와 같습니다.

• 주기적인 투자 : 지식 포트폴리오에 주기적으로 투자합니다.
• 다각화 : 여러가지를 알면 알수록 자신의 가치가 높아집니다.
• 리스크 관리 : 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것에 이르기까지 여러가지 기술이 있습니다.
• 싸게 사서 비싸게 팔기 : 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 것은 저평가된 주식을 찾아내는 것처럼 어려우나 이익도 큽니다.
• 검토 및 재조정 : 산업은 매우 동적이며, 유행이 바뀔 수 있기에 검토와 재조정이 필요합니다.

Tip 8. 지식 포트폴리오에 주기적으로 투자하라.

목표

다음의 목표를 진행하는 것도 좋습니다.

• 매년 새로운 언어를 최소 하나는 배워라
  • 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 것을 예방하는 데 도움이 됩니다.
• 기술 서적을 분기별로 한 권씩 읽어라
  • 습관이 들면 한달에 한권씩 읽기
  • 사용하는 기술을 완벽히 익힌 후는 다른 관련 없는 분야까지 공부하는 것이 좋습니다.
• 비 기술 서적도 읽어라
  • 컴퓨터를 사용하는 것은 인간입니다.
• 수업을 들어라
  • 흥미로운 강좌를 듣는 것도 좋습니다.
• 지역 사용자 모임에 참여하라
  • 고립은 경력에서 치명적일 수 있습니다.
• 다른 환경에서 실험해보라
  • 윈도우, 리눅스, 맥...
• 요즘의 흐름을 놓치지 마라
  • 여러 잡지와 저널을 구독하는 것도 좋습니다.
• 인터넷을 이용해라

학습의 이해

• 답을 찾기위해 계속 도전해라.
• 물어보고 싶은 것을 정확히 알고 가능하면 구체적으로 합니다.
• 질문은 구체적으로 쓰며 답이 있는지 찾습니다.
• 공개적이거나 개인적으로 질문할지 확인합니다.
• 물러서서 인내를 가지고 기다립니다.

비판적 사고

자신의 포트폴리오에 있는 지식이 정확하고, 벤더나 매체의 과대광고에 흔들림이 없도록 확실히 해야합니다.

Tip 9. 읽고 듣는 것을 비판적으로 분석합니다.

Q. 이번 주부터 새로운 언어를 배우기 시작해라

• 개인적으로 리액트 혹은 코틀린

Q. 새 책을 하나 읽기 시작해라

• 데이터 중심 애플리케이션 설계

Q. 밖으로 나와서 현재 프로젝트에 관여하지 않는 사람들 혹은 자신과 다른 회사의 사람과 이야기, 외부에서 열정적인 사람을 찾아 보자.

• 스터디 2개 중

Item 6. 소통하라

유용한 아이디어는 다음과 같습니다.

• 말하고 싶은 게 무엇인지 알아라
  • 무엇을 말할지 미리 계획하고, 개요를 작성하고, 자문하는 과정을 끝없이 다듬습니다.
• 청중으로 알아라
  • 청중에 대한 뚜렷한 그림이 필요합니다.
  • WIDSOM(What(무엇), interest(관심), sophisticated(소양), detail(구체적), owe(소유), motive(동기))
• 때를 골라라
  • 가장 좋은 타이밍에 요청을 합니다.
• 스타일을 골라라
  • 전달하는 스타일을 청중에 맞게 조정합니다.
  • 피드백 역시 의사소통의 한 가지 형태입니다.
• 멋져 보이게 하라
  • 아이디어를 표현하는 것은 중요한 매개체입니다.
• 청중을 참여시켜라
  • 문서 초고에 독자가 참여하도록 합니다.
• 청자(listener)가 되어라
  • 다른 사람들의 말을 경청하는 것이 필요합니다.
• 응답하라
  • 질문을 받았으면 반드시 응답해라

Tip 10. 무엇을 말하는가와 어떻게 말하는가 모두 중요합니다.

Q. 개발 팀 내의 의사소통에 관한 훌륭한 책을 꼭 봐라

• 분석과 설계 : Object, Design Pattern, Analysis Patterns
• 팀과 프로젝트 : The Mythical man Month, Dynamics of Software Development, Surviving Object-Oriented Projects: A Manager's Guide
• 특정 환경 : Unix, Windows, C++, Nutshell 시리즈
• 웹 : Slashdot, Cetus Links, WikiWikiWeb
• 다른 책 볼게 많음...

Q. 다음 프로젝트 작업시 WISDOM 과정대로 진행하기