책 읽기 해석 공유

J002 강유진

개발자로서 성장하는 데 좋은 정보를 뇌에 입력하는 것도 좋지만, 제대로 이해하고 있는지 확인받는 것도 중요합니다. 아예 모르는 것보다 잘못 아는 것이 더 위험합니다. 그러므로 가급적이면 결과물을 공개해 다른 사람의 조언을 들을 기회로 삼아보시길 바랍니다.

-"개발자 원칙", p.55

• 해당 챕터의 내용에서는 전반적으로 오류가 발생했을 때 자세한 내부 동작을 뜯어보고, 학습한 내용을 공유하고, 마지막으로는 이걸 활용해서 어딘가에 기여해보면 이를 통해 학습을 할 수 있다는 노하우를 공유해주셨습니다. 모두 공감이 되고, 활용해봐야겠다는 생각이 들었지만, 실제 경험과 연관되어 있는 부분이 위의 내용이라는 생각이 들어서 해당 부분을 인상 깊었던 내용으로 작성하게 되었습니다.
• 지난 함수형 프로그래밍 미션을 진행하면서, 내 생각을 공유할 때 “내가 한 말이 틀린거먼 어떡하지?” 하고 겁먹고 철저하게 공부해서 한마디 한마디를 던져야겠다는 생각이 든 경험이 있습니다.

J040 김상민

<aside> 💡 -

• GPAM 프레임워크 (원칙) : 목표 달성 가능성 업
  • Goal : 목표 / Plan : 계획 / Action : 실천 / Measure : 평가
  • GPAM의 모든 항목은 서로 연관성이 깊음
  • P, A, M에 대해서 고려하며 G(목표)를 세워야 함
  • 광범위해서 계획을 세우기 힘든 목표 X, 실제 행동이 불가능한 목표 X, 결과를 측정할 수 없는 목표 X
  • 비전은 커도 되지만 목표는 작게, 단계적으로 여러 개 있어야 좋음.
  • 목표와 계획을 세우고 실천은 빠르게 해야 함
  • 결과가 나오면 즉시 평가 -> 평가 결과를 토대로 다시 목표와 계획을 업데이트. 마지막의 측정을 꼭 염두해두자.
• SMART 하게 목표 세우기
  • Specific : 개선이 필요한 영역에 대한 구체적인 목표
  • Measurable : 진행 상황에 대한 수치화(측정)가 가능해야 함
  • Actionable : 실행이 가능해야 함
  • Realistic : 현재의 리소스가 현실적으로 가능한지
  • Time-related : 결과가 언제 나올지 기한이 있어야 함
• 5W : Who, Why, When, Where, What
  • 구체적인 SMART 목표인지 확인하기 ex) 알고리즘 구현 실력을 키우겠다는 목표 (계획) who 나는 why 알고리즘 실력을 키우기 위해 when 평일 저녁 퇴근 후 3시간 동안 where 프로그래머스 사이트에서 what 알고리즘 3문제를 풀겠어.
  • 측정 가능한 SMART 목표인지 확인하기
    • ex) 시간을 측정하는 방식으로?
  • 실행 가능한 SMART 목표인지 확인하기
    • ex) 자원과 전례가 중요한 척도
  • 현실적인 SMART 목표인지 확인하기
  • 시의적절한 SMART 목표인지 확인하기

• "프로덕트 잘 만들기"
  • 내일부터 스프링 강의를 들어야지 vs 간단한 API 서버를 스프링 기반으로 만들어보겠어
  • 실제 프로덕트를 목표로 삼는 계획과 그렇지 않은 계획은 적지 않은 결과의 차이를 만들어 냄
• "반복적으로 완성하기"
  • 프로덕트를 성공적으로 만들기 위한 최선의 방법은 이터레이션 기반으로 일정을 점진적이고 반복적으로 진행하는 것
  • 이터레이션 : 상대적으로 짧은 주기로 목표를 세우고 이를 피드백이 가능한 결과물로 완성하고 개선하는 작업을 반복하여 프로덕트를 만들어내는 애자일 개발 방법론.
  • 혹자는 반복적인 개발 방법이 오히려 프로덕트를 만들기 위해 먼 길을 돌아가는 것으로 생각함.
  • 그렇지만 이터레이션 기반의 점진적이고 반복적인 개발이 최선의 길이다. 모든 프로젝트에는 변화의 가능성이 존재하고, 우리는 어떤 일이 생길지 예측을 못하기 때문임.
  • 이터레이션은 상대적으로 짧은 시간에 결과물을 만들고 피드백을 주고 받으며 프로젝트 진행 방향을 지속적으로 수정할 수 있게 함.
• "디테일까지 도달하기" 이터레이션을 반복하면 프로덕트의 완성도를 끌어올릴 수 있는 디테일한 작업 단계에 이르게 됨. 디테일을 논하게 되는 단계에 도달하는 것은 매우 중요힘. 기능 구현만 하고 끝내는 방식은 발전이 멈추게 됨.
• "항상 협업 모드로 작업하기"
  • 나와의 협업 : git과 같은 버전 관리 기구 적극적으로 사용하기
  • 타인과의 교류 : 온오프라인 세미나, 커뮤니티, 스터디
• "망설일 바에는 실패하라"
  • 더 나은 프로덕트를 목표로 삼고 무언가를 반복적으로 시도하면 점점 프로덕트에 대해 잘 이해하게 됨 </aside>

J110 박서연

• 읽은 부분: <나의 메이저 버전을 업그레이드하는 마이너 원칙들>, <이직, 분명한 이유가 필요해>, <목표를 달성하는 나만의 기준, GPAM> 일부

나에게 온전한 결정권이 없더라도 의견을 낼 수 있는 환경과 작더라도 나의 의견이 반영되는 경험은 제품에 필요한 일을 자발적으로 찾게끔 만드는 중요한 요인이 됩니다.

-> 어제 팀활동을 하는데 내가 익숙하지 않은 부분이기도 하니까 내 의견도 잘 못내고 다른 분을 따라가게 되었던 것 같다. 그러면서 결국에는 배운게 많았지만 많이 아쉬운 부분이 있었다.. 이 책에서처럼 나도 조금은 의견을 더 많이 내고 적극적으로 해야 더 성취감을 느끼고 ‘내것이다’라는 느낌이 드는 것 같다고 생각해서 공감이 많이 되었고 이 작가분의 직업을 대하는 태도가 본인과 회사의 성장을 모두 고려해서 적극적으로 추진하는데 그 부분도 참 인상적이었다.

G(Goal) P(Plan) A(Action) M(Measure)