영상요약 - 5년만에 구글에서 수석 개발자가 된 방법(주인공들의 이야기)

2024년 10월 4일 · #공부

우연히 알고리즘에 떠서 제목에 끌려 별 생각없이 영상을 틀었다가, 내용도 좋고 이한결님의 매력에 빠져서 한시간 반짜리를 1.0 속도로 꼼꼼히 시청하게 되었다.

이렇게 좋은 인터뷰 영상을 찍어주셔서 주인공들의 이야기 - 장주영 채널에 감사드리고 🙏🏻 좋은 내용을 잊어버리지 않기 위해 간략히 글로 요약 정리해보았다.

더 높은 직급의 엔지니어로 승진 할 수록, 더 큰 스코프의 문제들을책임 져 주기를 바란다.
- 기능 → 시스템 → 전체
페이스북의 Architypes
- Code machine
- Product & Engineering hybrid
- Generalist
- Architect

나의 성과를 정의할 수 있어야 한다.
회사에서 생각하는
- 내 레벨에 대한 기준, 다음 레벨에 대한 기준을 명확히 알고 있어야 한다.
- 매니저에게 다음 레벨로 가기 위해 필요한 피드백(개선할 점)을 요청하라.
팀을 활용해서 임팩트를 내라
- 일을 잘 맡기고 분배
장기적인 프로젝트(년 단위)는 중단 될 확률이 높다. 2-3개월 안에 가시적인 성과를 낼 수 있게 업무를 설계하라.

Requirements(요구사항)를 확실히 하는 것을 일정의 제일 앞에 두라.
- 남들의 의견이 필요한 일
- 협의가 필요한 일
- 사람들과 이야기를 많이 해야하는 시기이다.

일에 대한 목차를 만든다.
- 섹션으로 쪼개고, 하위 단계로 또 쪼갠다.
- 하위 기능들을 나만의 투두리스트로 만든다.
Checkpoint 를 잘 설정해야 한다.
- 일에 대한 Stack 을 얼마나 자연스럽게 쌓을 수 있는가.
- 2000줄짜리 코드 업무를 100줄 단위로 쪼갠다고 했을 때 이걸 어떨게 쪼갤지
동료가 내 PR을 보고 Approve 를 쉽게 누를 수 있도록 하는데에 집착한다.
- 500줄 짜리 PR이라면 기능은 100줄 미만, 테스트 코드가 400줄
- 반대로 생각해서 누가 1,000줄 짜리 코드를 PR 하면, Reject 한다.
  - “당신의 코드를 정확하게 리뷰할 자신이 없어요.“
  - “당신의 코드에 기능적으로 문제가 없다고 말 할 자신이 없어요. 왜? 너무 많은 Changes 를 한꺼번에 넣었기 때문에.”
- 기능 코드는 최대한 100줄 이하로.
- 리팩터링의 경우 리팩터링만 하는 PR을 따로 분리하라.

회사가 나에게 바라는 것들