Conversation
tttghost
requested review from
jongfeel,
TaeHyoungKwon,
hemil0102,
ymkim97 and
dhlee3994
|
우측에 있는 |
![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 @tttghost, 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 author's reflections and notes for the final chapters (34-39) of the book 'Becoming a Better Programmer', along with thoughts on a section covering stories from Korean developers. The notes cover key takeaways from each chapter, personal anecdotes, and proposed discussion points related to the themes of mentorship, teamwork, communication, attitude, and the broader role of a developer.
Highlights
- Chapter 34: People Power: Reflections on the importance of good mentors and colleagues for growth, and a perspective on efficient time usage, favoring side projects over simple overtime.
- Chapter 35: Thinking is Important: Emphasis on mutual obligation and teamwork, illustrated with a personal anecdote about exercising together, relating it to the importance of code readability and collaborative code reviews.
- Chapter 36: Speaking!: Discussion on the importance of communication for developers, contrasting communication with machines (clear, unambiguous) and people (situational), and highlighting the author's preference for face-to-face communication for efficiency.
- Chapter 37: Manifesto!: Agreement with the book's point that change is constant and nothing is absolute in software development, emphasizing the need for developers to remember this.
- Chapter 38: Code Hymn: Reflection on the strength of a team over individual heroes, using Pareto's principle as an analogy, and arguing for focusing on building better teams rather than solely on hiring top individuals.
- Chapter 39: Attitude is Key: Concluding thought that a developer's attitude towards coding is the most crucial factor, agreeing that 'attitude' is the core message of the book, and sharing that a love for development is a personal driving force.
- Stories of 8 Korean Developers: Highlighting the insight that developers have significant non-coding tasks and the value of observing and learning team-player behavior from others.
- Discussion Topics: Two discussion topics are proposed: experiences with passionate and capable developers/being one, and memorable personal attempts at being a team player.
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. ↩
| ### 논의주제 | ||
| >**확산되는 열정, 영감을 주는 동기 부여, 전염되는 책임감** | ||
|
|
||
| 혼자만 잘하는 게 아닌 `열정 + 능력`이 뛰어난 개발자와 일해본 적이 있으신가요? 아니면 이미 그런 개발자이신가요? |
There was a problem hiding this comment.
네 저희 회사에 열정 + 능력 이 좋으신 분들이 많아서, 일은 많이 해보았습니다 제가 그런 개발자인진 잘 모르겠지만, 일단 열정은 있습니다
There was a problem hiding this comment.
같이 일해본적은 없습니다. 저는 그냥 열정만 있는 개발자네요 ㅎㅎ..
| ### 논의주제 | ||
| 내 팀플레이어다운 시도 중 가장 기억에 남는 것이 있으신가요? |
There was a problem hiding this comment.
딱히 기억에 남는 것은 없는 것 같고, 제 개인적으로는 회사에서 일할 때는 의식적으로 개인(나)이 아닌, 팀을 위해서 모든 것을 결정하고 실행해야한다고 생각하고 있습니다
There was a problem hiding this comment.
저는 팀플을 하지 않아서 공유할 수 있는 경험이 없네요ㅠㅠ
| ### 논의주제 | ||
| >**확산되는 열정, 영감을 주는 동기 부여, 전염되는 책임감** | ||
|
|
||
| 혼자만 잘하는 게 아닌 `열정 + 능력`이 뛰어난 개발자와 일해본 적이 있으신가요? 아니면 이미 그런 개발자이신가요? |
There was a problem hiding this comment.
같이 일해본적은 없습니다. 저는 그냥 열정만 있는 개발자네요 ㅎㅎ..
| ### 논의주제 | ||
| 내 팀플레이어다운 시도 중 가장 기억에 남는 것이 있으신가요? |
There was a problem hiding this comment.
저는 팀플을 하지 않아서 공유할 수 있는 경험이 없네요ㅠㅠ
| ### 논의주제 | ||
| >**확산되는 열정, 영감을 주는 동기 부여, 전염되는 책임감** | ||
|
|
||
| 혼자만 잘하는 게 아닌 `열정 + 능력`이 뛰어난 개발자와 일해본 적이 있으신가요? 아니면 이미 그런 개발자이신가요? |
There was a problem hiding this comment.
이직했던 회사마다 열정과 능력이 있는 개발자와 일했던 경험이 있습니다.
저는 열정은 어느 정도 있는 것 같고 능력은 특별하다고 생각하지는 않습니다.
상대적으로 떨어지는 능력은 아닌데, 잘 하는 사람의 능력 만큼은 아닌 것 같아요.
| 동료들과 협업하는 개발자가 되는 내용이 담겨 있어 귀감이 되었습니다. | ||
|
|
||
| ### 논의주제 | ||
| 내 팀플레이어다운 시도 중 가장 기억에 남는 것이 있으신가요? |
There was a problem hiding this comment.
팀을 위해서 개발 프로세스를 체크하거나 변경하고 그게 도움이 되는지에 대한 피드백을 받아서 정착시킨 사례가 있습니다.
1인분의 몫은 해야 한다는 개인의 업무 처리 능력이라고 보면
여러 명이서 효율적으로 개발을 하기 위한 방법 (대표적인 예로 코드 리뷰, 빌드 자동화 시스템 등)을 제안하고 적용해서 발전시켜 나가는 누군가가 있다면 좋은 팀 플레이어라고 봅니다.
결국 한 단어로 귀결되는 책의 내용이 좋았습니다.
460p 연습해보기 상단에 적혀있는
놀라게 될 수 있도록 성실한 태도로 임해 보겠습니다.
좋은 책 추천해주셔서 감사합니다.
Chapter 34 사람의 힘
느낀점
첫 회사에 실력과 인성을 겸비한 선임을 만나길 희망했습니다.
하지만 그러지 못했고 초기 몇 년간 실력 향상이 더뎠습니다.
이직 후에야 훌륭한 선임과 동료들을 만나 좋은 영향을 받으며 성장할 수 있었습니다.
모두가 훌륭한 프로그래머가 되고 싶어 합니다.(아마도?) 그러기 위해서는
시간과 노력, 그리고 좋은 가르침이 필요하다고 생각합니다.
개인의 노력 여하에 따라 다르겠지만 아무리 배우고자 하는 열정이 있어도
좋은 스승이 있을 때 그 노력의 가치는 배로 빛날 것이라고 생각합니다.
야근하면서 일하는 것은 장/단점이 있다고 생각합니다.
장점이라고 한다면 야근의 업무를 처리하는 동안에도 어떤 형태로든 경험이 쌓이기 마련이기에
이런 경험들도 전문가로 가는 방향 중 하나라고 생각합니다.
하지만 야근은 이런 장점보다 효율적인 측면에서 단점이 더 크다고 생각합니다.
보다 관심 있는 개발 분야의 사이드 프로젝트에 시간투자를 하는 것이
야근으로 시간투자를 하는 것보다 좀 더 효율적인 시간활용법이라고 생각합니다.
논의주제
혼자만 잘하는 게 아닌
열정 + 능력이 뛰어난 개발자와 일해본 적이 있으신가요? 아니면 이미 그런 개발자이신가요?국내 개발자 8인의 이야기
느낀점
8인의 개발자들의 이야기 중
훌륭한 프로그래머이자 팀플레이어 되는법을 작성하신 토스의 진유림님의 글이 특히 인상 깊었습니다.그 중에서도
코딩 말고도 개인업무가 있다는 말에 크게 공감했습니다.신입 시절에는 코드짜기에 급급했지만, 이제는 코딩자체보다
그 외의 업무들이 눈에 들어오고 점점 비중이 커진다는 것입니다.
개발업무 외의 업무지만 이 업무들이 거미줄처럼 개발과 연관이 있고 종합적으로
더 훌륭한 프로그래머가 됨과 동시에 팀 플레이어가 된다는 점을 이야기하는 것 같아 좋았습니다.
특히 다른 사람이 팀플레이어다운 행동을 관찰하고 배우는 방법에 대해 적혀있는데 따라서 시도해볼 만한 내용인 것 같습니다.
주어진 업무만 하는 개발자가 아닌, 프로젝트에 진심을 다하고
동료들과 협업하는 개발자가 되는 내용이 담겨 있어 귀감이 되었습니다.
논의주제
제가 알게된 지식들을 가볍게 공유하며 확산시키는 것을 즐깁니다.
새로운 기술이나 새로운 도구를 사용함에 있어서 저는 좋다고 하더라도
다른 사람들에게는 배우는 기회비용 대비 유용할지 안할지를 쉽지 않습니다.
이런 부분에 대한 공유를 접근하기 쉬게 추천하는 것을 잘 하는것 같습니다.
(CI/CD, 테스트코드, AI IDE, 좋은 도구 등...)
내 팀플레이어다운 시도 중 가장 기억에 남는 것이 있으신가요?