경험이 적은 프로그래머에게는 언제 도움을주지 않습니까? [닫은]

주니어 프로그래머가 항상 뛰어 들어 교육을 시도하는 데 도움이 필요할 때 좋은 아이디어라고 생각하십니까? 아니면 그들은 당신이 그들에게 제공하는 모든 "물고기 교육"조언을 무시하고 방금 가져온 "물고기"에 집중할 것입니까? 실수가 배우는 가장 좋은 방법이라는 것을 알고 항상 스스로 스스로 알아낼 수 있도록 하시겠습니까? 아니면 그들이 너무 타거나 좌절해서 속도를 올리려는 욕구를 잃을 까봐 두렵습니까?

언제 당신이 더 후배를 도울 수 있는지, 언제 당신이 언제 서서 실수를 통해 배울 수 있도록 선택합니까?

내 직업 중 하나에서, 나는 배우고 가르치고있었습니다. (물론 모든 것을 알지 못하기 때문에, 나는 그 이상을 알고 있습니다)

하지 마십시오 모든 비용은 키보드에서 손을 놓습니다. 이것은 당신과 당신이 가르치는 사람 모두에게 좌절입니다. 단계별 지침을 제공하더라도 키보드에 손을 대면 코드를 제공하고 "이것이 수정되었습니다"라고 말하는 것과 같습니다.

내가 배운 것에서 :

• 코드를 입력하지 마십시오
• 그들의 수준에서 가르치려고 노력하십시오 (구문을 이해하면 설명하지 마십시오. 단지 그것들을 지울 것입니다. 대신 사용되는 클래스 / 기능을 가르치십시오)
• 그것들을 무시하거나 "자신 만의 그림으로 나타내십시오"라고 말하지 마십시오. 결국 문제가 발생한 3 줄의 코드를 제외하고 나중에 나올 것입니다. 이제 문제를 해결하기 위해 8 줄에 걸쳐 50 줄이 퍼졌습니다.
• 그들 스스로 배우도록 가르치십시오. 가장 좋은 방법 중 하나는 stackoverflow를 사용하도록 지시하는 것입니다. 그들이 나에게 물어 본다면 때로는 대답을 알고 있습니다. 나는 "글쎄, 나는이 질문을 stackoverflow에 대해 물을 것이다"라고 말할 것이다. 그들에게 질문에 대한 링크를 제공합니다. 커피를 마시고 다른 코드를 살펴보십시오. 그들이 "어떻게 문제를 해결합니까?" 나는 대중이 보통 나보다 더 나은 선생님이라는 것을 알게되었다.
• 인터넷에서 코드를 복사하여 붙여넣고 작동하지 않는 이유를 물으면 각 줄의 기능을 설명하도록 요청하십시오. 그들이 할 수 없다면, 사용 된 기능 / 클래스를 조사하도록 지시하십시오. 필요한 경우, 수업과 기능에 대한 설명을 제공하십시오
• 코드 검토를 수행하여 나중에 문제를 해결하기 위해 문제를 해결하는 것이 아니라 문제를 해결하고 있는지 확인하십시오.
• 착하게 굴 어라. 누군가 문서없이 코드베이스에서 시작했을 때 소스 코드를 읽도록 지시하지 마십시오. 해당 기능에 대한 요약 된 고급 개요를 제공하십시오. 또는 더 나은 방법으로 문서 작성을 시작하십시오. :)
• 겸손하라. 문제에 대해 BS하지 마십시오. 당신이 그것을 모른다면 말하지 말고 그들이 찾도록 도와주십시오. 검색 할 키워드를 알기에 충분한 도메인을 아는 것만으로도 많은 도움이됩니다.

소크라테스 방식, 즉 긍정적 인 방향으로 생각하도록하는 질문을한다

[문제가 무엇인지 모르는 경우에도 훨씬 유용합니다.]

나는 그들이 건축가를 세우고 거기서 멈추도록 돕는 법을 배웠다. 올바른 도구를 골라 복잡한 문제에 대한 일반적인 설계를 한두 개 만들어서 해결하십시오. 그들이 돌아와서 조언을 구한다면, 작은 덩어리로 그들에게주십시오. 그렇지 않다면 내버려 두십시오.

당신은 "타고 좌절"에 대해 전적으로 옳습니다. 그들은 당신이 미세 관리 또는 nit-pick 경우 정확히 것입니다. 마지막으로 동료들과 우호적 인 협력 관계를 구축하는 데 많은 도움이됩니다. 신뢰와 상호 존중을 얻는 데 소비 한 시간은 10 배가 넘습니다.

나는 벽돌 벽에 부딪친 것이 분명하고 도움없이 그것을 알아낼 수없는 것이 분명 할 때, 빨리 끝내야 할 것들이 필요할 때 그들을 도와줍니다. 그러나 그들이 무언가를 향한 시간을 투자하지 않았다면 먼저 시도하는 것이 좋습니다.

"물고기 교육"대신 "물고기"를 섭취하는 한, 가장 좋은 방법은 사람들의 문제를 해결하지 않는 것 입니다. 그들에게 아이디어를주고 그것을 실행 시키십시오. 그들이 그것으로 달려 실패하면 더 도움이됩니다. 그들이 성공하면 더 좋습니다.

그들이 좋은 프로그래머라면 스스로 할 수있는 방법을 찾아야합니다. 지금은 정보 나 도움의 손길을 빌려 주어진 문제에 대한 해결책을 찾을 수없는 가까이있는 상황에서 한 같은 이유에서 겉으로 는 이유에서 보관하십시오. 그들에게 답을 숟가락으로 먹이지 마십시오.

아마도 예를 들어 18 살이고 지금은 몇 년 동안 내 자신을 배우고 있으며 내 자신의 컴파일러를 포함하여 몇 가지 미친 것들을 썼으며 나는 스스로 가르쳤다. 나는 적어도 하루 동안 검색하고 실험했지만 아무 소용이없는 것처럼 실제로 붙어있는 것들에 대해서만 도움을 구합니다. 나는 또한 반례를 제시하고 싶다. 프로그래밍 클래스에서 한 번은 학생이 컴파일하지 않은 코드를 디버깅하도록 요청했다.

기본적으로 훌륭한 프로그래머, 심지어 주니어 프로그래머라도 대부분의 문제에 대한 솔루션을 실험하고 연구 할 수 있어야합니다.

나는 멘토를 할 것이지만 그들이 나를 위해 그들의 일을하기를 원한다면 나는 떠난다. 일반적으로 문제를 해결하는 방법에 대한 조언이나 작업 설명을 다시 말하면 먼 길을 갈 수 있습니다. 구글에서 사용해야 할 단어를 알려주는 것만으로도 충분한 도움이 될 수 있습니다. 최대 2 분

최근에 pomodoro 기술을 사용하기 시작했습니다 . 결과적으로 현재 과제에 대한 생각을 잃지 않고 질문에 대답 할 수 없다면, 포모 도로 끝까지 평균 15 분 정도 지연 될 수 있는지 묻기 시작했습니다. 내가 발견 한 이것의 흥미로운 부작용은 질문에 대답하기 위해 책상으로 떨어질 때, 그들은 종종 이미 스스로 해결했습니다. 그들이 그렇지 않은 경우, 그 시점에서 나는 그들에게 내 모든 관심을 줄 더 많은 준비가되어 있습니다.

이것은 학교가 아닙니다. 그들이 결국 스스로 찾을 수있는 사실을 신속하게 제공한다면 속임수가 아닙니다. 반대로, 시간을 절약하는 것은 좋은 사업 적 의미가 있으며, 내 경험상 올바른 방향으로 자주 작은 푸시를주는 멘토에 비해 시행 착오에 의해 기술이 거의 연마되지 않습니다. 차라리 그들은 9 가지의 잘못된 길과 하나의 권리보다 내 도움으로 일을하는 10 가지 올바른 방법을 배우고 싶습니다.

무언가를 쉽게 찾을 수 있다면 그렇게하는 방법을 가르쳐주십시오. 반면에 특정 버그 증상을 조사 할 파일과 같이 경험을 통해서만 알 수있는 것이면 설명 할 수없는 대답을하는 것만으로는 아무런 문제가 없습니다.

반대로, 아키텍처 안내와 같은보다 주관적인 것은 항상 그 뒤에 추론을 동반해야합니다. 우선, 주니어 개발자는 자신의 특정 작업에 대해 더 깊이 생각했습니다. 그것을 통해 이야기하면 결론에 도달하지 않습니다. 또 다른 경우에는 적용되지 않을 미래 상황에 대해 맹목적으로 규칙을 적용하지 못하게합니다.

나는 동료를 계속 돕지 않는 것이 명백한 한 가지 사례에 대해서만 생각할 수 있으며, 몇 시간 동안 무언가를 여러 번 설명하고 몇 가지 예를 겪은 후에야 그녀는 문자 그대로 다음에 입력 할 다음 진술을 알지 못했습니다. 매우 유용한 힌트. 그 시점에서 그녀는 기본에 대한 진지한 재 학습없이 직업을 유지할 희망이 거의 없었으며, 몇 달 동안 만 지속되었습니다.

나는 그들이 같은 질문으로 세 번 돌아올 때 그들을 돕지 않습니다.

나는 그들에게 먼저 기꺼이 도움을 줄 수만 있다면 그들에게 도움을 줄 수 있다고 말합니다. 거기에서 그들은 무료 음식을 위해 다른 연못을 찾으러갑니다.이 경우 보통 잠시 후에 해고됩니다. 또는 그들은 더 많은 것을 위해 돌아 왔을 때 그것에 일하고 대성공을 쳤다.

문맥이 중요하다고 생각합니다.

응답 시간이 중요한 중요한 생산 지원 문제를 다루는 경우 실제로 문제를 배울 수 있도록 많은 설명과 함께 많은 도움을 줄 것입니다.

마감 기한이 덜 민감한 경우 복잡성이 드라이버가됩니다. 물론 기술 수준의 적절한 작업을 할당하여 초보자에게 많은 도움을 줄 수 있지만 연구를 통해 해결할 수있는 경우 정확한 답변을 제공하지 않고 안내하는 것이 좋은 접근법이라는 다른 포스터에 동의합니다. .

그들이 다른 곳을 보면서 쉽게 대답 할 수있는 질문을하면, 나는 그들 자신의 일을하도록 조종합니다. 그 라인들과 함께, 꽤 썩은 프로세스 나 솔루션이 있고 그것들을 노예로 만드는 데 가치가 거의 없다면, 그들이 확인하기에 위키가 없다면 부끄러운 줄 아십시오.

비즈니스에 맞춤화 된 도메인 지식을 이전 할 때 나는 말을하지 않습니다. 가능한 빨리 똑바로 강의하십시오. 초보자는 나중에 나오는 모든 것을 돕기 위해 필요합니다. 비즈니스에 대해 너무 빨리 또는 너무 쉽게 교육받는 것은 없습니다. 나는 한 시간 동안 모든 종류의 트릭을 연주하는 보스가있어 대답으로 이끌어 냈습니다. 저는 새 것이었고 앱이나 비즈니스에 대해 전혀 몰랐으며 프로덕션 지원 문제를 다루고있었습니다. "왜 & # @ $! # @ & (* $ %! 게임을하고 있습니까? 인보이스를 발행하려는 사용자가 답변을 기다리고 있습니다!"

도움을주기 전에 먼저 물어봐야 할 것이 이것에 대해 조사한 것입니까? 그렇다면 그들이 찾은 것을 물어보고 올바른 방향을 가리 키십시오. 그것을 조사하는 것은 종종 저평가이지만 내가 배운 모범 사례 중 하나입니다. 필요한 것에 대한 정보를 찾으면 스스로 배울 수있는 힘을 제공하며, 그들이 먼저 시도해야한다는 것을 분명히합니다.

문제가 더 복잡하다면 어떻게해야하는지 말하지 말고 아이디어를 공유하십시오. 문제에 어떻게 접근 할 수 있다고 생각하는지 물어보십시오.

단서가 없다면 모든 세부 사항을 제공하지는 않지만 시도 할 수있는 솔루션을 충분히 설명하는 매우 기본적인 수준으로 분류하려고하면 알고리즘 이나 플로우 차트 와 같은 유용한 도구가 있습니다.

결론적으로, 학습 과정을 방해하지 않고지도를하도록 노력하고, 배정 된 모든 업무에 대해 항상 그들이 당신에게 의지하도록 도와 주십시오. 시간이 걸리고 비생산적입니다.

나는 그들이 알아야 할 구문과 같은 간단한 것들을 돕지 않거나 그들이 모르면 스스로 이해할 수 있어야한다. 더 복잡한 것이라면 한 번 설명하는 것이 좋습니다.

프로세스 설명이나 조직 / 프로젝트 코딩 표준 등을 설명 할 때는 세 가지 경고 규칙을 사용합니다. 나는 그가 세 번 이상 설명해야한다면 사람이 절름발이라고 생각합니다. 사실 그것은 또한 우리의 평가에서 기준 중 하나입니다.

학습자에게 많이 의존합니다. 나는 그들이 스스로 몇 가지를 선택할 것으로 기대합니다. "이 문제에 직면하여 A, B 및 C 방법을 시도했지만 문제를 해결할 수 없었습니다"라고 생각하면 도움이 될 것입니다. 그들이 단순히 "이 문제에 직면하고 있습니다"라고 생각하고 아무것도하지 않았다면 나는 책으로 돌아가서 해결책을 찾도록 요청할 것입니다.

초보자 프로그래머로서 (현재 Perl과 SQL을 주로 사용하고 a) Perl에 대해 알지 못하고 b)이 작업 전에 SQL을 몇 달 동안 땜질하면서 프로그래밍 질문을 할 때 나는 보여 주려고 노력합니다. 내가 지금까지 한 일, 또는 작동하지 않는 (그리고 디버깅하기 어려운) 경우에는 버그가 있다고 생각합니다. 가능하면 낚시하는 법을 배우려고 노력했습니다.

다음과 같은 상황에서 도움을 중단합니다.

• Google / Stack을 채널링하는 데 익숙한 경우
• 적절한 문서와 의견을 제공했으며 RTFM 단계를 단축하는 경우
• 그들이 더럽고, 코멘트가 없다면, "지금 이것을 해킹하고 나중에 다시 올 것이다"& & £>! $

적절한 문서를 제공하지 않았거나 내가 작성한 도구 / 클래스로 작업하는 경우 도움을주는 것이 내 책임입니다.