프로그래밍을 갓 시작한 꼬꼬마들은 당연하게도 모르는 게 참 많다. 이럴 땐 혼자 문제를 해결할 수도 있지만 잘 안 풀리면 이 분야를 먼저 접한 사람들에게 궁금한 걸 물어보기도 하는데 이 꼬꼬마들은 거의 대부분 질문을 올바르게 하는 방법을 모른다. 그래서 서로 시간 낭비가 더 심해지고 차라리 내가 시간을 할애해서 블로그에 글을 남기는 게 오히려 시간 낭비가 적어지겠다 생각해서 글을 남긴다.
TL;DR
- 웬만한 프로그래머들은 꼬꼬마 후배들이 물어보는 거 잘 답변 해주려고 하지만 너의 질문 방법은 너의 의도와는 다르게 시간 낭비도 심하고 질문 자체도 제대로 된 게 아님.
- 괜한 절차 섞지 말고 인사와 함께 질문에 대한 간략한 설명을 동시에 첨부한다. 평소에 질문 자주 주고 받았으면 처음부터 질문을 통째로 첨부해도 괜찮다.
- 일단 본인이 궁금한 게 뭔지 본인부터 알아야 한다. 그리고 자세한 상황 설명은 필수다.
일단 웬만한 프로그래머들은 후배가 질문을 하면 기특해 하며 잘 알려주려고 하지 귀찮다고 버리지 않는다. “내가 사업을 하려는데 프로그래머가 필요하고 어쩌고~” 하는 노답이 아니라면 말이다. 다만 질문을 똑바로 하지 못하는 상황에 답답해 할 뿐이다.
첫번째로 가장 이해가 안 가는 건 “궁금한 게 있는데 질문 해도 되나요?”다. 질문을 해도 되냐는 그 질문을 이미 던진 것부터가 이미 모순이기도 하지만 저런 질문을 받는 당사자 입장에선 “선생님이 교무실로 잠깐 오라신다”를 들었을 때와 같은 심정이 된다. 내가 사고라도 친 게 있나, 어제 내가 뭘 했나 온갖 생각이 드는 것도 있고 사람의 정체성이 프로그래머 달랑 하나만 들고 사는 게 아니다. 프로그래머로 살면서 아이를 기르기도 하고 취미로 요리를 하기도 한다. “궁금한 게 있는데 질문 해도 되나요?” 같은 의미 없는 말은 집어 치우고 최소한 “프로그래밍 관련해서 궁금한 게 있어 여쭤보려고 하는데 혹시 시간 되시나요?”라고 물어봐야 한다. 내가 진짜로 궁금해서 저런 의미 없는 질문을 왜 하냐 물어봤더니 “답변을 해 줄 시간이 되는지”를 먼저 예의 차려서 물어보는 거라고 들었다. 차라리 명확하게 물어보자.
남의 시간을 뺏는 게 미안해서 저렇게 묻는 심정은 이해 한다. 하지만 저런 방식도 사실 시간 낭비를 몇십 분 단위로 더 생기게 한다. 흔히 보이는 대화를 예시로 들어보자.
나 질문이 있는데 해도 돼?
(10분 지나서 확인했음)
– (질문이) 뭔데?
(또 5분 지남)
프로그래밍 과제 하다가 궁금한 게 생겨가지고
– 그니까 그 질문이 뭐냐고
(몇 분 지나서 초점도 안 맞는 과제 사진 찍어 옴)
이게 궁금해
– 일단 과제가 뭔지는 대충 알겠는데 그래서 니가 궁금한 부분이 뭐냐고
(여기서부터 비로소 의미 있는 진짜 “질문”이 나온다)
이 대화를 보면 대체 시간이 얼마나 낭비 되는지 이해가 갈 거라고 믿는다. 방에서 자기 전에 혼자 영화를 보다가 엄마가 “~아 잠깐 와 봐” 해서 가 봤더니 “이제 잘 시간이니까 불 끄고 자”라고 말 한 것과 비슷한 시간 낭비다. 애초에 “잠깐 이리 와 봐” 할 노력으로 처음부터 “불 끄고 자” 하면 되는 걸 굉장히 짜증이 나게 만든 상황이다. 조금 친한 사이라면 저런 심각하게 비효율적인 절차는 진행하지 말고 처음부터 과제가 이건데 이 부분을 모르겠다고 하자. 조금 덜 친하면 “~과목 과제 하다가 궁금한 게 생겼는데 물어봐도 되나요?”라고 하자. 최소한 내가 5분이 지나고 봤을 때 내가 모르는 과목이라면 더 시간 낭비를 안 하고 바로 잘 모르는 거라 미안하다고 말 할 수도 있다.
그리고 제일 중요한 건 이거다. 당신이 궁금한 게 뭔지 본인조차 모르는 상태로 질문 하지 마라. 과제를 하다 안 된다고 들고 왔으면 최소한 자신이 어느 위치인지는 알아야 내가 답변을 해 줄 것이다.
- 문제는 이해 했는데 하다가 중간에 막혀서 해결법을 모르는 상태.
- 문제는 이해 했는데 처음 접근을 어떻게 해야 하는지 모르는 상태.
- 문제가 뭘 원하는지 아예 모르겠는 상태.
이 중에 자신이 어디에 속해 있는지 정도는 알아야지 그것도 아닌 “내가 어느 상태인지 모르겠는 상태”라면 선배에게 질문을 할 게 아니라 자기 자신에게 질문을 해야 할 단계다.
한 가지 더 있다. 당신의 머리 속에 존재하는 이해의 형태는 타인의 머리 속에 존재하지 않습니다. 벽돌로 집을 지으려고 하다가 딱풀로 벽돌이 잘 안 붙어서 선배에게 물어보고 싶은 상황은 충분히 있다. 초보자인데 딱풀이 아니라 시멘트를 써야 한다는 걸 모를 수도 있지. 근데 다짜고짜 “선배, 딱풀로 벽돌을 붙이려면 어떻게 해요?”라고 질문을 하면 절대로 제대로 된 답변이 나올 수가 없다. 선배는 아마 얘가 대체 왜 그런 짓을 하려는지 모르겠으나 일단은
그렇게 해야 한다니까 딱풀에 본드를 섞어 보라든가 이상한 답변을 하게 된다. 배경 상황이 되는 “제가 벽돌로 집을 지으려고 하는데 딱풀로 벽돌이 잘 안 붙네요, 어떻게 하는 게 좋을까요?”라고 물어본다면 그제서야 상황을 파악하고 “딱풀 말고 시멘트를 써봐”라는 제대로 된 답변이 나올 수 있는 것이다. 꼭 시멘트가 아니라 딱풀로 해야 하는 게 맞는 상황이라면 “교수님이 벽돌을 딱풀로 붙여보라는데 혹시 좋은 방법 있을까요?”라고 이유를 붙이는 것도 좋다. 안 그러면 “아니 딱풀로 벽돌을 어떻게 붙여! 시멘트 써!” 하게 되는 것이다.
그럼 마지막으로 제대로 된 질문의 예시를 하나 적고 끝내겠다.
저 C언어로 구구단 짜는 과제를 하다가 막힌 게 있는데 혹시 시간 되시나요? (“하다가 막힌 상태”라는 본인의 상황, C언어 구구단 과제라는 세부 주제를 미리 알렸다.)
– 어디서 막혔는데?
교수님이 for문을 쓰지 말고 while을 사용해보라는데 while문으로 초기화, 증감식을 어떻게 써야 하는지 모르겠어요. ( 시멘트 말고 딱풀을 써야 하는 배경 상황 설명, 자신이 막힌 부분 설명)
이런 방식이라면 굳이 40분을 낭비하지 않고 5분만에 문제가 해결 될 수 있다.