모든 일에 최대의 에너지를 쏟을 수는 없다. 허가, 선택, 막힘 해소 (unblock), 정보 공유 (inform) - 이 중 하나를 고를 수 없다면, 그 미팅은 시간낭비일 것이다. 구체적인 날짜를 지정하면 추진력이 생긴다. 무언가 결정하는데 몇 시간이 아니라 몇 주가 걸린다면 그 이유를 들여다보아야 한다. 제품를 검토하지 않고 기능을 출시하지 않듯이, 신뢰성에 대한 논의없이 시스템을 배포해선 안된다. 모호한 경계와 불분명한 계약 (Contract) 들은 더 많은 회의와 슬랙 채널을 만든다. 누가 무엇을 책임지고 있고, 서로 어떻게 의존하고 있는지가 명확해야 한다. 문제를 제기하는 사람과 문제를 해결하는 사람 모두 이슈를 파악해냈지만, 한 쪽만이 신뢰와 자율성을 얻는다. 한 사람이 지속적으로 회사나 팀을 구해내고 있다면, 그것은 영광이 아니라 추락하고 있다는 신호다. "코드가 잘 작동한다는 것을 확인했음"을 일의 종료로 간주하라. 작은 PR은 점진적으로 생각할 수 있게 만들기에, 지식을 조금씩 차곡차곡 쌓아갈 수 있다. 의도적으로 연결고리를 줄이지 않으면 새 팀을 추가해도 아웃풋은 동일하다. 실제로 완료되는 마이그레이션은 세 가지 공통점을 가진다. 지속적으로 관여하는 후원자 (Sponsor), 진정으로 마이그레이션을 주도하는 팀, 그리고 모두가 신뢰하는 명확한 종료일. 이 세 가지가 모두 충족되지 않으면 마이그레이션은 영원히 '거의 완료' 상태에 머물게 되고, 영원히 두 시스템을 책임진다. 가장 훌륭한 것을 선별하는 엔지니어가 이 시대의 최고가 될 것이다. 약속을 지킬 때마다, 실수를 솔직히 인정할 때마다, 남들의 삶을 편하게 해줄 때마다, 당신은 예금을 하는 것이다. 나는 평범한 기술력을 가진 엔지니어들이, 모두가 그들을 신뢰했기에 엄청난 성과를 이루는 모습을 봤다. https://news.hada.io/topic?id=24909 의 후속글입니다.1. 최고의 엔지니어들은 적절한 문제를 고른다
2. 뭘 요구해야 할 지 모르겠다면, 당신은 미팅할 준비가 되지 않은 것이다
3. "해야죠"는 계획이 아니다. "화요일에 할게요"가 계획이다.
4. 느린 코드는 증상일 뿐이고, 느린 의사결정이 진짜 원인이다.
5. 신뢰성 (Reliability) 는 제품의 기능으로 간주하라
6. 팀 간의 인터페이스가 나쁘다면 커뮤니케이션을 잘 할 수 없다
7. 최고의 에스컬레이션은 제안을 곁들이는 것이다.
8. 영웅이 필요없는 시스템을 구축하라
9. 관측 가능성 (Observability) 를 기능의 일부로 여겨라
10. 작은 PR은 친절함이다. 특히 그게 AI가 만든 것이라면.
11. 새 팀을 추가하면 것은 노드 (Node) 뿐 아니라 간선 (Edge) 들도 추가된다
12. 마이그레이션은 절대 그냥 마이그레이션이 아니다
13. AI는 초안을 쉽게 만들고, 취향 (Taste) 은 점점 희귀해지고 있다.
14. 신뢰는 레이턴시 최적화다

1 month ago
16







English (US) ·