개발자 원칙 sprint 10 - 이근주#662
Conversation
Updated chapter headings and added reflections on development experiences.
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a reflection document for the first three chapters of 'Developer Principles,' covering topics like tech leadership and growth through debugging. The review feedback focuses on improving the Markdown document structure by correcting the header hierarchy (adjusting H1/H2 levels to H2/H3), completing an unfinished title for Chapter 2, and addressing an empty section in Chapter 0.
|
|
||
| --- | ||
|
|
||
| # chapter 0 - 선배와의 인터뷰 |
There was a problem hiding this comment.
문서의 계층 구조를 올바르게 유지하기 위해 최상위 제목(#)은 문서 전체의 제목(1번 라인)에만 사용하고, 개별 챕터는 하위 헤더(##)를 사용하는 것이 좋습니다. 또한, 현재 이 섹션은 내용이 비어 있으므로 내용을 추가하거나 필요하지 않다면 섹션을 정리하는 것을 권장합니다.
| # chapter 0 - 선배와의 인터뷰 | |
| ## chapter 0 - 선배와의 인터뷰 |
|
|
||
| --- | ||
|
|
||
| # chapter 1 - 덕업일치를 넘어서 |
There was a problem hiding this comment.
문서 구조의 일관성을 위해 챕터 제목의 헤더 수준을 ##로 조정하는 것을 권장합니다.
| # chapter 1 - 덕업일치를 넘어서 | |
| ## chapter 1 - 덕업일치를 넘어서 |
|
|
||
| 연차가 쌓이면 단순 구현보다 팀을 이끌고 방향을 정하는 역할이 중요해질 텐데, 어떤 자세와 마음가짐을 가져야 하는지 생각해볼 수 있었다. | ||
|
|
||
| ## 논의 주제 |
There was a problem hiding this comment.
챕터 제목이 ##로 변경됨에 따라, 하위 섹션인 '논의 주제'는 ###를 사용하여 계층 구조를 맞추는 것이 바람직합니다.
| ## 논의 주제 | |
| ### 논의 주제 |
|
|
||
| --- | ||
|
|
||
| # chapter 2 - 오류를 만날 때가 |
There was a problem hiding this comment.
챕터 제목이 '오류를 만날 때가'에서 끊겨 있습니다. 원문 제목인 '오류를 만날 때가 가장 성장하기 좋을 때다'로 완성하고, 헤더 수준도 ##로 조정하여 일관성을 유지하는 것을 권장합니다.
| # chapter 2 - 오류를 만날 때가 | |
| ## chapter 2 - 오류를 만날 때가 가장 성장하기 좋을 때다 |
|
|
||
| 그 과정에서 문제를 추적하고 해결하는 능력이 많이 성장했고, 밤새 디버깅하면서 해결해나가는 재미도 있었다. | ||
|
|
||
| ## 논의 주제 |
There was a problem hiding this comment.
챕터 제목이 ##로 변경됨에 따라, 하위 섹션인 '논의 주제'는 ###를 사용하여 계층 구조를 맞추는 것이 바람직합니다.
| ## 논의 주제 | |
| ### 논의 주제 |
jongfeel
requested review from
TaeHyoungKwon,
chichoon,
dhlee3994,
hemil0102,
jongfeel,
tttghost and
ymkim97
|
|
||
| ## 논의 주제 | ||
|
|
||
| 테크 리더가 8명 정도 규모의 팀을 이끄는 상황이라면, 직접 개발보다는 문서를 읽고 방향성을 정리하며 기획자와 소통하는 역할 중심이 되어도 괜찮을까? |
There was a problem hiding this comment.
리더는 그 자리에 있으면 자연스럽게 어떤 역할을 해야 하는지 알게 된다고 봅니다.
실무는 안 한다고 하더라도 그 경험치는 무시할 수 없으니까요.
다만, 정말 아예 손 놓고 몇 년을 방치하면 안되고 기술의 발전이나 새로 들어온 사람들이 추구하려는 업무 방식에 대해서는 이해하려는 자세도 필요하다고 봅니다.
저도 분명 그런 시절이 있었고, 매년 새로운 경험을 가진 신입을 10년 넘게 경험하다 보니 아예 실무에서 손 떼는 건 아닌 것 같다는 생각이 강하게 듭니다.
There was a problem hiding this comment.
제가 느끼기에 요즘 특히나 중간 관리자 계층은 애매한 포지션인 것 같고, 모두가 LLM으로 기획과 개발을 하는 시대에 조직의 비즈니스 성장을 위해서, 계층구조는 비즈니스의 스케일 아웃 차원에서 확실히 비효율적인것을 느끼고 있습니다.
그래서 결국에 방향은 말씀주신 8명 팀보다도 훨씬더 작은 팀이 되지 않을까 생각되고, 그 작은 팀원들 모두가 직급차 없이 동등한 입장에서 개발과 방향성 정하는 것을 같이하게되지 않을까? 생각해 봅니다
| 나의 경우 멘토님과 함께 프로젝트를 진행했을 때가 가장 기억에 남는다. | ||
| 새벽이 지나 아침이 되어도 잠이 오지 않을 만큼 재미있었고, AI가 없던 시절이라 인터넷을 뒤져가며 계속 실행하고 부딪혀 문제를 해결했다. 지금 생각해보면 그 과정 자체에 특유의 낭만이 있었던 것 같다. |
There was a problem hiding this comment.
감사합니다.
그게 벌써 8년 전 얘기이군요.
알려드렸지만 멘토로 활동했던 첫 해의 첫 팀이어서 그 어느 때 보다 저도 열정적으로 했던 것 같습니다.
지금은 열정이 없느냐?의 의미가 아닌 아무것도 모를 때 멘토는 뭘 해야 하지? 라는 마음으로 했던게 더 컸던 것이죠.
3 participants
No description provided.