더 나은 프로그래머 되는법 4주차 - 김영명 #554
Conversation
ymkim97
requested review from
TaeHyoungKwon,
dhlee3994,
fkdl0048,
hemil0102,
jongfeel and
tttghost
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @ymkim97, 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!
Summary of Changes
Hello team, gemini-code-assist here to provide a summary of this pull request. This PR, authored by ymkim97, focuses on documenting the reading and reflections from chapters 24 through 33 of the book 'Becoming a Better Programmer'. The author reflects on the importance of attitude as a developer and person, finding the chapters a valuable opportunity for self-assessment and commitment to implementing the lessons learned. This marks the documentation for the fourth week, approaching the final sprint of the year.
Highlights
- Continuous Learning: The PR includes reflections on the importance of loving to learn, staying in a state of continuous learning, and broadening one's focus beyond narrow technical skills (Chapter 24).
- Avoiding Complacency and Stagnation: Key themes include the analogy between driving and programming to highlight the dangers of complacency once 'conscious competence' is reached (Chapter 25), and the critical need to avoid the 'comfort zone' which leads to stagnation and regression as a developer (Chapter 27).
- Working Smarter and Defining Done: The summary covers principles for being a productive programmer by working 'smarter, not harder', including tips like reusing, prioritizing, and automating (Chapter 31). It also emphasizes the importance of clearly defining when a task is 'done' to avoid unnecessary work and ensure completion (Chapter 32).
- Beyond Technical Skills: The reflections touch upon the ethical responsibilities of programmers (Chapter 28), the value of learning and appreciating multiple programming languages and paradigms (Chapter 29), the importance of physical health and posture (Chapter 30), and the recognition that many development problems are human-centric, highlighting the need to ask for help and learn from others (Chapter 33).
Changelog
- 2025/Becoming a Better Programmer/ymkim97/chapter24~33.md
- Added a new Markdown file summarizing chapters 24 through 33 of 'Becoming a Better Programmer'.
- Includes reflections on continuous learning, avoiding stagnation, ethical considerations, language appreciation, ergonomics, working smarter, defining 'done', and learning from human-centric problems.
- Appends discussion points related to finding motivation and preferred programming languages.
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.
Learn, grow, and reflect,
Chapters read, lessons kept,
A better coder blooms.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
안녕하세요, 김영명님. Chapter 24부터 33장까지의 내용을 꼼꼼하게 정리해주셔서 감사합니다. 각 장의 핵심 내용을 잘 요약하셨고, 인용구를 통해 중요 포인트를 강조한 점도 좋았습니다. 특히 각 장 말미에 개인적인 생각이나 다짐을 추가하신 부분과 마지막의 '논의 내용'은 스터디 그룹에서 활발한 토론을 이끌어내는 데 도움이 될 것 같습니다.
문서 전반적으로 가독성이 높고 체계적으로 잘 구성되어 있습니다. 다만, 몇 가지 사소한 오타와 문법적인 수정 사항이 있어 이를 반영하면 더욱 완성도 높은 요약본이 될 것이라 생각합니다. 자세한 내용은 아래 리뷰 코멘트와 요약된 발견 사항을 참고해주세요.
Summary of Findings
- 문법 교정 (중간 심각도): 119행의 '되야 하고'는 '돼야 하고'로 교정해야 합니다. 이에 대한 리뷰 코멘트를 추가했습니다.
- 사소한 오타 및 띄어쓰기 (낮은 심각도 - 코멘트 미생성): 리뷰 설정에 따라 심각도가 낮아 직접 코멘트하지 않았지만, 다음과 같은 사소한 오타 및 띄어쓰기 오류들이 발견되었습니다:
- 11행: '알지 못한는' (올바른 표현: '알지 못하는')
- 19행: '만지작 거리거나' (올바른 표현: '만지작거리거나')
- 60행: '느께게' (올바른 표현: '느끼게')
- 95행: '겨우가' (올바른 표현: '경우가')
- 107행: '설명 한다' (올바른 표현: '설명한다')
- 141행: '다음어야' (올바른 표현: '다듬어야')
이러한 부분들을 수정하면 문서의 전반적인 가독성과 완성도를 높일 수 있습니다. - 파일 끝 개행 문자 누락 (낮은 심각도 - 코멘트 미생성): 파일 끝에 개행 문자가 누락되었습니다 (diff에서 '\ No newline at end of file'로 표시됨). 다양한 텍스트 기반 도구 및 버전 관리 시스템과의 호환성을 위해 개행 문자를 추가하는 것이 일반적인 좋은 습관입니다. 심각도가 낮아 직접 코멘트하지 않았습니다.
Merge Readiness
책의 내용을 훌륭하게 요약하고 개인적인 성찰까지 담아주신 점이 인상적입니다. 한 가지 문법적 수정 사항에 대해 코멘트를 남겼고, 그 외 몇 가지 사소한 오타들을 발견 사항 요약에 포함했습니다. 이러한 점들을 수정하면 문서가 더욱 정제될 것입니다.
저는 AI이므로 Pull Request를 직접 승인할 권한은 없습니다. 하지만 제안된 수정 사항들이 반영된 후, 다른 리뷰어분들의 검토와 승인을 거쳐 병합하신다면 스터디에 매우 유용한 자료가 될 것이라고 생각합니다.
jongfeel
left a comment
jongfeel
left a comment
There was a problem hiding this comment.
👍
오늘 모임에서 7월 26일에 개최될 Google I/O Extended Incheon 에서 발표자로 선정된 이야기를 해드리면 좋을 것 같습니다.
|
|
||
|
|
||
| ## [논의 내용] | ||
| * 26장의 자극받기에서는 다양한 방법이 소개되어 있습니다. 저 같은 경우에는 다른 개발자를 만나 이야기를 나누거나, 개발 컨퍼런스 또는 모임에 참석하는 것을 좋아합니다. 다른 분들은 어떤 방법으로 자극을 받으시는지, 개발에 대한 흥미를 다시 이끌어내는지 궁금합니다. |
There was a problem hiding this comment.
저도 알려주신 방법으로 자극 받는 걸 좋아합니다.
다른 개발자와 얘기하는 건 서로 어느 수준 까지 알고 얘기하는지 가늠해 보는 좋은 방법이고
컨퍼런스 같은 경우는 GDG 인천/송도의 경우는 1년에 2~3회 참석하고, 사내 스터디 발표 모임도 되도록 매주 진행하고 있고, 제가 주관하고 개최하며 현재 진행중인 독서 모임과 연말 home coming day 행사 등이 있습니다.
그리고 하나 더 추가하면
저는 저보다 능력있는 개발자와 함께 일하는 걸 즐기는데 가끔 그런 능력있는 분들하고 같이 일하면 즐겁기 때문입니다.
There was a problem hiding this comment.
예전에는 제 일상에서 사용할 애플리케이션을 만들고, 직접 사용함으로써, 개발의 흥미를 느꼈는데,
최근에는 문제를 해결한다는 측면에서, 그 절차를 하나씩 직접 해보고, 그 원리를 파악하게 되는 과정이 즐거운 것 같습니다. 그래서 예전에는 공부, 학습의 대상이여서, 지속하기 힘들었다면, 요즘에는 새로운 개념을 알게되는 즐거움의 측면에서 좀 더 지속하기 쉬운 상황인 것 같습니다
There was a problem hiding this comment.
저같은 경우는 멘토링을 받았을 때 입니다.
거의 회사업무에 치우쳐진 삶을 살면서 개발을 좋아하기만 했지 어떻게 해야 할지를 몰랐습니다.
멘토링 때에 그에 대한 방향성을 잡아주셔서 좋았고 지금은 멘토링을 쉬고 있는데
다시 시작할 생각입니다.
|
|
||
| ## [논의 내용] | ||
| * 26장의 자극받기에서는 다양한 방법이 소개되어 있습니다. 저 같은 경우에는 다른 개발자를 만나 이야기를 나누거나, 개발 컨퍼런스 또는 모임에 참석하는 것을 좋아합니다. 다른 분들은 어떤 방법으로 자극을 받으시는지, 개발에 대한 흥미를 다시 이끌어내는지 궁금합니다. | ||
| * 개발자마다 자신이 특히나 좋아하고 애정하는 언어가 하나씩은 있을 것이라고 생각합니다. 각자 어떠한 언어를 그렇게 생각하는지와 이유에 대해서 의논하면 좋을 것 같습니다. No newline at end of file |
There was a problem hiding this comment.
저는 어렸을 때 부터 IBM과 Microsoft의 운영체제, 프로그래밍 언어를 쓰다 보니 선호하게 되었고
제가 특별히 의도한 건 아니지만 개발자 경력의 대부분을 Microsoft의 환경에서 개발했던 적이 매우 많습니다.
그래서 Basic, C++, C# 언어를 자주 써왔고 좋아하는데
특히 C#은 1.0 때 부터 써왔고 현재 23년째 쓰는 언어라 큰 애정을 가지고 있습니다.
1.0 버전은 정말 그 당시 Java 최신 버전이었던 1.4 보다도 한참 못미칠 정도로 형편없는 언어였는데
23년간 여러 언어의 장점(자바, 델파이, C++, 파이썬)을 흡수하면서 동시에
자바스크립트, 타입스크립트에 큰 영향을 주는 언어이고
현재도 사용하고 있는 언어여서 큰 애정을 가지고 있습니다.
There was a problem hiding this comment.
저는 python 입니다
저는 컴공 출신인데, 학교 다닐 때는 프로그래밍이 저에게 정말 적성이 맞지 않았습니다 그때 당시에는 C, C++ 등을 배우면서 이걸로 내가뭘 할 수 있을까? 라는 현타가 자주왔었던거 같은데요
python을 접하면서, 이걸로 내가 해볼 수 있는게 많겠다 라는 생각이 들면서, 처음으로 프로그래밍에 흥미를 가지게 되었습니다
근데, 그 python 언어로 회사에서 업무도 하다보니, python의 어떤 언어적인 철학이나 좋고 나쁨을 떠나서, 저에게는 현재도 가장 최애 언어로 볼 수 있을 것 같습니다
물론, 제가 python을 좋아하는 이유와 별개로, python 언어 자체도 업계에서도 많이 사용되는 굉장히 성숙한 언어이기 때문에 충분히 학습할 이유가 있는 언어라 생각합니다
|
|
||
|
|
||
| ## [논의 내용] | ||
| * 26장의 자극받기에서는 다양한 방법이 소개되어 있습니다. 저 같은 경우에는 다른 개발자를 만나 이야기를 나누거나, 개발 컨퍼런스 또는 모임에 참석하는 것을 좋아합니다. 다른 분들은 어떤 방법으로 자극을 받으시는지, 개발에 대한 흥미를 다시 이끌어내는지 궁금합니다. |
There was a problem hiding this comment.
저같은 경우는 멘토링을 받았을 때 입니다.
거의 회사업무에 치우쳐진 삶을 살면서 개발을 좋아하기만 했지 어떻게 해야 할지를 몰랐습니다.
멘토링 때에 그에 대한 방향성을 잡아주셔서 좋았고 지금은 멘토링을 쉬고 있는데
다시 시작할 생각입니다.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
Chapter 24 ~ 33장
이번 스프린트에서는 개발자로서, 사람으로서의 태도에 대해서 생각할 수 있는 좋은 기회였던 것 같습니다.
책의 내용을 전반적으로 공감하면서도 당연하다는 생각이 들지만 책의 저자가 이렇게까지 작성할 정도면 결국 몇 사람들에게는 그렇지 않다는 것을 알 수 있었습니다.
그래서 그저 동의만 하면서 넘어가기 보다는, 정말 진심으로 책의 내용들을 제가 잘 이행하고 있는지 고민하는 시간이 되었습니다.
어느덧 이번년도 마지막 스프린트를 앞두게 되었네요! 마지막까지 열심히 읽겠습니다ㅎㅎ