좋은 질문이란 무엇일까 ?
2024년 3월 12일
좋은 질문이란 무엇일까?
아직도 좋은 질문은 ~이다. 라는 식의 정의를 내리기엔 어려움이 있다.
하지만 어떠한 류의 질문이 흐릿한 질문이고 인스턴트식의 질문인지에 대해서는 우테코에서 치루는 미션들을 통해 조금은 갈피를 잡아가려 한다.
또한 이러한 부분은 알고있음에도 놓칠 가능성이 크기 때문에, 글로써 정리해놓고 계속 되새기며 남은 미션을 임하려한다.
1. 정답을 갈구하지 않는다.
모든 것에는 트레이드 오프가 있으며 적절한 때와 상황이 존재한다.
가령 에러핸들링의 목적을 가진 유틸 함수를 하나 만들었다면 이 유틸 함수의 목적은 재사용성의 극대화일 것이다.
하지만 직접적으로 에러 핸들링을 명시해주는 방법보다 직관성이 떨어질수도 있다.
당사자가 어디에 더 무게를 두고 있느냐에 따라서 어떠한 방법이 더 나은 것인지는 달라진다.
이러한 부분에 대해서 단순히 어떠한 방법이 더 나을까요 ?라는 방법은 질문을 받는 사람의 입장에서 쉽사리 결정해줄수 없는 부분이다.
이럴땐 차라리 본인이 왜 이렇게 기능을 구현했는지, 또 이렇게 기능을 구현했을때 걱정되는 부분은 무엇일지 등 본인에 대한 생각을 먼저 피력하는 것이 더 확실한 피드백을 들을 수 있다.
2. 비교군을 구체적으로 명시한다.
만약 A 방법론을 따라서 기능을 구현했을때, 그에 따른 비교군이 B 방법론이라면 질문을 하는 사람에게 A와 B에 대해서 구체적으로 명시해주어야한다.
단순히 A 방법으로 기능을 구현했는데, 이거에 대해서 어떻게 생각하실까요? 라기보다,
A 방법으로 기능을 구현해보았는데, 이에 관한 장단점은 ~라고 생각합니다. 그래서 B 방법으로 구현을 해볼까 했지만 이에 따른 장단점은 ~라고 생각하여서 A 방법을 채택했습니다. 이에 대해 어떻게 생각하실까요?
라는 질문이 비교군이 존재하기에 답변자 입장에서도 더 명확한 답변을 해줄수 있다.
3. 내가 어디까지 알고 있고, 어디까지 시도해보았는지에 대해서 명확히 기술한다.
질문을 받는 사람의 입장에선 이 사람의 배경 지식이 어디까지인지, 이 사람이 문제를 해결하기 위해 무엇까지 시도해보았는지 당연히 알지 못한다.
그렇기 때문에 질문을 받는 사람도 질문에 대해서 쉽사리 답변해줄수 없다.
질문자와 답변자의 배경지식이 차이가 난다면, 답변을 해주더라도 질문자는 이를 이해 못할 가능성이 크다.
만약 이렇게 된다면 질문자, 답변자 둘다 에너지와 시간을 낭비하는것이 되는 것이기 때문에 처음부터 본인의 상황을 답변자에게 인지시키는것이 효율적이다.
4. 언어화가 힘들다면 시각적 자료를 활용하자.
문제 상황을 묘사하기 위해서 이런 저런 코드블록들을 추가하면서 설명을 덧붙여도 효과적이지 못할때가 있다.
각각 모달에 있는 요소마다 원래는 form-item으로 공통으로 선언해주었었는데,
이러면 첫번째 formItem 요소 안에 모든 요소들이 appendChild 되는 문제가 발생했습니다..
각각 margin이 생기는게 아니고 하나의 margin만 생깁니다.
const formItem = document.getElementsByClassName("form-item")[0];
그래서 불가피하게 각각 요소마다 클래스명을 따로 추가해주어서 각각 appendChild를 해주었는데, 이러한 방식이 맞나? 라는 생각도 들었습니다.
각각 id 값을 주어야하나 ? 라는 생각도 들었는데, 단순히 렌더링만 시키는 함수이다보니 과하다는 생각도 동시에 들었어요!
각각 컨테이너에 요소를 추가 해줘야한다면, 이런식으로 그냥 클래스를 각각 추가해주는 방법이 최선인걸까요..!?
글로 아무리 상세히 설명을 한다해도, 때때로 질문을 받는 사람 입장에서는 알아듣기가 힘들 수 있다.
각각 모달에 있는 요소마다 원래는 form-item으로 공통으로 선언해주었었는데,
이러면 첫번째 formItem 요소 안에 모든 요소들이 appendChild 되는 문제가 발생했습니다..
각각 margin이 생기는게 아니고 하나의 margin만 생깁니다.
const formItem = document.getElementsByClassName("form-item")[0];
그래서 불가피하게 각각 요소마다 클래스명을 따로 추가해주어서 각각 appendChild를 해주었는데, 이러한 방식이 맞나? 라는 생각도 들었습니다.
각각 id 값을 주어야하나 ? 라는 생각도 들었는데, 단순히 렌더링만 시키는 함수이다보니 과하다는 생각도 동시에 들었어요!
각각 컨테이너에 요소를 추가 해줘야한다면, 이런식으로 그냥 클래스를 각각 추가해주는 방법이 최선인걸까요..!?
위처럼 글로써 상세하게 질문을 남겨도 상대방이 이해하기 어려울 가능성이 있다면, 이미지나 다이어그램 등 시각적 자료를 활용해서 질문을 남겨보자.
실제로 인간의 뇌는 시각적 자료를 처리하는데에 매우 효율적이기 때문에, 텍스트를 통해 이해가 되지 않았다 하더라도 시각적 자료를 통한 이해가 이뤄질수도 있다.
5. 최대한 상세하고 친절하게, 단 장황하지 않게 기술한다.
단순히 텍스트만을 통해 본인의 의견을 피력하고 더 나아가 상대방에게 관철 시키는것은 굉장히 어렵다.
그렇기 때문에 텍스트만으로 본인의 의견을 기술할때 내용이 길어질수 밖에 없다.
본인의 의견에 대해서 더 많은 내용들을 추가하기 때문에, 의견에 관한 살이 덧붙여질 수 있다.
하지만 무조건 긴 글이 상대방에게 더 확실한 이해를 가져다주는 것은 아니다.
저는 오늘 아무것도 먹지 못해서 배고픕니다.
저는 오늘 8시에 기상해서, 바로 캠퍼스로 10시까지 출근을 했어요.
수업을 듣고나니 바로 점심 시간이 되었지만, 미션 제출기한이 6시까지였기 때문에 점심을 거르고 페어와 함께 미션에 집중했습니다.
그래서 미션을 제출을 하고 집에 오니 8시가 되었어요.
저녁도 굶은 터라 많이 배가 고픕니다.
결국 말하고자 하는 것은, 본인의 배고픔이지만 이에 대한 배경 설명은 너무 장황하다.
위는 간단한 예이지만 더 나아가서 본인의 코드에 관한 설명과 궁금증을 기술할 때도 충분히 적용 시킬 수 있는 부분이다.
위의 나열한 부분들은 사실 누구나 알고 있으며, 누구든지 지킬 수 있는 부분이다.
하지만 당연시하면 자연스레 놓치게 되듯이, 위의 항목들은 인지하고 있지만서도 동시에 쉽사리 생략될 수 있는 부분이다.
또한 나는 나조차도 모르게 리뷰어는 나보다 실력적으로 한수위이니, 내가 이렇게 말씀을 드려도 이해하지 않으실까?라는 안일한 생각이 내심 기저에 깔려있었던것 같다.
하지만 질문을 잘한다는 것은, 질문을 받는 사람의 실력을 떠나서 사람과 사람사이의 커뮤니케이션 역량임을 깨닫고 반성하게 됐다.
질문 뿐만 아니라 상대방과 의견을 나눌때 조차도, 상대방에게 본인의 생각을 명확하게 이해시키는 것은 개발 분야를 넘어서서 본인 자체의 역량을 높이는 것이라 생각한다.