diff --git a/2025/Becoming a Better Programmer/taehyoung/24.md b/2025/Becoming a Better Programmer/taehyoung/24.md new file mode 100644 index 00000000..f0107770 --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/24.md @@ -0,0 +1,11 @@ +# ch24. 배움을 사랑하며 살기 + +# 논의 내용 + +- 없음 + +# 내 생각 + +- 배움을 실천한다는 것 자체보다 더 중요한 것은 현재 나에게 왜 배움이 필요한지와 무엇을 어떻게 배울지에 대한 것이다. 이때 그 기준은 철저히 내 기준이어야 한다. 즉, 현재 나에게 필요한 것인지 아닌지에 대한 판단을 스스로 내려서 배움의 범위를 정해야한다. 그렇지 않고, 나 이외의 다른 사람의 의견이 들어가게 된다면, 배움의 중요한 본질을 놓친채 시간만 버릴 가능성이 높다고 생각한다. 예를 들면, 업무 중에 나의 지식의 부족으로 제대로 끝내지 못한 부분이 있다면, 이는 좋은 배움거리라고 본다. 내 문제를 해결하기 위한 해결책이기 때문이다. 반대로, 요즘에 어떤 기술이 유행하는데, 유행하는데 배우지 않으면 안될거 같고, 다른 사람들을 봤을 때, 다들 이걸 하더라 라는 것을 보고, 나도 이것 배워야겠다라고 생각이 든다면, 높은 확률로 시간 낭비일 가능성이 높을 것 같다. +- 학습방법과 관련해서, 이전과 비교해서 현재 하지 않는 1가지는 책의 내용 혹은 강의 내용을 그대로 받아서 내 노트에 적어두지 않는다는 것이다. 이렇게 하는 이유는 내용을 열심히 적고나서, 다시 그 내용을 보는 일이 거의 없었기 때문이다. 오히려 그 내용을 정리하거나, 요약한 부분을 보기 보다는, 책이나 강의를 다시 찾아보는 경우가 더 많았다. 나의 경우는 위의 행동패턴을 보이다보니, 사실상 내용을 정리하거나 요약하거나, 문장을 옮겨적는 행위가 나에게는 불필요한 행위가 되었다. 그 대신에 내가 기록하는 것은 `키워드` 와 `질문` 그리고 `내 생각` + `도식화` 이다. 따지고 보면, 현재 책모임에서 하는 형태와 비슷한데, 그전에는 input 그 자체에 집중했다면, 현재는 output 에 좀 더 집중하려고 한다고 볼 수 있다. 좀 더 풀어서 설명하면, 어떤 주제에 대해서 전통적인 방식으로 일단 적고 보는 방식을 취하기 보다는 키워드들을 정리해보고, 해당 주제에 대한 내 생각도 정리해보고, 나스스로 주제에 대한 추가적인 질문도 만들어보고, 내 방식대로 도식화도 해보는 과정을 거침으로써, 어떤 주제를 나의 지식으로 `체득` 하는 것에 집중한다 라고 볼 수 있을 것 같다. 이렇게 했을 때의 내가 생각하는 장점은 자연스럽게 어떤 주제에 대해서 비판적인 관점에서 바라보고 내 생각을 정리해 볼 수 있다는 점이다. 책을 읽을 때, 그냥 그 텍스트 내용을 받아적는것에만 집중한다면, 저자의 의견을 정답으로 받아들일 가능성이 높다. 하지만, 내 생각을 고민하게 되면, 어떤 주제 혹은 주장에 대해서 나 혹은 나의 현재 상황과 비교한 어떤 생각을 하게 되기 때문에, 개인적으로는 좀 더 재미있게 학습할 수 도 있고, 나중에 어떤 주제에 대해서 말할 때도 훨씬 더 기억이 잘 난다고 생각한다 +- `나중에 버릴지언정 지금 배우고 있는 것을 기록하라` 라는 책의 조언은 그다지 동의하진 않는 편이다. 나중에 버릴거라면, 굳이 시간낭비하면서, 기록할 필요가 없다고 생각한다. \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/25.md b/2025/Becoming a Better Programmer/taehyoung/25.md new file mode 100644 index 00000000..a659697f --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/25.md @@ -0,0 +1,9 @@ +# ch25. 테스트 주도 개발자 + +# 논의 내용 + +- 이 챕터의 메인 키워드는 `안일함` 일 것 같습니다. `안일함` 때문에, 큰 코 다친 경험이 있다면 말해보면 좋을것 같습니다 + +# 내 생각 + +- 이 챕터에서 가장 중요하다고 생각되는 부분은 `안일함` 에 대해서 얘기한 부분이다. 대개의 경우는 어떤 것에 익숙해졌을 때, `안일함` 이 드러나는 일이 많다. 경험적으로 느꼈을 때, 개발자의 경우도 본인이 익숙한 어떤 기술 혹은 업무에 대해서는 직관에 의존하는 경우가 많은데, 확실하게 확인할 수 있는 수단이 있어야한다. 개인적으로는 `테스트` 라고 생각한다. 성공,실패 케이스를 모두 정의하고 어떤 방식으로든 테스트를 할 수 있고, 문제가 없는게 확인 되었다면, 전혀 문제가 없다고 생각한다. 다만 이런 검증절차를 거치지 않고, 어떤 본인의 직관에 의해서, 단순하게 문제가 없다고 판단하면, 이것이 바로 `안일함` 이 아닐까 라는 생각이다 \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/26.md b/2025/Becoming a Better Programmer/taehyoung/26.md new file mode 100644 index 00000000..891ffa44 --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/26.md @@ -0,0 +1,11 @@ +# ch26. 도전 즐기기 + +# 논의 내용 + +- 없음 + +# 내 생각 + +- 개인적으로 프로그래밍 자체는 되게 좋아하고, 재미있게 생각하고 있다. 그래서 일을 할 때도 개발하는게 재미있고, 평소에 일을 하지 않을 때도, 소소하게 개인프로젝트 개발을 하거나(요즘은 안하긴하지만…) 그냥 CS 책, 기술 관련 책들을 보는것 자체도 재미있고 하다보니 취미 처럼 되었다. 어떻게 보면, 내가 하는 일과 내가 재미있고, 즐겁게 하는 것이 일치한다는 것은 행운이라고 생각한다 +- 예전에는 내가 통제할 수 있다는 것 자체에 더 흥미를 느꼈었다. 예를 들면, 내가 할줄아는 언어와 프레임워크로 내가 딱 개발할 수있는 수준에서 내가 필요한 어떤 서비스를 만들고 직접 사용하는 것이다. 혹은 회사에서 일을 할 때, 특정 언어와 프레임워크를 사용해서 개발 업무를 한 것으로도 말할 수 있을 것 같다. 그러나 최근에는 내가 당장 통제할 수 없는 것이더라도, 문제를 이해하고, 그걸 해결하는 과정 자체가 즐겁다고 느끼다보니, 회사 업무도, 개인프로젝트도 질리지 않고 할 수 있게 되는것 같다. 마치 방탈출을 더잘하기 위해서 여러가지 방법을 연구하는 것, 특정 보드게임의 승률을 올리기 위해서 고민하고 실제로 적용해보는 것과 비슷한 맥락에서 볼 수 있을 것 같다 +- 그래서, 요즘에는 문제해결의 관점에서 모든 것을 보고, 해결절차에 관심을 가지다보니, 어떤 것을 새롭게 배우고, 활용하는 것에 대해서 거부감을 가지기 보다는 흥미롭게 받아들이는 것 같다 \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/27.md b/2025/Becoming a Better Programmer/taehyoung/27.md new file mode 100644 index 00000000..678933f7 --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/27.md @@ -0,0 +1,10 @@ +# ch 27. 부진 피하기 + +# 논의 내용 + +- 없음 + +# 내 생각 + +- 안전지대에 머물지 말아야 한다는 내용에 대해선 공감한다. 그러나 제안한 해결책에 대해선 과연 적절한 해결책일지에 대한 의문이 있다. 개인적으로는 어떤 방법론적인 해결책을 찾기보다는(예를 들어서 책에 나온대로, 새로운 언어를 도전해봐라, 개인 프로젝트를 해봐라 등등), 본인 스스로의 동기에 대해서 더 고민해보는게 좋지 않을까 하는 생각이다. +- 개인적으론, 회사 업무를 스트레스를 받지 않고, 재미있게 일하고 싶다. 나의 의사결정과 결과물로 나도 이득을 얻고, 회사도 이득을 얻고, 내 동료들도 같이 이득을 보면 좋겠다라는 생각을 가지고 있는데, 이 생각이 나에게는 개발과 관련된 공부들을 더 열심히하게 하는 동기 중 하나이다. \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/28.md b/2025/Becoming a Better Programmer/taehyoung/28.md new file mode 100644 index 00000000..19a32945 --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/28.md @@ -0,0 +1,10 @@ +# ch28. 윤리적인 프로그래머 + +# 논의 내용 + +- 없음 + +# 내 생각 + +- 프로그래머라는 직업 윤리의 관점에서 큰 고민을 해본적은 없다. 책을 읽으면서, 여러가지 것들을 고려해볼 수 있겠다라는 생각이 들었는데, 개인적으로는 무의식적으로 그냥 별생각없이 했었던 것 이다보니, 당연한것으로 받아 들였던 것들인 것 같다 +- 이런 윤리적인 사항들에 대해서는 전적으로 각 개인에게 그 책임 있지 않을까 생각된다. 즉, 아무리 회사에서 혹은 주변에서 이런 저런 얘기를 한다고 하더라도, 본인 스스로가 윤리적인 사항들을 인지하고, 지킬려고 노력을 해야만 지킬 수 있다고 생각한다. 위에서 말한대로, 사실 상식적인 사항들이 많다보니, 상식적인 선에서 항상 판단하려는 노력을 하는 것만으로도 대부분 윤리적인 문제들은 해결이 되지 않을까? 라는 생각이 있다 \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/29.md b/2025/Becoming a Better Programmer/taehyoung/29.md new file mode 100644 index 00000000..ce4b026b --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/29.md @@ -0,0 +1,11 @@ +# ch29. 언어에 대한 사랑 + +# 논의 내용 + +- 한 때, 김포프 님이 개발자로써, managed 언어와 unmanaged 언어 둘다 학습할 필요가 있다고 주장한적이 있었는데요. 물론, 모든 언어의 특성을 위의 2가지 만으로 나눠서 바라볼 수 없지만, 개인적으로는 이분 주장에 어느정도는 동의하는 바 입니다. 이 주장에 대해서 어떻게 생각하시는 다른 분들의 의견이 궁금하네요 +- 폴리글랏에 대해서 어느정도로 동의하는지 궁금합니다. 폴리글랏에 어느정도 동의하신다면, 폴리글랏이 되기 위해서, 어떤식으로 접근하는지 궁금합니다 + +# 내 생각 + +- 여러 언어들을 고려해서 활용해보는 것은 단순히 그냥 해보는 것 보다는 어느정도 동기가 있으면 좋다고 생각하는 편인데, 이전에 다른 챕터에서 말했던 것과 같이, 본인의 업무 혹은 개인적인 일상에서 어떤 문제들이 있는지를 잘 살펴보고, 이를 어떻게 해결할 수 있을지에 대한 관점에서 접근을 해보면 좋을 것 같다는 생각이다. 예를 들어서, 나의 경우는 기존에 파이썬으로만 업무를 하다가, 회사에서 자바 업무를 하게 되면서, 본격적으로 자바 언어에 대한 관심을 가지고 사용해볼 수 있었다. 또한 학생시절 때 배운, C 언어 등은 당시에 배울 때는 왜 이걸 써야하는지에 대한 인식없이 그냥 쓰다보니, 언어를 배우는 효용성에 대해서 전혀 인식하지 못했었는데, 최근에는 컴파일, 메모리 관리 등의 관점에서 더 깊이 이해하기 위해서 C언어를 살펴 보다 보니, 확실히 그전보다는 더 관심도 높게 언어를 바라볼 수 있게 된 것 같다 +- 개인적으로는 여러 언어를 다룰 수 있는 폴리글랏을 지지 하진 않는다. 그 이유는 언어를 습득하는 것 자체가 목적으로 보이기 때문이고, 전문성의 측면에서, 하나에 집중하는것과 여러개를 집중하는 것의 깊이의 차이는 어쩔 수 없는 부분이다. 그러나 그렇다고해서, 언어를 하나만 딱 해야한다 식의 고정된 마인드를 가질 필욘 없다고 생각한다. 이전챕터에서도 말했던 것 처럼, 여러언어들을 경험해보면서, 그 언어들만의 철학을 배워보는 것도 프로그래밍 언어에 대한 관점을 넓힐 수 있다는 측면에서는 좋다고 생각하고, 무엇, 어떤 언어냐 보다는 이 언어를 어떻게 활용할 것인가에 집중해서 활용해보면 좋지 않을까 생각이다. 예를 들면, 그냥 Rust가 요즘에 핫하니까 배워보자가 아니라, 업무에서 파이썬의 CPU bound 향의 코드가 성능이 잘 나오지 않는 문제가 있을 때, 이를 개선하기 위해서 Rust를 활용해보는 것이다. \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/30.md b/2025/Becoming a Better Programmer/taehyoung/30.md new file mode 100644 index 00000000..c749f798 --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/30.md @@ -0,0 +1,10 @@ +# ch30. 프로그래머의 자세 + +# 논의 내용 + +- 건강을 지키면서, 프로그래밍을 더 잘하기위한 혹은 업무효율성을 높이기 위한 본인만의 어떤 방법론 있다면 공유해보면 좋을 것 같습니다 + +# 내 생각 + +- 이번 장의 내용은 좀 웃겼던거 같다. 이런 것 까지 책 내용에 싣는게 재미있네 라는 생각이였다. +- 그러나, 웃겼다고 말하긴 했으나, 저자의 말대로 어느정도 중요한 내용인 것은 사실이라고 생각한다. 프로그래밍을 잘하기 위해선 태도 그 자체도 중요하지만, 이를 지속할 수 있는 피지컬적인 요소, 자세 등도 중요한게 맞기 때문이다. 꼭 책에 나와있는 내용이 아니더라도, 건강과 관련해서 본인 스스로 잘 관리할 수 있어야 한다고 생각한다 \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/31.md b/2025/Becoming a Better Programmer/taehyoung/31.md new file mode 100644 index 00000000..596b109a --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/31.md @@ -0,0 +1,15 @@ +# ch31. 더 열심히 보다는 더 현명하게 + +# 논의 내용 + +- 개인적으로, 주니어개발자, 시니어개발자의 역량을 나누는 것을 좋아하진 않지만, 면접 같은 곳에서 굳이 평가를 해야한다면, 지식이 더 많냐 아니냐를 따지기 보다는 `현명하게` 의 수준으로, 해당 개발자가 시니어의 역량을 가졌는지 아닌지를 판단하면 좋지 않을까? 라는 개인적인 생각이 있습니다 다른분들 생각도 궁금합니다 + - 시니어, 주니어 역량 구분을 하지 않아야한다와 관련된 제가 쓴 글을 공유합니다 + - https://medium.com/@kth5604/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%8A%94-%ED%94%84%EB%A1%9C-%EC%8A%A4%ED%8F%AC%EC%B8%A0-%EC%84%A0%EC%88%98-94d3d81ca780 + - [https://medium.com/@kth5604/나는-주니어니까-라고-말하지-말자-387c2babdd75](https://medium.com/@kth5604/%EB%82%98%EB%8A%94-%EC%A3%BC%EB%8B%88%EC%96%B4%EB%8B%88%EA%B9%8C-%EB%9D%BC%EA%B3%A0-%EB%A7%90%ED%95%98%EC%A7%80-%EB%A7%90%EC%9E%90-387c2babdd75) + - + +# 내 생각 + +- 책에서 주장하는 맥락에 대해선 매우 동의한다. 일단 열심히가 아닌 현명하게 생각하기 위해서 전제조건은 본인 스스로가 능동적으로 업무를 인식하고 진행하는 것이라고 생각한다. 즉, 본인이 윗사람을 통해서 업무를 단순하게 그냥 받아서 요구사항대로 처리만 한다면 현명하게 보다는 열심히에 초점이 맞혀져 있을 가능성이 높다고 생각한다. 그래서 수동적보다는 능동적으로 나 스스로 문제 해결을 어떻게 할 수 있을지를 고민하고, 바텀업으로 먼저 제안하는 방향을 고려해본다면, 자연스레 현명하게 좀 더 가깝게 갈 수 있다고 생각하는 편이다. +- 결국 모든 것을 기승전 문제해결로 보고, 능동적인 자세로 문제를 해결해보려고 해야한다라는 얘기 인데, 개인적으로 조심해야한다고 생각하는 것은 단순히 성과를 높이기 위한 행동을 하는 것을 현명하게 한다고 착각하는 것이다. 꼭 성과를 높이기 위한 어떤 행동이나 실천이 반드시 현명하게 일하는 것이라고 생각진 않는 편이다. 오히려 어떤 면에서는 성과를 높이는게 현명하게 일하는 것이라고 착각하는 사람들 보다 열심히만 하는 사람들이 지금 현재 불필요한 일을 벌리지 않고, 현재 해야할 일에 집중한다는 측면에서는 더 나을 수도 있다고 생각한다. +- 여기서 `현명하게` 라는 말은 어떻게 보면, `상황에 따라서 적절하게` 으로 치환할 수도 있을 것 같다. 흔히 주니어 개발자와 시니어 개발자를 구분 지을 때, 어떤 지식의 수준으로 나누는 경우가 많은데 내 개인적으론, `현명하게` 의 수준으로 생각해볼 수 있지 않을까 생각된다 \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/32.md b/2025/Becoming a Better Programmer/taehyoung/32.md new file mode 100644 index 00000000..1464b3a0 --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/32.md @@ -0,0 +1,9 @@ +# ch32. 끝나야 끝나는 것 + +# 논의 내용 + +- 없음 + +# 내 생각 + +- 책의 내용을 구체화시키면, PO 혹은 기획자로 부터, 요구사항을 전달 받아서, 요구사항을 분석하고, 분석한 내용을 바탕으로 설계를 진행하고, 인수조건을 도출한 다음에 이를 각각 작업 티켓으로 만들어서, 개발하고 인수조건에 맞게 QA 하는 대부분의 개발자들의 업무 flow에 대한 내용을 말하고 있다. 어떻게 보면 되게 당연한 것들인데, 대개의 개발자들은 무의식적으로 그냥하다보니, 각각 스텝별로 어떤 부분을 더 신경써서 처리해야할지에 대해서는 의식적으로 생각해보지는 못하는 것 같은데, 책 내용을 통해서 의식적으로 생각해보고, 본인의 방식을 정리해보면 좋을 것 같다는 생각이 들었다 \ No newline at end of file diff --git a/2025/Becoming a Better Programmer/taehyoung/33.md b/2025/Becoming a Better Programmer/taehyoung/33.md new file mode 100644 index 00000000..19175ba3 --- /dev/null +++ b/2025/Becoming a Better Programmer/taehyoung/33.md @@ -0,0 +1,11 @@ +# ch33. 교훈 얻기 + +# 논의 내용 + +- 없음 + +# 내 생각 + +- 책에서 나오는 짐의 사례는 절대 일어나선 안되는 것으로 보인다 +- 책에 나오는 이러한 문제를 잘 해결하기 위해서는 팀에서의 기준이 중요할 것 같은데, 현재 우리 회사에서는 어떤 장애 상황이 있을 때, 고객에게 심각한 문제를 초래할 수 있다 판단되면, 바로 롤백을 하도록 되어있다. 그리고 분석은 그 이후에 시간을 여유롭게 가지고 한다. 반면에 크리티컬하지 않다고 판단되면, 빠르게 버그픽스를 해서 핫픽스 배포를 한다. +- 장애 분석 시에는 같은 팀원들이 같이 도움을 줄 수 있고, 내가 도움을 원한다면 팀원들에게도 도움을 당연히 요청해야한다. 개발자 스스로 본인이 작성한 코드에 대한 책임감을 가지는 것 또한 중요하지만, 당장의 문제해결을 위해서 도움을 받는게 맞다면, 주저없이 도움을 요청을 해야한다고 생각한다 \ No newline at end of file