Topic 1 - 당신의 인생이다
변화를 피하지 말고 불만이 있는 것이 있으면 고치기 위해 노력하라
- 업무환경, 적성이 안맞으면 바꾸되, 너무 오래 노력하지는 말기
- 뒤쳐지는 기분이 들면 여가 시간에 공부하기
기회는 많고 적극적으로 행동해 그 기회를 잡아라
Topic 2 - 고양이가 내 소스 코드를 삼켰어요
실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다. 아무리 잘해도 발생하는 문제는 있고, 이를 정직하고 솔직하게 인정하고, 처리하려고 노력해야한다.
팀 내 신뢰 팀이 나를 믿고 의지할 수 있어야하고, 나도 팀을 의지할 수 있어야한다. 신뢰를 바탕에 둔 환경에서는 안전하게 아이디어를 교류할 수 있다.
책임지기 책임을 지지 않을 권리는 있지만, 지기로 결정했다면 결과를 감당해야한다.
어설픈 변명 말고 대안을 제시하라.
- 나쁜 소식을 전하기 전에 시도해볼만한 것은 없는지.
- 해결을 위해 필요한 것이 있고, 그 이유를 설명할 수 있을지
- “잘 모르겠어요” 다음에는 “알아보겠습니다”
Topic 3 - 소프트웨어 엔트로피
소프트웨어의 무질서도가 증가하면 이를 ‘소프트웨어의 부패’ (기술 부채)라고 부른다.
깨진 창문을 내버려두지 마라
- 나쁜 설계, 잘못된 코드 등이 모두 깨진 창문이다.
- 고칠 시간이 없다면, 주석처리 / Not implemented 등의 메시지를 표시하여 상황을 관리하고 있음을 보여줘라
방치는 다른 어떤 요인보다 부패를 가속화시킨다. 만약 고칠 시간이 없다면 아예 버리거나 새롭게 대체하라
우선 망가트리지 말라 상황을 냉정하게 평가하여 어떤 위기가 왔다고 필요이상의 피해를 주지마라. (= 깨진 창문을 더 만들지 말라)
Topic 4 - 돌멩이 수프와 삶은 개구리
변화의 촉매가 되라
- 어떤 시스템을 개발하려고할 때
시작 피로에 빠지기 쉽다. 이때는 개발에 필요한 자원을 얻기 위해 사람들을 설득하는 것은 쉽지 않다. - 하지만 작은 것을 잘 개발하여 사람들에게 보여주고, 사람들로 하여금 조금씩 추가해달라고 할때까지 기다려라
- 계속되는 성공에 합류하기는 쉽고, 미래를 살짝이라도 보여주면 사람들은 도와주기 위해 모여들 것이다
큰 그림을 기억하라
- 소프트웨어 참사는 대부분 작은 문제들이 쌓이다가 어느날 갑자기 폭주한다.
- 큰 그림에 늘 주의를 기울여 참사가 발생하지 않도록 하자.
- 당장의 일에만 정신을 쏟지말고 주변에서 벌어지는 일을 살펴보라
Topic 5 - 적당히 괜찮은 소프트웨어
너무 완벽한 소프트웨어를 만들려하지말고, 적당히 괜찮게 만드는 것이 중요하다. 하지만 이때 적당히 괜찮은은 기본적인 성능, 보안, 요구조건을 만족해야한다.
타협과정에 사용자를 참여시켜라 소프트웨어가 얼마나 좋아야하는지 사용자에게 물어라. 좋은 소프트웨어를 위해 요구조건을 무시하거나, 요구조건을 위해 기본적인 것을 빼는 것 모두 전문가답지 못하다.
품질을 요구사항으로 만들어라.
우리는 적당한 타협이 필요한 상황에 자주 처한다. 사용자는 완벽한 내일의 소프트웨어보다 적당한 오늘의 소프트웨어를 원한다. 사용자에게 직접 만질 수 있는 기회를 주면 피드백을 통해 더 나은 해결책에 도달할 수 있다.
멈춰야할 때를 알라 완벽하게 훌륭한 프로그램을 만드느라 망치지마라.
‘기능 블로트’ 소프트웨어가 실제로 사용되는 기능에 비패 훨씬 더 많은 기능을 가지고 있고, 그만큼 버그나 보안 취약점이 생길 가능성이 높은 것을 말함
Topic 6 - 지식 포트폴리오
새로운 것을 배우는 능력은 가장 중요한 전략 자산이다. 그런데 배우는 방법은 어떻게 배워야하고, 무엇을 어떻게 배워야할까?
지식 포트폴리오
- 주기적인 투자
- 소량으로라도 주기적으로 지식 포트폴리오에 투자해야한다.
- 습관 자체가 중요하며, 방해받지 않을 수 있는 시간과 장소를 정기적으로 이용할 계획을 마련하라
- 다각화
- 기본적으로 현재 작업에 사용하는 기술에 관해서는 속속들이 알아야한다.
- 추가적으로 더 많은 기술에 익숙하다면 변화에 더 잘 적응할 수 있다.
- 기술 외의 분야도 잊지말라
- . 리스크 관리
- 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것 모두 적절히 담아라
- 싸게 사서 비싸게 팔기
- 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하면 보상도 크다.
- 검토 및 재조정
- 소프트웨어 업계는 매우 동적이기에 주기적으로 어떤 걸 배워야할지 검토하여 재조정하라
목표
- 매년 새로운 언어를 최소 하나는 배워라
- 기술 서적을 한달에 한 권씩 읽어라
- 현재 프로젝트와 관련이 있는 흥미로운 주제의 기술 서적을 읽어라
- 현재 사용하는 기술을 일단 완전히 익혔다면, 가지를 쳐서 다른 분야까지 공부 범위를 넓혀라
- 기술 서적이 아닌 책도 읽어라
- 수업을 들어라
- 지역 사용자 단체나 모임에 참여하라
- 회사 밖에서 사람들이 어떤 일을 하는지 알아보라
- 다른 환경에서 실험해보라
- 윈도우에서만 일했다면 리눅스도 사용해봐라.
- IDE에서만 작업했다면 makefile/텍스트 에디터로 작업해봐라
- 요즘 흐름을 놓치지 마라
- 현재 사용하는 것과는 다른 기술을 다루는 뉴스와 게시물을 읽어라.
한 기술에 익숙해지면 다음으로 나아가라. 직접 사용할일은 없어도, 학습과정에서 사고가 확장될 것이다.
학습의 기회
- 무엇인가 모르는게 생기면 답을 찾도록 노력하라
- 비는 시간을 위한 읽을거리를 준비하라
비판적 사고
읽고 듣는 것을 비판적으로 분석하라
- ‘왜’냐고 다섯번 묻기
- 누구에게 이익이 되나?
- 어떤 맥락인가?
- 언제 혹은 어디서 효과가 있을까?
- 왜 이것이 문제인가?
Topic 7 - 소통하라!
청중을 알라
- 청중에 따라 포인트를 짚을 부분을 다르게 설정하라.
- 피드백을 모아라
- 질문을 기다리지말고 먼저 물어보라
말하고 싶은 게 무언지 알라 무엇을 말할지 미리 계획하고, 개요를 작성하라. 그리고 자문하라.
때를 골라라 무언가를 말할때 그 때가 적절한지 생각해봐라
스타일을 골라라 청중에 어울리도록 전달하는 스타일을 조정하라
- 청중이 사실만 전달하는 브리핑을 원하는가? 한담을 원하는가?
- 청중이 전문가인가?
하지만 조정할 수 없는 내용이라면, 사실이 그렇다고 전달하자
멋져보이게 하라 내용만 집중하기보단 멋져보이게 얘기하는 것도 중요하다
청중을 참여시켜라 가능하면 독자를 문서 초안에 참여하도록하여 피드백을 받아라
경청하라 회의를 대화로 바꾸면 생각을 더 효과적으로 전달할 수 있다
응답하라 “다음에 답해 드리겠습니다”라고 하더라도 사람들에게 응답해주면 더 긍정적으로 봐준다.
문서화 문서화는 꼭 필요한 작업이다.
문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
모듈과 외부로 노출하는 함수에는 주석을 다는 것을 추천한다. But 모든 함수나 자료구조에 주석을 남기는 것은 유지보수를 어렵게 만든다. 주석을 달 때는 코드의 용도와 목적을 논해야한다. 어떻게 동작하는지는 코드가 이미 보여주고 있기 때문이다.