실용주의 프로그래머 #01. 실용주의 철학

생성일:

7 분 소요

TL;DR (3줄 요약)

  1. 새로움을 두려워하지 말고, 흐름을 보며 주도적으로, 도전하는 자세를 갖자.
  2. 책임감을 갖기. 변명보단 대안을 제시하자.
  3. 조금씩, 하지만 주기적으로 지식에 투자하자.

🗓️ TIL (Today I Learned)

2022.03.19

🔖 오늘 읽은 범위

서문, 1장.실용주의 철학

🌟 책에서 기억하고 싶은 내용을 써보세요.

서문


  • 실용주의가 필요한 이유?
    • 개별 상황마다 그 상황에서 좋은 해결 방안을 고를 수 있도록 충분한 배경지식과 경험을 쌓아야 한다. 배경지식은 컴퓨터 과학의 기본 원리에 대한 이해에서 생겨나고, 경험은 다양한 종류의 실제 프로젝트들을 수행해 봄으로써 얻을 수 있다.

    이론과 실천의 결합이 여러분을 강하게 만든다.

무엇이 실용주의 프로그래머를 만드는가?

  • 얼리 어댑터 또는 새로운 것에 빨리 적응하는 사람
    • 새로운 것을 시도하기 좋아한다. 이런 사람의 자신감은 경험에서 우러나오는 것이다.
  • 호기심 많은 사람
    • 질문을 많이 한다. 자잘한 지식을 머릿속에 쌓아 두며, 그 가운데 어떤 것은 몇 년 후의 결정에 영향을 주기도 한다.
  • 비판적인 사고의 소유자
    • 사실 관계를 확인하지 않고서는 곧이곧대로 믿는 일이 드물다.
  • 현실주의자
    • 자신이 맞닥트리는 모든 문제의 근본적인 특성을 이해하려고 노력한다.
    • 얼마나 어려운 일인지, 이 일에 시간이 얼마나 걸릴지 판단하는 감각 → 이를 이해하면 끈기 있게 그 일을 해 나갈 지구력이 생긴다.
  • 다방면에 능숙한 사람
    • 다양한 분야의 기술과 환경에 친숙해지려고 열심히 노력한다.
    • 그리고 새로운 발전의 흐름에 뒤떨어지지 않으려고 노력한다.

절대 기계적으로 일하지 말라. 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라.

끊임없는 과정

훌륭한 잔디밭은 매일 조금씩 손질해 주어야 한다. 훌륭한 프로그래머도 마찬가지다.

  • 매일같이 지금 있는 기술들을 다듬고, 여러분 기술 목록에 새로운 도구들을 추가하라.

1장. 실용주의 철학


  • 실용주의 프로그래머는 직면한 문제 너머를 고민한다. 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다.

Topic1 당신의 인생이다

“왜 직접 바꾸지 않습니까?” (p.3)

  • 우리는 원하는 것은 거의 무엇이든 할 수 있다.
  • 마틴 파울러가 말했듯이 “당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다.”
  • 이 업계는 여러분에게 놀랄 만큼 다양한 기회를 준다. 주도적으로 행동해서 그 기회를 잡아라. (p.4)

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

  • 전문가다운 처리 : 정직하고 솔직
  • 우리는 자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점도 인정해야만 한다.

[팀 내 신뢰]

  • 신뢰에 바탕을 둔 건강한 환경에서는 안전하게 여러분의 생각을 말하거나 아이디어를 제안할 수 있다. (p.5)
  • 신뢰에 구멍이 뚫리면 원상복구가 어렵다.

[책임지기]

  • 여러분이 통제할 수 없는 위험 요소가 있지 않은지 상황을 분석해야 한다. 여러분에겐 불가능하거나 위험 요소가 너무 큰 상황, 또는 결과가 윤리적으로 심각하게 우려되는 상황에서는 책임을 맡지 않을 권리가 있다. (p.5)
  • 다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 말라. (중략) 필요한 것은 변명이 아니다. 해결책을 찾아내야 하는 사람은 여러분이다. (p.6)
  • 변명 말고 대안을 제시하라. 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있을지 설명하라.
  • 여러분이 “잘 모르겠어요.”라고 말했다면, 꼭 바로 이어서 “하지만 알아볼게요.”라고 말하라. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다.(p.7)

Topic3 소프트웨어 엔트로피

  • 절망감이 전염된다. (중략) 명백히 망가진 상황을 무시하는 것은 아무것도 고쳐지지 않을 것 같다는 생각, 아무도 신경쓰지 않는다는 생각, 망조가 들었다는 생각을 더 굳어지게 만든다. 이런 부정적인 생각이 팀원들 사이러 퍼져서 악순환을 만들 수 있다.(p.9)
  • ‘깨진 창문’을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라.
  • 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라. → 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 상황을 잘 관리하고 있음을 보여 줘라.
    • 불쾌한 코드를 주석처리
    • ‘아직 구현되지 않았음’이라고 메시지를 표시
    • 가짜 (dummy) 데이터로 대치 **

방치는 다른 어떤 요인보다도 부패를 더 가속시킨다. (p.9)

[우선, 망가트리지 말라]

  • 어떤 위기가 찾아왔다고 해서 부가적인 피해를 일으키지 말라.(p.10)

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

[군인] → 하나의 촉매로 작용해서 마을 사람들 스스로는 불가능했던 무언가를 힘을 모아 이룰 수 있도록 도움

  • 일에 착수하려고 허락을 구하는 때부터, 무너가가 지연되거나 사람들이 멍한 눈으로 여러분을 바라본다. (시작 피로 start-up fatigue)
  • 큰 무리 없이 요구할 수 있을 만한 것을 찾아라. 그리고 그걸 잘 개발하라. 일단 무언가 생기면 사람들에게 보여 주고 그들이 경탄하게 하라 (p.13)
  • 미래를 살짝이라도 보여 주면 사람들은 도와주기 위해 몰려들 것이다.

[마을 사람의 경우] → 한 가지에 너무 지나치게 집중

  • 종종 작은 것들이 쌓이고 쌓여서 사람들의 의욕, 그리고 팀을 파괴한다.
  • 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보라. **

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

우리는 종종 뭔가 나아기제 하려다가 괜찮은 것마저 망친다.

  • 셰익스피어, <리어왕>1막 4장 (p.15)

  • ‘적당히 괜찮은’이라는 표현은 너절하거나 형편없는 코드를 의미하지 않는다. (p.16)
  • 생산해 낸 것이 적당히 괜찮게 사용자의 요구를 충족하는지 결정하는 과정에 사용자가 참여할 기회를 가져야 한다는 것이다.

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

  • 놀랍게도 많은 사용자가 멋지고 휘황찬란한 버전을 위해 일 년을 기다리느니 차라리 오늘 당장 좀 불편한 소프트웨어를 사용하고 싶어 한다(게다가 사실 1년 뒤면 원하는 것이 완전히 달라질 것이다.) (p.17)
  • 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다.

[멈춰야 할 때를 알라]

  • 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아 두라. 완벽하지 않을 수도 있다. 그래도 괜찮다. 완벽해지기란 불가능하다. (p.18)

Topic6 지식 포트폴리오

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

  • 벤저민 프랭클린

  • 새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛것이 된다. (p.20)
  • 새로운 것을 배우는 능력은 여러분의 가장 중요한 전략 자산이다.

[지식 포트폴리오]

  • 비결은 일단 스스로 한 번 해본 다음, 습관을 들이는 것이다. 따라 할 절차를 만든 다음 여러분의 뇌에 각인될 때까지 반복하라. (p.21)

[포트폴리오 만들기]

  • ✨ 주기적인 투자
    • 소량으로라도 주기적으로 투자해야 한다. 그 습관 자체가 금액의 합계만큼이나 중요하다.
    • 방해를 받지 않을 수 있는 시간장소를 정기적으로 이용할 계획을 마련하라.
  • 다각화
    • 더 여려 가지를 알수록 자신의 가치는 더욱 높아진다.
    • 현재 작업에 사용하는 기술 + a
  • 리스크 관리
  • 싸게 사서 비싸게 팔기
    • 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 게 저평가된 주식을 찾아내는 것만큼이나 어려울 수 있지만, 이익 또한 그만큼 클 수 있다.
  • 검토 및 재조정

[목표]

종잣돈이 될 지식 자산을 공급하는 최선의 길

  1. 매년 새로운 언어를 최소 하나는 배워라
    • 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방하는 데에 도움이 된다.(p.22)
  2. 기술 서적을 한 달에 한 권씩 읽어라
    • 깊이 있는 지식을 원한다면 긴 글 형식의 책을 읽어야 한다.
    • 현재 프로젝트와 관련 있는 흥미로운 주제의 기술 서적을 서점에서 찾아보라. 현재 사용하는 기술을 일단 완전히 익혔다면, 지금 하는 프로젝트와 관련 없는 분야까지 공부 범위를 넓혀라.
  3. 기술 서적이 아닌 책도 읽어라
    • 컴퓨터도 사람이 사용한다는 걸, 그리고 우리는 바로 이 사람들을 만족시키려고 노력하고 있다는 걸 꼭 기억해야 한다.
  4. 수업을 들어라
  5. 지역 사용자 단체나 모임에 참여하라
    • 고립은 경력에 치명적일수 있다. 여러분 회사 밖에서는 사람들이 어떤 일을 하는지 알아보라. 가서 가만히 듣고만 오지 말고 적극적으로 참여하라.
  6. 다른 환경에서 실험해 보라
    • 다른 OS, 다른 개발 환경 IDE 을 시도해 보라.
  7. 요즘 흐름을 놓치지 말라
    • 현재 프로젝트에서 사용 중인 것과는 다른 기술을 다루는 뉴스와 온라인 게시물을 읽어라.

사고 간의 교접이 중요하다. 새로이 배운 교훈을 현재 프로젝트에 적용하도록 노력하라. (p.24)

[학습의 기회]

  • 질문이 들어옴 → 답을 모름 → 인정한다 → ✨ 답을 찾기 위한 개인적인 도전으로 생각하라
    • 웹을 검색해 보라
    • 사용자용 문서뿐 아니라 학술 자료도 찾아보아야 한다.
    • 스스로 답을 찾지 못하겠거든 답을 찾아줄 수 있는 사람을 찾아라. 중단하지 말라.
  • 독서와 연구는 시간이 걸리고 시간은 늘 부족한 자원이다.
    • 다른 사정으로 비는 시간을 위해 늘 읽을거리를 준비하라. (p.25)

[비판적 사고]

  • “왜냐고 다섯 번 묻기 Five Whys”
    • 근본 원인에 더 가까이 다가갈 수 있을 것이다.
  • 누구에게 이익이 되나?
    • 돈의 흐름을 살피면 분석이 한결 쉬워지기도 한다.
  • 어떤 맥락인가?
    • 최고의 방법은 ‘누구에게 최고인가?’
    • 전제 조건은 무엇이고 그 결과의 장기, 단기적 여파는 무엇인가?
  • 언제 혹은 어디서 효과가 있을까?
    • “그 이후에는 또 어떤 일이 일어날까?” 같이 그다음 단계까지 생각해 보라.
  • 왜 이것이 문제인가?
    • 광범위한 포트폴리오를 갖추고, 넘쳐나는 기술을 다룬 글을 읽을 때 비판적 분석을 적용함으로써 복잡한 해답을 이해할 수 있을 것이다.

Topic7 소통하라!

  • 여러분이 뭘 가졌느냐 만이 아니라 그걸 어떻게 포장하느냐도 중요하다. (p.28)
  • 하루 중 많은 시간을 소통하며 보내기 때문에 이를 잘할 필요가 있다.

[청중을 알라]

그저 질문을 기다리지 말고 먼저 물어보라.

[말하고 싶은 게 무언지 알라]

  1. 무엇을 말할지 미리 계획하라.
  2. 개요를 작성하라.
  3. 그리고 자문하라. ‘이렇게 하면 내가 표현하고 싶은 것을 듣는 사람에게 통하는 방법으로 잘 전달할 수 있나?’
  4. 그렇게 될 때까지 다듬어라.

[때를 골라라]

  • 청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다.
  • 가끔 ‘…..에 대해 이야기할 좋은 때일까?’라는 간단한 질문을 해 보는 것만으로도 충분하다.

[스타일을 골라라]

  • 전달하는 스타일을 청중에 어울리도록 조정하라. (p.31)
  • 뭐가 좋을지 모르겠거든 물어보라.

[멋져 보이게 하라]

  • 워드 프로세서의 스타일 시트, 페이지 머리말과 꼬리말, 스타일과 레이아웃, 맞춤법 검사

[청중을 참여시켜라]

  • 가능하다면 독자가 문서 초안에 참여하도록 하라. 피드백을 받고 그들의 머릿속을 도용하라.

[경청하라]

[응답하라]

  • 언제나 이메일과 음성 메시지에 답을 하라. 심지어 응답이 단순히 “다음에 답해 드리겠습니다.” 이더라도. (p.33)

[문서화]

  • 실용주의 프로그래머는 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 받아들인다.
  • 소스 코드에 다는 주석은, 프로젝트에서 쉽게 누락되는 다른 곳에서 문서화할 수 없는 부분을 문서화하기에 최적의 기회다.
    • 예를 들어 기술적인 절충점, 어떤 결정의 이류, 폐기한 다른 대안 등

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

  • 클린 코드는 방법을 알려주는 해답지를 보는 기분이었는데, 실용주의 프로그래머는 마치 사수가 옆에서 끊임없이 조언해주는 기분이 들었다. 모든 문장이 다 공감도 가고 이해도 가고,,, ㅎ
  • 특히나 프로그래머로서의 자세에 대해 생각해보게 되었다. 지금까지는 주니어라 아직 지식이 부족하다는 이유로, 지레 겁먹고 고쳐야 할 부분이 보인다거나 하고 싶은 것이 있어도 참고 분위기 보면서 말을 아낀 경우가 많았는데 이번 챕터를 읽으면서 좀 더 주도적이고 적극적으로 변해야겠다는 생각이 들었다. “당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다.” 뼈에 새겨야 할 말…

📚 오늘 읽은 다른 사람의 TIL

댓글남기기