Add review of chapter 34 to 39 and interviews and two discussions #564
Conversation
jongfeel
requested review from
TaeHyoungKwon,
dhlee3994,
hemil0102,
tttghost and
ymkim97
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @jongfeel, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request adds the final review notes for the book 'Becoming a Better Programmer', covering chapters 34 through 39, along with summaries and links to related interviews and discussions. It also includes my personal impressions on the book's ending and proposes two topics for group discussion.
Highlights
- Final Book Review Chapters: I've added the review notes for the final chapters (34-39) of the book 'Becoming a Better Programmer'. These chapters cover topics like the power of people, the importance of thinking, communication, declarations (likely Agile-related), code quality, and attitude.
- Related Interviews and Discussions: Included are links and brief mentions of several external articles and discussions relevant to the book's themes, focusing on becoming a great programmer, developer learning, and career growth.
- Personal Impressions: I've shared my thoughts on the book's conclusion, particularly appreciating the emphasis on attitude and reflecting on the 'Declaration' chapter's relevance.
- Proposed Discussion Topics: I've proposed two topics for further discussion: the concept of 'sense of duty' in development (especially self-review practices before code review) and reflections on what defines a 'great programmer' based on the referenced external articles.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configureGemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
2025/Becoming a Better Programmer/jongfeel/Chapter_33_to_39_and_interviews.md
Outdated
Show resolved
Hide resolved
2025/Becoming a Better Programmer/jongfeel/Chapter_33_to_39_and_interviews.md
Outdated
Show resolved
Hide resolved
2025/Becoming a Better Programmer/jongfeel/Chapter_33_to_39_and_interviews.md
Outdated
Show resolved
Hide resolved
2025/Becoming a Better Programmer/jongfeel/Chapter_33_to_39_and_interviews.md
Outdated
Show resolved
Hide resolved
2025/Becoming a Better Programmer/jongfeel/Chapter_33_to_39_and_interviews.md
Outdated
Show resolved
Hide resolved
2025/Becoming a Better Programmer/jongfeel/Chapter_33_to_39_and_interviews.md
Outdated
Show resolved
Hide resolved
| ## 논의 주제 1 | ||
|
|
||
| 저는 35장의 생각이 중요하다에서 의무감에 대해 얘기해 보면 좋겠습니다. | ||
|
|
||
| 코드 리뷰를 통해 코드의 품질 향상에 대한 객관성 확보 외에 | ||
| 코드 리뷰가 자신의 코드 품질을 높이기 위한 의무감의 발현이라고 생각한다는 점에서 좋은 마음가짐이라고 봅니다. | ||
| 아무도 관심 없으니까 혹은 어떻게 코드를 작성하던 요구사항대로 동작은 하니까는 | ||
| 단편적인 의무, 즉 회사와의 계획 관계에 대한 의무만 이행했을 뿐 | ||
| 더 좋은 프로그래머가 되기 위한 의무감 까지는 아니기 때문입니다. | ||
|
|
||
| 그래서 책에서 소개하는 여러 의무감을 가질 수 있는 방법들에 대해 소개해 주는데 | ||
| 각자 어떤 부분에서 그런 걸 느끼는지 자유롭게 애기해 보면 좋겠습니다. | ||
|
|
||
| 저는 코드 리뷰 요청 전 셀프 코드 검토 단계를 한번 가지는데 | ||
| 그게 스스로 의무감을 가지게 하는 데 좋은 방법이라고 생각합니다. | ||
| GitHub를 통한 방법으로 설명하자면 pull request draft를 작성해 두고 commit을 추가하면서 스스로 리뷰를 해 보는 것이죠. | ||
| (저는 draft 기능을 사용하지는 않습니다.) |
There was a problem hiding this comment.
일을 하는 과정 중에 여러가지가 있지만, 개인적으로 가장 중요하게 생각하는 것은 인수조건이고, 저 말고도 같이 일하는 동료들에게도 인수조건을 잘 정의하고, 반드시 지켜야한다는 의무감에 대해서 자주 설파하곤 합니다
인수조건은 내가 이 프로젝트의 작업을 완료 했다는 최종적인 체크리스트이고, 이게 충족되지 않는다면, 서비스를 제대로 만들었다고 말할 수 없기 때문이기도 하고, 인수조건은 고객의 기준에서 작성되기 때문에 B2C 비즈니스를 하는 회사에서는 어찌보면 당연스럽게도 가장 먼저 고려해야할 대상이기 때문입니다
| ## 논의 주제 2 | ||
|
|
||
| 여러 개발자 분들이 생각하는 훌륭한 프로그래머에 대해 쓴 글은 읽어볼 만 하고 | ||
| 각자 생각하는 기준과 방식에 대해서도 객관적으로 바라볼 수 있게 하는 시야를 가지게 하는 것 같습니다. | ||
|
|
||
| 토스 이소영님의 개발자의 학습, 성장에 관하여의 내용은 | ||
| 주니어 개발자의 시각으로 쓴 글이긴 하지만 어느 정도의 경험치를 통해 통찰력을 얻었다고 볼 수 있을 만큼 잘 쓴 글이라고 생가합니다. | ||
| 그래서 제가 정리하면서 저와 같다고 생각하는 부분에 대해 코멘트를 추가했고 그 내용은 아래와 같습니다. | ||
|
|
||
| 추가 정보인데, 이분이 토스에 재직한 기간은 작년 까지였고 그 때 쓴 글을 책으로 낸게 올해였던 것 같습니다. | ||
| 직금은 다른 회사에서 일하고 계시더라고요. | ||
|
|
||
| https://github.com/jongfeel/BookReview/issues/1354#issuecomment-2955857868 | ||
|
|
||
| ``` | ||
| 이 분이 얘기하는 것과 나의 공통점을 찾아 봤다. | ||
|
|
||
| 기록: 정의하기 부분에서 기록에 대한 내용은 없지만 암시적으로 포함되어 있다고 본다. 기록을 바탕으로 측정할 수 있고 측정할 수 있어야 성장을 얘기할 수 있으니까. | ||
| 꾸준함: 마찬가지로 애자일이라는 단어가 없지만 암시적으로 포함되어 있다. 한 번에 많이 하는 것 보다 조금씩 꾸준히 실천하는 건 정말로 강력하고 그 자체로도 동기부여가 된다. | ||
| 루틴: 어떤 특정 시간에 뭘 하는 걸 얘기한다. 특히 점심 시간에 사이드프로젝트나 스터디를 한다는 점에서, 나도 점심시간에 책을 읽는 것과 같은 루틴을 가지고 있다고 본다. 데일리 루틴은 강력하다. 예측한대로 시간을 보내고 기록을 통해 되돌아보고 성장을 얘기해볼 수 있다. | ||
| 속도: 코드 작성을 빨리 하고 싶으면 타이핑 하는 걸 가장 나중에 해야 한다는 걸 얘기하는 걸 보고 상당한 깨달음을 얻으셨구나 했다. 특히, 작은 컴포넌트 단위는 인터페이스를 먼저 생각하라는 부분에서 깨달음이라는 단어로 표현하고 싶어졌다. | ||
| 의지: 문제를 발견하고 공유하는 건전한 분위기 속에서 용기있는 수정이 가능하며, 같이 해결해 나가고자 하는 의지가 있다면 무엇이든 해낼 수 있을 것이다. | ||
| ``` No newline at end of file |
There was a problem hiding this comment.
논의 내용이 책에서 저자가 실천하는 행동과 내가 실천하는 행동의 공통점을 찾아보는 것으로 이해를 했습니다
저도 동일하게 이소영님을 기준으로 봤을 때, 무엇을 학습할 것인가 부분에서 학습을 위한 학습이 아니라, 문제해결을 위한 학습부터 시작해보자가 제가 실제로 실천하는 행동과 비슷하다고 생각합니다
저의 경우는 조금은 다른게 범위를 회사 업무에 훨씬 더 비중을 많이 두는데요
회사에서 경험하는 실무가 가장 순도 높은 현실세계의 문제들이기 때문 입니다 수능에 빗대어서 표현해보자면, 수능 혹은 평가원 모의고사 문제 같은 것이라고 볼 수 있을 것 같습니다
좀 더 확장하면, 집중할 영역, 집중하지 않을 영역 을 기준으로도 말할 수 있을 것 같은데요. 저는 회사에서 겪는 실무와 그 과정에서 발생한 장애는 집중할 영역, 그 외는 집중하지 않을 영역으로 봄으로써, 저자가 프런트 개발 역량을 키우는 것에만 집중하는 것과 같은 맥락에서 학습의 효율성을 추구한다고 볼 수 있을 것 같습니다
There was a problem hiding this comment.
저는 점심시간이 대략 11시 20분 ~ 13시 00분까지인데, 그 시간은 무조건 공부하는 시간으로 정했습니다. 처음에는 점심시간도 쉬지 않고 계속 개발을 하니까 삶이 팍팍하다고 느꼈었는데, 루틴화되고 난 후부터는 오히려 공부를 안 하면 찝찝한 정도가 되었습니다.
저는 소영님과 다르게 집중할/집중하지 않을 영역으로 구분하지 않고, 흥미 여부로 공부하고 있습니다.
이게 좋지 않다는 걸 알고 고쳐보려고 하는데 쉽지가 않네요.
…d_interviews.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…d_interviews.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…d_interviews.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…d_interviews.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…d_interviews.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| ## 논의 주제 2 | ||
|
|
||
| 여러 개발자 분들이 생각하는 훌륭한 프로그래머에 대해 쓴 글은 읽어볼 만 하고 | ||
| 각자 생각하는 기준과 방식에 대해서도 객관적으로 바라볼 수 있게 하는 시야를 가지게 하는 것 같습니다. | ||
|
|
||
| 토스 이소영님의 개발자의 학습, 성장에 관하여의 내용은 | ||
| 주니어 개발자의 시각으로 쓴 글이긴 하지만 어느 정도의 경험치를 통해 통찰력을 얻었다고 볼 수 있을 만큼 잘 쓴 글이라고 생가합니다. | ||
| 그래서 제가 정리하면서 저와 같다고 생각하는 부분에 대해 코멘트를 추가했고 그 내용은 아래와 같습니다. | ||
|
|
||
| 추가 정보인데, 이분이 토스에 재직한 기간은 작년 까지였고 그 때 쓴 글을 책으로 낸게 올해였던 것 같습니다. | ||
| 직금은 다른 회사에서 일하고 계시더라고요. | ||
|
|
||
| https://github.com/jongfeel/BookReview/issues/1354#issuecomment-2955857868 | ||
|
|
||
| ``` | ||
| 이 분이 얘기하는 것과 나의 공통점을 찾아 봤다. | ||
|
|
||
| 기록: 정의하기 부분에서 기록에 대한 내용은 없지만 암시적으로 포함되어 있다고 본다. 기록을 바탕으로 측정할 수 있고 측정할 수 있어야 성장을 얘기할 수 있으니까. | ||
| 꾸준함: 마찬가지로 애자일이라는 단어가 없지만 암시적으로 포함되어 있다. 한 번에 많이 하는 것 보다 조금씩 꾸준히 실천하는 건 정말로 강력하고 그 자체로도 동기부여가 된다. | ||
| 루틴: 어떤 특정 시간에 뭘 하는 걸 얘기한다. 특히 점심 시간에 사이드프로젝트나 스터디를 한다는 점에서, 나도 점심시간에 책을 읽는 것과 같은 루틴을 가지고 있다고 본다. 데일리 루틴은 강력하다. 예측한대로 시간을 보내고 기록을 통해 되돌아보고 성장을 얘기해볼 수 있다. | ||
| 속도: 코드 작성을 빨리 하고 싶으면 타이핑 하는 걸 가장 나중에 해야 한다는 걸 얘기하는 걸 보고 상당한 깨달음을 얻으셨구나 했다. 특히, 작은 컴포넌트 단위는 인터페이스를 먼저 생각하라는 부분에서 깨달음이라는 단어로 표현하고 싶어졌다. | ||
| 의지: 문제를 발견하고 공유하는 건전한 분위기 속에서 용기있는 수정이 가능하며, 같이 해결해 나가고자 하는 의지가 있다면 무엇이든 해낼 수 있을 것이다. | ||
| ``` No newline at end of file |
There was a problem hiding this comment.
저는 점심시간이 대략 11시 20분 ~ 13시 00분까지인데, 그 시간은 무조건 공부하는 시간으로 정했습니다. 처음에는 점심시간도 쉬지 않고 계속 개발을 하니까 삶이 팍팍하다고 느꼈었는데, 루틴화되고 난 후부터는 오히려 공부를 안 하면 찝찝한 정도가 되었습니다.
저는 소영님과 다르게 집중할/집중하지 않을 영역으로 구분하지 않고, 흥미 여부로 공부하고 있습니다.
이게 좋지 않다는 걸 알고 고쳐보려고 하는데 쉽지가 않네요.
jongfeel
deleted the
559-더-나은-프로그래머-되는-법-sprint-5-34장-39장-부록-국내-개발자-8인의-이야기-총-106페이지-2025-06-13
branch
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
마지막 까지 좋은 내용으로 가득찬 책을 읽어서 좋았고
매년 느끼는 거지만 마지막 리뷰 글 까지 적고 나면 올해도 잘 해냈다 라는 생각이 듭니다.
6개월 간의 긴 여정을 잘 해주신 여러분 모두 수고 많으셨습니다.
그 동안 하고 싶은 얘기는 워크샵 때 모여서 맛있는 저녁을 먹으며 얘기하면 좋을 것 같네요.
1년에 단 이틀뿐이고 저의 외박이 허락되는 날이기도 하는 날이라, 많은 분이 참석하셨으면 좋겠습니다.
감사합니다.