상세한 내용은 https://github.com/oliv3h/the-pragmatic-programmer/blob/main/03.%EA%B8%B0%EB%B3%B8_%EB%8F%84%EA%B5%AC.md 에 작성하였습니다. 오늘도 함께 책 읽으신 여러분들 고생 많으셨어요!

오늘 TIL 3줄 요약

• 도구들은 제각기 고유의 방식으로 다듬어야 한다.

• 도구들은 유창하게끔(fluency) 손에 익혀야 한다.

• 항상 '분명 더 나은 방법'에 대해 고민하라.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어 보세요.

• 예전에 같은 학과 선배 혹은 외부 컨퍼런스에서 개발자라면 당연히 mac을 써야 한다는 말을 얼핏 들었던 기억이 난다. 그때만 하더라도 구직중이었던 지친 어린 양은 '애플이라는 이름값 만으로도 사람을 잘나가는 개발자처럼 보일 수 있게 하는 걸까?'라는 삐딱한 질문을 마음 속으로만 했더랬다. 그리고 오늘. 뜬금없게도 topic 17 <셸 가지고 놀기>를 보며 (...) 철없던 지난 날의 나를 다시금 떠올렸다. 부끄럽지만 다시 그때로 돌아간다면 나에게 조용히 속삭여주고 싶다. "제발 이상한 생각하지 말고 실용주의 프로그래머 책이나 읽어라."

• 실용주의 프로그래머 책을 읽으며 대부분 개발자 생활의 바이블과도 같은 느낌으로 글을 읽었으나, 마지막 Topic 22 <엔지니어링 일지>를 보며 이견을 느꼈다. 당연히 엔지니어링 일지를 "써야 한다."는 말에는 동의를 한다. 그러나 "파일이나 위키 말고 종이를 사용하라"는 입장에는 반대하는 편.

• 나는 입사 이래로 에버노트, 노션을 이용하여 <엔지니어링 일지>를 작성했다. (물론 이제 사담을 충실히 곁들인.) 장점은 누군가에게 업무에 관해 커뮤니케이션을 할 때 나름 깔끔하게 정리된 문서(=일지)를 가지고 사용할 수 있어 편리했다는 점이었다. 게다가 "온라인"으로도 충분히 소통이 가능하다는 점이 편했다. 바쁘다 바빠 현대사회에서는 하드 카피로 작성한 문서에 대해 소프트 카피로 변환하는 시간조차 부족하다. (특히 이제 연차가 차오를수록 정성들여 정리하는 것은 더더욱 불가능하다. 간략한 내용은 적되 필수불가결한 내용은 노션에 정리한다.) 만약 오늘 파트를 읽고 엔지니어링 일지에 대해 고민한다면 개인적으로 노션을 추천한다.

• 아, 덧붙이자면 나의 경우 엔지니어링 일지를 편히 외부 프로그램인 노션을 사용할 수 있는 환경에서 업무를 할 수 있었다. 만약 이것이 불가능하다면 최대한 markdown을 작성하는 방법에 대해 터득하여 vsc로 markdown 문서를 작성해보자. vsc에서는 markdown 문서를 ppt로도 내보내주는 아주 어마어마하고 무시무시한 기능을 갖추고 있다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어 보세요.

• 대부분 술술 읽히기에 특별히 궁금한 내용이 존재하지는 않았지만, 개인적으로는 셸 언어가 그렇게 강력한지 진짜 경험해보고 싶어졌다. 특히 "시스템 정보를 버전 관리 시스템으로 관리하여 빠른 복구가 가능했다."는 부분에 이끌려.. 먼지가 쌓인 맥북을 켜고 <자신만의 셸> 부분을 다시 읽어야 겠다.

오늘 읽은 다른 사람의 TIL

• @jds9285 님 https://nomadcoders.co/community/thread/3895 : 적절한 드립.. 매력 있으시다.