How do I ask a good question?
내가 제일 많이 하는 일
개발자는 회사에서 코딩을 압도적으로 많이 할까? 물론 그럴 때도 있지만 항상 그런 것은 아니다. 어떤 날은 문서 정리하는데 시간을 보내는 날도 있고 어떤 날은 오전 내내 연달아 회의만 하는 경우도 있다. 그 때 가장 강력하고 효과적인 능력을 발휘하는 것이 바로 Communication이다. 나는 전 회사가 첫 회사이기에 협업하는 문화가 처음이었다. 😂 나는 모든 일을 혼자서 해 내는 슈퍼 플레이어가 아니었기에 함께 소통하고 더욱 효과적이게 나의 문제와 해결책을 공유하고 상대방의 문제를 파악해 서포트 해줘야했다. 그 때의 나의 사수님이 How do i ask a good question?의 제목의 링크를 보내주면서 이야기했었다.
"혹시 이 링크 읽어보시고 나중에 기회가 될 때 같이 발표를 통해 같이 공유할 수 있으면 좋을 것 같아요!"
아는 분도 있고 모르는 분은 를 들어가 보면 알겠지만 원래 이 글의 주제는 Stack OverFlow에 질문하는 방법에 대한 내용이다.
본래의 주제는 Stack OverFlow에 어떠한 문제나 질문을 올릴 때 이러한 규칙에 따라서 올리면 더욱 당신이 원하는 답변을 빠르고 정확하게 받을 수 있을 것이다. 뭐 이런 내용의 글이지만 인터넷으로 소통하는 것이나 현실에서 소통하는 것이나 오히려 인터넷으로 소통하는 것이 더 한계가 있기에 이러한 큰 틀 안에서 이 글의 내용을 바탕으로 평상시에 커뮤니케이션에 사용해도 좋을 것 같다는 생각에 이렇게 공유하게 되었다.
💁🏻♂️ 열심히 구글과 파파고 그리고 저의 머리가 열심히 일했지만 조금은 섭섭한 독해로 어색한 부분은 댓글 부탁드립니다! 🙇🏻♂️
Action Item
1. Search and research
우선 먼저 그 문제에 대해서 검색을 해보는 것이다. 요즘 구글링을 통해서 얻을 수 있는 정보가 정말 많다. 정보화시대를 살아가는 우리에게 검색 능력을 키우는 것은 정말 필요한 능력 중 하나이다.
그렇게 검색을 하면서 검색의 능력도 키우고 감사하게 그 이슈에 관한 내용을 발견한다면 더 좋고 혹여 찾지 못하더라도 질문을 할 때 그 링크의 방법을 해보았다는 것으로 질문을 구하는 사람에게 불필요한 비용을 줄일 수 있게 되는 것이다.
2. Write a title that summarizes the specific problem
질문의 제목은 문제를 명확하고 구체적으로 요약해서 적어야 한다는 것이다. 보통 사람들은 모든 글을 세세하게 읽지 않는다. 질문의 제목만 보고 흥미를 잃어서 주절주절 쓰여 있는 글은 읽지 않을 확률이 높다.
그렇기에 질문만 보더라도 어떤 문제가 발생했는지 알 수 있게끔 적어야 한다. 잘 이해가 되지 않는다면 아래의 팁을 참고하기를 바란다.
- 바쁜 동료와 이야기 하는 것처럼 문장을 요약한다.
- 철자, 문법, 문장 부호 등이 중요하다.
- 문제의 제목을 붙이기 어렵다면 다른 질문들을 먼저 작성하고 제목을 적으면 문제가 정리되어 더 쉽게 작성 할 수 있습니다.
아랫글로 예시를 들어보겠습니다.
👎🏻 Android에서 if else 오류가 났습니다.
👍🏻 str를 'value'로 선언했는데 왜 str == 'value'가 false로 나올까요?
👎🏻 PHP session이 이상한 것 같다. 잘 안된다.
👍🏻 어떻게 하면 session data를 기반으로 사용자를 다른 페이지로 redirect 할 수 있나요?
👎🏻 현재 가입이 안 돼요.
👍🏻 현재 Sign-up 관련 API가 500 Error를 응답하는데 API에 문제가 있을까요?
별거 아닌 것 같지만 상대방의 되물음에 대한 비용을 줄일 수 있는 좋은 방법이다.
3. Introduce the problem before you post any code
코드를 올리기 전에 문제를 먼저 설명해야 한다. 그런 말이 있지 않은가 기-승-전-결 어떤 이야기는 흐름이 있어야 한다. 앞뒤 사정없이 바로 코드를 올리는 것보다 그때의 상황을 조금 풀어서 설명하면서 그 상황을 포커스 시키는 것이 질문하는 효과적인 방법이다. 그러므로 제목 다음 첫 단락을 신중히 쓰는 것이 중요하다.
4. Help others reproduce the problem
다른 사람들이 해당 문제를 똑같이 재현할 수 있도록 도와야 한다. 코드를 마냥 보여준다고 다 도움이 되는 것은 아니다.
또한 외부에 질문하는 거라면 전체 프로그램을 복사해 올리지 안된다. 만약 회사의 코드를 함부로 올릴 경우 회사와 문제가 생길 수 있고 또한 그 코드에는 독자가 무시해도 되는 정보가 포함되어 있을 수도 있다.
- 다른 사 람들이 문제를 파악하고 재현 할 수 있을 정도의 코드만 올린다. → minimal, Complete, Verifiable code
- 링크 할 수 있는 문제에 대한 코드를 올릴 수 있을 때 올려놓고 질문에도 코드를 복사한다. → codepen 등
- 기본적으로 코드를 텍스트 기반으로 질문을 한다. → 텍스트로 설명이 힘든 다이어그램이나 렌더링 버그의 경우는 이미지 사용
5. Include all relevant tags
질문과 관련된 언어, 라이브러리, API 등 관련 태그 모두 포함 시키기 🤔
6. Proof-read before posting!
게시하기 전에 마지막으로 읽어 보면서 체크하기 👌🏻
7. Post the question and respond to feedback
올려주는 응답을 실행할 준비를 하고 피드백을 할 준비하기 🙂
글을 마치며 👋🏻👀
사실 모두 알고 있는 내용일 확률이 높다. 그저 우리도 모르게 이미 하고 있거나 때때로 눈 앞에 보이는 이슈로 급해진 우리의 손과 마음이 그저 놓치고 있을 뿐이다.
급하면 돌아가라
오히려 당황해서 다급하게 주절주절 설명하는 것보다 어설픈 질문으로 되물음을 반복하는 것보다 저 규칙에 맞게 생각해서 커뮤니케이션 하는 것이 훨씬 서로의 시간을 아낄 수 있고 문제를 빠르게 파악해 답을 찾는 핵심인 것 같다. 우리는 앞으로도 혼자 일하는 날보다는 함께 일하는 날들이 더 많을 확률이 높다. 일 뿐만 아니라 삶이 그런 것 같다. 이 글을 적으면서 이 모든 규칙들이 말하는 것은 그저 상대방을 배려하는 것은 아닐까? 싶은 생각도 들었다. 그러니 앞으로 모든 커뮤니케이션을 할 때 상대방이 이해할 수 있는 언어와 단어 그리고 존중하는 마음으로 소통한다면 나와 함께 일하는 사람들이 상처 받지 않고 더 즐거운 시너지 효과를 낼 수 있지 않을까?