동료들과 실용주의 프로그래머라는 책을 같이 읽고 있습니다. 공부하면서 정리한 내용을 블로그에도 남겨볼까 합니다. 아직 못 읽은 부분은 계속 업데이트하려고 합니다.

1장. 실용주의 철학

Topic1 당신의 인생이다

우리에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다. 이 업계는 우리에게 다양한 기회를 주고, 주도권은 우리에게 있으니 행동하라.

Topic2 고양이가 내 소스 코드를 삼켰어요

개인적으로 최선을 다하는 것이 전부가 아니다. 불가능하거나 위험 요소가 크면 책임을 맡지 않을 권리가 있고 실수를 저지르거나 잘못된 판단을 내렸다면 잘못을 인정하고 대안을 제시해야 한다. 책임을 맡은 업무에서 외부 요인이 문제가 있더라도 그것까지 커버해야 한다.

“잘 모르겠어요. 하지만 알아볼게요” → 모른다는 것을 인정하고 전문가답게 책임을 지는 방법

현재 회사를 다니면서 스스로 결정을 많이 합니다. 그 결정이 합리적이라면 전적으로 믿어주는 팀원들이 있습니다.

Topic3 소프트웨어 엔트로피

나쁜 설계, 잘못된 결정, 형편없는 코드 등은 모두 깨진 창문이며 발견하자마자 고칠 것. 엔트로피가 우리를 지배하도록 내버려두지 말 것

그러기 위해서는 먼저 망가트리지 말아야 한다.

프로젝트에 깨진 창문은 얼마나 많은지? 어떻게 고칠 것인지?

Topic4 돌멩이 수프와 삶은 개구리

변화의 촉매가 될 것. 사람들은 각자 자신의 자원을 지키려고 한다. (시작 피로) 계속되는 성공에는 합류하기 쉽다.

비슷한 경험을 했습니다. 같이 일하는 디자이너분들과 사이드 프로젝트를 하는데, 첫 미팅 후에 다음 미팅 때 간단하게라도 데모 버전을 보여드렸던 적이 있습니다. 굉장히 반응은 뜨거웠고 크게 동기부여가 되서, 아이디어도 많이 나왔고 디자이너 분들의 의욕이 넘쳐나는 것이 보였습니다. 다음 미팅때도 기능을 조금 더 추가한 데모 버전을 보여드렸고 그 결과 업무에 지쳐있던 분들의 컨디션을 끌어올릴 수 있었고 계속해서 동기를 부여할 수 있었습니다.

큰 그림을 기억하라. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 살펴봐야 한다.

Topic5 적당히 괜찮은 소프트웨어

완벽한 소프트웨어를 만들 순 없지만 적당히 괜찮은 소프트웨어를 만들 순 있다.

우리가 생산해 낸 것이 적당히 괜찮게 사용자의 요구를 충족하는지 결정하는 과정에 사용자가 참여할 기회를 가져야 한다.

완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말 것.

Topic6 지식 포트폴리오

지식에 대한 투자가 언제나 최고의 이윤을 낸다.

매우 인상깊은 말

우리 지식은 기한이 있는 지식이다. 새로운 것을 배우는 능력이 가장 중요한 능력 자산

알고 있지만 참 어려운… react, vue도 나중에 보면 한물 간 기술이겠지

1. 주기적으로 공부하자
2. 더 많은 기술에 익숙해지자 → 변화에 더 잘 적응
3. 리스크 관리 → 위험도가 높지만 보상이 큰 것, 낮지만 보상이 작은 것을 잘 섞자
4. 싸게 사서 비싸게 팔기(얼리어답터)
5. 검토 및 재조정 → 트렌드를 다시 파악해서 올바른 방향으로 가고 있나 체크!

많이 하지 않더라도 조금씩 공부하자. -> 새로운 것을 접하는 것만으로도 리프레쉬되고 나를 객관적으로 돌아보는데 도움이 많이 됨. 중심을 잡을 기술(react 등)과 새롭지만 높은 보상이 있는 기술을 섞어볼 것.(deno, next13 등) 포트폴리오에 비유를 하니까 되게 재밌고 유사한 점이 많은 거 같음.

목표

1. 매년 새로운 언어를 최소 하나는 배우기
   • 언어는 동일한 문제를 다르게 푼다
   • 사고방식의 확장에 도움을 줌
2. 기술 서적을 한 달에 한 권씩 읽기
   • 제일 실천하고 싶은 것
   • 깊이 있는 지식 → 긴 글 형식의 책
3. 모임에 참여할 것
   • 고립은 경력에 치명적일 수 있다.
4. 다른 환경에서 실험
   • 새로운 환경은 자극을 준다

책은 읽기 시작했는데 기술 서적을 읽을 생각은 못했음. 주기적으로 읽어야겠다 라는 생각이 듦. 모임에 참여하자. 겨울엔 사진을 좀 줄이고 모임을!

비판적 사고

1. 왜냐고 다섯 번 묻기
2. 누구에게 이익이 되나?
   • 사용자?
   • 개발자?
   • 조직원?
3. 어떤 맥락인가?
   • 전제 조건이 뭔지
   • 그 결과의 장,단기적 여파는 무엇인지?
4. 언제 혹은 어디서 효과가 있을까?
   • 다음에 어떤 일이 일어날까 → 그 다음엔 어떤 일이 일어날까? 멀리 생각해볼 것
5. 왜 이것이 문제인가?

일을 할 때, 왜 하는지, 공수대비 얼마나 임팩트, 컨피던스가 있는지를 항상 생각하는데 더 다각화해서 생각해볼만 하다.

Topic7 소통하라!

청중을 알고 내용을 그에 맞게 각색해서 전달.

멋지게 보이게 할 것. (개발자라는 핑계로 디자인을 소홀히 하지말자.)

타이밍도 중요(청중이 내 전달 내용을 필요로 하는 타이밍을 찾아보자)

청중을 참여시켜라

결국 듣는 사람이 듣고 싶은 얘기를 해야 한다.

문서화 → 코드의 용도와 목적을 논해야 한다. 동작 방식은 코드가 보여주므로 불필요.

청중 참여, 타이밍 등 청중을 계속 생각하는 걸 연습해야겠음.