Add review of chapter 24 to 33 and two discussions #553
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,78 @@ | ||||||
| ## 책 내용 정리 | ||||||
|
|
||||||
| 24장 배움을 사랑하며 살기 | ||||||
| 25장 테스트 주도 개발자 | ||||||
| 26장 도전 즐기기 | ||||||
| 27장 부진 피하기 | ||||||
| 28장 윤리적인 프로그래머 | ||||||
| 29장 언어에 대한 사랑 | ||||||
| 30장 프로그래머의 자세 | ||||||
| 31장 '더 열심히' 보다는 '더 현명하게' | ||||||
| 32장 끝나야 끝나는 것 | ||||||
| 33장 교훈 얻기 | ||||||
|
|
||||||
| - https://github.com/jongfeel/BookReview/issues/1288 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1293 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1294 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1300 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1301 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1311 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1314 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1319 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1321 | ||||||
| - https://github.com/jongfeel/BookReview/issues/1323 | ||||||
|
|
||||||
| ## 소감 | ||||||
|
|
||||||
| 이번에도 제가 이전에 읽었던 책인 클린 코드, 프로그래머의 길 멘토에게 묻다, 실용주의 프로그래머 책에서 다룬 주제가 겹친다는 느낌을 많이 받았습니다. | ||||||
| 꾸준히 학습해야 한다가 주제인 Chapter 24 배움을 사랑하며 살기 | ||||||
| 현실에 안하지 말고 더 나은 개발자 되기가 주제인 Chapter 26 도전 즐기기 | ||||||
| 여러 법률 윤리적인 문제를 지적하며 올바른 프로그래머가 되어야 한다는 주제인 Chapter 28 윤리적인 프로그래머 | ||||||
| 한 가지 언어 외에 다양한 언어를 배우자인 Chapter 29 언어에 대한 사랑 등등 입니다. | ||||||
|
|
||||||
| ## 논의 주제 1 | ||||||
|
|
||||||
| chapter 31 열심히 보다는 현명하게에 대한 내용 입니다. | ||||||
| 제가 과거 팀장 겸 멘토링 했을 때 자주 했던 말로 | ||||||
| '미련하게 열심히 하지 말고, 똘똘하게 잘' 이라는 말을 입에 달고 살았던 적이 있었습니다. | ||||||
| 이 말과 유사한 맥락으로 여태까지 잘 했던 아는 방법으로 힘들게 해서 열심히 했다고 포장하지 말고 | ||||||
| 조금 똘똘한 방법으로 하자가 주장의 핵심이었고 | ||||||
| 그 근거로 eXtreme programming에서 얘기했던 의사소통과 피드백의 근거를 들어서 얘기해 줬던 기억이 있습니다. | ||||||
| 그리고 이 책의 내용이 eXtreme programming의 내용과 유사한 점이 많은 것이 특징이기도 합니다. | ||||||
|
|
||||||
| 그래서 책의 전략으로 다음을 언급하는데 | ||||||
| 여기서 자신이 실천하고 있어서 아주 좋은 효과를 보고 있는 것이나 | ||||||
| 혹은 해야 하거나 하면 좋은 건 아는데 못하고 있는 환경적인(정치적인?) 이유 등을 자유롭게 얘기해 보면 좋겠습니다. | ||||||
|
|
||||||
| - 현명하게 재사용하라 | ||||||
| - 다른 사람의 일로 만들라 | ||||||
| - 해야 하는 것만 하라 | ||||||
| - 거칠더라도 빠르게 해결하라 | ||||||
| - 우선순위를 설정하라 | ||||||
| - 정말 필요한 것은 무엇인가 | ||||||
| - 한 번에 하나씩 | ||||||
| - 작고 간결하게 유지하라 | ||||||
| - 문제를 미루고 쌓아두지 말라 | ||||||
| - 자동화하라 | ||||||
| - 오류 방지 | ||||||
| - 의사소통하라 | ||||||
| - 지쳐 나가떨어지지 말라 | ||||||
| - 강력한 도구 | ||||||
|
|
||||||
| ## 논의 주제 2 | ||||||
|
|
||||||
| Chapter 33의 교훈 얻기 부분입니다. | ||||||
|
|
||||||
| 제가 느꼈던 강력한 교훈은 책의 설명에도 있지만 메타 인지 능력입니다. | ||||||
| 자기가 잘 하고 있다고 생각하지만 실제로는 엉뚱한 작업을 하고 있다는 걸 알아채야 하는데 | ||||||
| 가장 좋은 방법이 스스로 체크해서 돌아보는 시간을 가지고 알아채는 것입니다. | ||||||
| 물론 책의 일화는 페어프로그래밍 과정에서 알아채는 것인데 사실 페어프로그래밍의 단점으로 다른 사람의 비용을 지불해야 한다는 수고로움이 필요하므로 | ||||||
| 스스로 알아채는게 좋다는 입장에 동의하는 바입니다. | ||||||
|
|
||||||
| 그래서 제가 하는 방법은 크게 2가이인데 | ||||||
|
Member
Author
There was a problem hiding this comment. Fix typo by gemini
Suggested change
Contributor
There was a problem hiding this comment. 네, 맞습니다. 해당 오타를 수정해주셔서 감사합니다! |
||||||
|
|
||||||
| - 스스로 알아채기: 화장실 다녀올 때나 누군가와 대화한 후, 회의가 끝난 후, 화장실 다녀온 후 등의 시간을 보내고 다시 자리에 앉을 때입니다. | ||||||
|
Member
Author
There was a problem hiding this comment. Fix typo by gemini
Suggested change
|
||||||
| - 막혔을 때 동료와 대화하며 검증하기: 작업 하다 보면 시간이 오래 걸리고 더 해볼 게 없을 때 다른 사람과 대화를 시도해 봅니다. 내가 알고 있는 걸 설명해 보면서 다른 사람은 어떻게 설명해주고, 얼마나 알고 있는지 파악한 후 몰랐던 사실을 알게 되는 방식으로 합니다. | ||||||
|
|
||||||
| 그래서 책에서 설명해주는 방법이나 제가 쓰는 방법이 아니라고 하더라도 | ||||||
| 각자 사용하고 있는 유용한 방법에 대해 얘기해 보면 좋겠습니다. | ||||||
|
Comment on lines
+77
to
+78
Collaborator
There was a problem hiding this comment. 피드백의 경우 그게 타인에 의한 피드백이면 가장 좋고(바둑도 훈수두는 사람이 잘본다고..), 그렇지 않으면 본인 스스로라도 셀프 피드백을 할 수 있어야하는데요 저는 메타인지를 잘 활성화시키기 위해선, 피드백이 반드시 필요하다고 보는 입장 입니다 그래서 필요하면 항상 동료에게 페어 프로그래밍 혹은 페어워크를 요청하고, 제 조직장분들께 혹은 동료분들께 부정이든, 긍정이든 피드백을 적극적으로 요청을하고, 특히 부정적 피드백을 요청을 항상 드리는 것 같습니다 제가 셀프 피드백 하는 방법은 여러가지 있긴한데(무의식적으로 그냥 하루를 되돌아보고 어떻게 개선할 수 있을까 고민해보기도 하고, 의식적으로 개인 회고를 진행하기도 합니다), 하나를 공유드리면, 꼭 회사 뿐만 아니라, 일상 생활에서도 활용하는 것인데요
처음에는 잘 와닿지 않았던 문장인데, 시간이 지나면 지나서 곱씹어볼 수록 저 개인적으로는 많이 공감을 하고 있고, 위 문장을 기준으로 스스로를 많이 되돌아보고 있습니다
Collaborator
There was a problem hiding this comment. |
||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저도 의식적으로 딱 정해놓고 하기보다는, 그동안의 경험을 토대로
현명하게라는 것이 무의식적으로 발휘가 되는 것 같은데요 제 개인적으로는현명하게를 실천하는 방법은 주어진 문제를 어떻게 하면 가장 간단하게 풀 수 있을까? 에 초점을 맞추는 것 같습니다이것을 고민하는 과정에서 제 개인적으로는 책에서 나오는 수단들은 거의다 사용하는 것 같습니다.
제 개인적인 생각을 공유하자면, 상황에 따라 다르지만, 어떤 경우에는 개발을 하지 않고 운영리소스로 문제를 해결하는게 가장 간단한 방법일 수 있고, 어떤 경우에는 어느정도의 부채를 쌓는 결정을 하는게 문제를 가장 간단하게 해결할 수 있는 방법이 될 수 있다는 점 입니다.
즉 프로그래밍 자체에 너무 매몰 되서 모든 것을 개발의 문제로 보기 보다는 좀 더 실용적인 관점에서, 어떻게 간단하게 문제를 해결할 수 있을까의 측면으로 바라본다면, 굳이 개발을 하지 않더라도 문제를 해결할 수 있는 방법이 있고, 부채를 쌓더라도 문제를 쉽고 간단하게 해결하는게 더 좋은 결정일 수 있다는 것 입니다
저는 이 사례들이
현명하게의 구체적 사례들로도 볼 수 있다고 생각하고,현명하게는상황에 따라서 적절하게로 치환할 수 있으며, 이걸 얼만큼 잘 하느냐가 개발자의 역량으로 볼 수 있다고 생각합니다