💡 선한 엔지니어링 (Kind Engineering) -1

The Staff Engineer's Path, 한국에서는 "개발자를 넘어 기술 리더로 가는 길"이라는 제목으로 출간된 책에서 소개된 "선한 엔지니어링(Kind Engineering: How To Engineer Kindness)" 글을 번역 요약해봅니다. 양이 많아 1,2부로 나눠 작성합니다. What Is Kindness? “Kind is about being invested in other people, figuring out how to help them, meeting them where they are.” - Tanya Reilly,Squarespace * 친절은 타인에게 투자하고, 그들을 도울 방법을 찾아내고, 그들이 있는 곳에서 그들을 만나는 것입니다. "친절함(Kindess)"은 정의하기 어려운 개념으로, 스퀘어스페이스 프린시플 엔지니어 Tanya Reilly 의 정의를 빌렸습니다. 친절함은 그들이 있는 곳에서 그들을 만나는 것이고, 상대방의 입장을 고려하고, 그들의 감정과 배경을 고려하여, 도움을 주려고 노력하는 것 입니다. 즉, 공감과 좋은 커뮤니케이션 그리고, 당신과 당신의 동료에게 솔직해지는 것 입니다. 한가지 인지해야할 사실은 친절함은 조직의 모든 문제를 해결할수 있는 만능 해결책은 아니며, 이에 대한 형태와 생각은 개인차가 있을수 있습니다. * Be Kind, Not Just Nice "친절함(Niceness)"은 "공손함(politeness)"와 동일시 될수 있습니다. 다만 공손함은 외적인 태도, 즉 상냥하고 친절한 태도에 관한 것이며, 친절함은 누군가를 돕기 위해 더 적극적인 역할을 하고, 투자하는 것입니다. * Give & Take: There Are 3 Types Of People In This World 친절함의 혜택들에 대해 설명하기 위해서, 제가 좋아하는 "Give and Take"얘기를 하려고 합니다. Adam Grant의 저서 "Give and Take"에서는 세상에는 3가지 타입의 사람이 있다고 합니다. 1. Takers(주는 것보다 더 많이 받는 사람) 2. Matchers(받은 만큼 주는 사람) 3. Givers(주는 사람). 이 책에서는 Giver가 되는것의 장점과 지속 가능한 기여에 대한 방법에 대해 얘기합니다. 기버의 장점은 더 생산적이고, 더 성공적이고, 더 행복해지고, 더 많은 의미있는 네트워크를 가질수 있다는 것입니다. Honesty 정직은 신뢰와 건설적인 비판을 만들어냅니다. 이는 배우고 도움을 받는데 중요한 부분으로, 사람들을 더 잘 이해하고, 그들이 어디에서 왔으며, 어떤 사람인지 어떤 도움이 필요한지 파악하기 위한 기초로, 도움을 줄 사람을 만나기 위한 초석입니다. 일에서 정직함과 신뢰를 구축하는 것은 중요합니다. 솔직하지 않은 피드백은 건설적이거나, 도움이 되지 않을수 있습니다. 선의의 거짓말은 사람들의 성장에 도움이 되지 않습니다. 최대한 정직한 피드백으로 동료에게 도움이 되도록 노력해야 합니다. 상대방에 솔직하게 잘한 일은 칭찬하고, 개선할수 있는 사항과 방법을 명확하게 제시해야 합니다. Async Communication - Code Review 비동기 커뮤니케이션에는 Pull Request/Code Review라는 강력한 도구가 있습니다. 이것을 단순한 확인사항으로 간주해서는 안 됩니다. 대신, 변화와 그 배경을 완전히 이해할 때까지 심층적으로 파고들어야 합니다. 변화의 이유(The Why)를 이해하기 위해서 노력하고, 단지, 무엇(What)과 어떻게(How)만 아니라, 왜 이부분이 삭제, 재 사용되었는지, 왜 이 함수를 여기에 두었는지 조금 더 깊이 들어가 이해해야 합니다. 잠시 그들의 입장이 되어서 왜 우리가 이 변화를 만들고 있는지, 왜 이렇게 하는지 생각해 보세요. 더 깊이 파고들면서, 악의나 무능을 가정하지 마세요. 무언가를 놓치고 있을 수도 있다고 가정하고 명확한 설명을 요청하세요. "이건 잘못됐어"나 "우리는 이렇게 해" 같은 말을 무턱대고 하지 마세요. 당신이 무언가를 놓치고 있거나, 이해가 잘못될 수도 있다는 가능성에 열려 있어야 합니다. 강한 의견을 주장하기보다 개방적인 질문을 하세요. 개방적인 질문으로 사람들은 당신이 가질 수 있는 이해를 채울 수 있고, 이는 그들이 당신에게 왜(The Why)를 더 잘 설명할 기회를 제공합니다. 이는 팀이 가진 어떤 "표준"으로 그들을 강제로 끌고 가는 것이 아니라, 그들이 있는 곳에서 그들을 돕기 위한 것입니다. 소소한 지적사항(Nitpicks)은 팀 표준과 일치시키기 위한 친구입니다. 이들은 필수적이지 않지만 좋을 변화들, 예를 들어 코드 스타일 변경 같은 것들을 지적하는데 유용합니다. 이런 소소한 지적을 할때는 코멘트를 달아주면 좋습니다. 'nitpick:' 이렇게요. 기한이 임박한 프로젝트에서 타협이 필요하다면 건너뛰는 선택을 하거나, 여유가 있다면 수정할수 있도록 하기 위함입니다. 이야기할게 많다면, 동기 커뮤니케이션으로 전환해보세요. GitHub, pull request에 코멘트가 너무 많으면 리뷰를 받는 대상은 공개된 자리에서 전시되는 느낌이 들어 자칫 굴욕감을 느낄수 있습니다. 이를 막기위해 많은 설명이 필요할 경우, 직접 대화 같은 동기 커뮤니케이션을 사용하세요. 📚 ref: http://kind.engineering 2부는 곧.. ;)