주니어 개발자를 멘토링하는 방법 다른 선임 개발자는 여기서 시작하는 새로운 개발자를

이 제목은 약간 광범위하지만 질문을 제대로하기 전에 약간의 배경 지식을 제공해야 할 수도 있습니다.

나는 비슷한 문제가 된 것을 알고 물어 여기에 이미. 그러나 제 경우에는 누군가를 멘토링 해야하는지 또는 소프트웨어 개발자가되기에 적합한 지 묻지 않습니다 . 그것은 내가 판단 할 곳이 아니다. 나는 똑바로 묻지 않았지만 나 자신과 다른 선임 개발자는 여기서 시작하는 새로운 개발자를 멘토링해야합니다. 나는 이것에 아무 문제가 없으며, 많은 경우에, 그것은 나에게 새로운 관점을 제공하고 그 과정에서 배우게됩니다. 또한, 누군가가 저에게 무언가를 가르쳐주기 위해 시간을 할애했을 때, 제가 경력을 시작했을 때 얼마나 유익했는지 기억합니다.

내가 “새로운 개발자”라고 말하면 대학 밖에서 1 년 또는 2 년의 경험을 쌓을 수 있습니다.

최근에 우리는 개발 / 프로그래밍에 대한 태도를 가진 사람들을 여기에서 시작해 보았습니다. 그들은 작업을 수행하기에 충분한 정보 만 추출하지만 실제로 학습하지는 못합니다. 나는 그들과 같은 문제를 계속 반복하고 있습니다. 나는 이것의 일부가 성격 일 수 있다는 것을 이해하지만, 내 날개 아래있는 동안 최선을 다하고 둥지 밖으로 밀어내는 것이 내 일이라고 생각합니다.

그들이 배울 수는 있지만 문제를 해결할만큼 많이주지 않을 수 있도록 충분한 정보를 어떻게 전달할 수 있습니까?

또는 아마도 :

가장 저항이 적은 경로를 취하고 본질적으로 쉽게 빠져 나가는 대신 배우도록 강요하도록 설계된 질문에 대한 올바른 답변은 무엇입니까?

이러한 질문은 아마도 일반적인 교육 질문 일 수 있으며 소프트웨어 개발과 관련이 없습니다.

참고 : 나는 그들이 어떤 작업을하고 있는지에 대한 언급을 얻지 못했습니다. 경영진은 업무를 처리하고 매우 간단한 버그 수정부터 전체 응용 프로그램 자체 시작에 이르기까지 다양한 작업을 수행 할 수 있습니다. 이것은 이상적인 방법이 아니며 분명히 도전 과제를 제시하지만 다른 질문에 가장 적합한 주제라고 생각합니다. 따라서 내가 할 수있는 최선의 방법은 문제를 해결하고 더 간단한 문제로 나누고 커밋 로그를 확인하고 실수를 지적하는 것입니다.

나의 주요 목표는 다음과 같습니다.

  • 그들을 도와주고 더 자립하기 시작하는 데 필요한 도구를 제공하십시오.
  • 올바른 방향으로 그들을 조종하고 나쁜 개발 습관을 일찍 깨십시오.
  • 내가 그들과 함께 보내는 시간을 줄이십시오 (위에서 설명한 성격 유형은 일대일로 훨씬 더 많은 시간이 필요하고 IM이나 전자 메일보다 잘하지 않습니다. 일반적으로 괜찮지 만 항상 내가 무엇을 멈출 수는 없습니다 나는 일하면서 내 걸음을 깨고 순간 통지로 오류를 디버깅하도록 도와줍니다.


답변

여기에 이런 종류의 정보가 들어있는 질문이 있었고, 가장 많이 붙어있는 부분은 키보드를 건드리지 않았습니다.

요컨대, 후배 에게 그들이하려는 일을 성취하는 방법 을 알려주십시오 .

그러나 그 외에도 다음과 같은 다른 팁이 있습니다.

  • Google (또는 다른 검색 도구)을 장려하십시오. 답을 온라인에서 쉽게 찾을 수 있다는 것을 알고 있다면 답을 말하는 대신 찾아 보라고하십시오. 궁극적으로 당신은 그들에게 자신을 가르치는 방법을 가르치기를 원하며 그들이 당신에게 의존하지 않도록하십시오.
  • 질문에 대답 할 수 있도록하십시오. 당신이 이용 가능하지 않거나 방해 받고 싶지 않다면, 그들이 특정 시간까지 질문을해야한다는 것을 분명히하십시오.
  • 그들이 옳고 그른 일을 알려주기 위해 정기적으로 코드 검토를하십시오. 모범 사례를 지적 할 수있는 기회로 이것을 사용하십시오
  • 모범 사례로 일찍 시작하십시오. 나중에 방법을 바꾸고 시도하는 것보다 올바른 방법을 가르치는 데 더 많은 시간이 걸리는 것이 좋습니다.
  • 코드 작성으로 시작하는 대신 수행 할 작업을 계획 / 문서화하여 조기에 시작하십시오.
  • 그들로부터 배우는 데 개방적입니다. 그들은 아마도 당신이 배우는 것보다 더 많은 시간을 소비하며, 당신이 모르는 것을 배울 수도 있습니다.
  • 그들이 실수로부터 배우도록 도와주십시오. 실수가있을 것이므로 실수가 학습의 일부이며 실수를 학습 기회로 사용해야한다는 것을 보여주십시오.

  • (아래 RuneFS에서) 그들에게 무언가를하는 방법을 알려주는 대신 스스로 알아낼 수 있도록 도와주십시오. 이것은 문제를 통해 논리적으로 일하는 능력을 향상시키고 학습 능력을 향상시키는 데 도움이됩니다.

  • (아래의 RuneFS에서) 잘못된 점을 알려주는 대신 개선 할 수있는 방법을 알려주십시오. 당신의 길이 그들의 길보다 더 나은지 포함 시키십시오. 이렇게하면 약화되는 대신 자신감이 높아집니다. 물론, 그들이 당신의 말을 듣지 않는다면 올바른 방법으로 말하라고 두려워하지 마십시오. 🙂

답변

약 4 년의 경력 이 있으며, 멘토링 측면에서 내가 원하는 것을 주니어 개발자로서의 경험에서 알 수 있습니다 . 내가 시작했을 때의 개발자 유형을 실제로 설명하고있는 것 같습니다 🙂

본질적으로 당신은 그들이 배우도록 격려하고 싶습니다. 어떤 사람들은 대학을 졸업 한 후에는 더 이상 책을 읽거나 배울 필요가 없다고 생각합니다. 이런 종류의 태도는 지름길을 찾고 “완료”하는 결과로 이어질 수 있습니다.
그들에게 “실용적인 프로그래머”를 얻고 그것을 읽게하십시오. 이 책은 프로그래밍이 직업이 아니라 기술 / 경력이라는 것을 깨닫도록 도와 줄 것입니다. 매 분기마다 읽을 수있는 책을 추천하십시오. Pragmatic Programmer에 언급 된대로 “지식 포트폴리오”를 구축하도록 도와주십시오. CS / 프로그래밍 책이 많은 Safari Books Online 을 강력히 추천 합니다 .

지식 포트폴리오를 통해 문제가있는 경우 어디를 볼지 알 수 있습니다. 볼 곳을 가르쳐주십시오. 나는 최근에 StackOverflow의 유용성을 발견했다.

많은 시간을 할애 할 수 없지만 페어 프로그래밍은 매우 유용합니다. 그렇게 할 수 없다면 최소한 CodeCollaborator 또는 다른 유사한 도구를 사용하여 코드 검토를 수행하십시오. 생각보다 시간이 많이 걸리지 않습니다.

단위 테스트도 매우 중요합니다. 특히 지속적으로 통합하여 나쁜 개발 관행을 신속하게 밝힐 수 있습니다.


답변

단순히 그에게 말하지 말고 대답을 이끌어 내도록 주도적 인 질문을하십시오. 답을 찾는 방법을 보여주십시오.

코드가 잘못되었을 때 코드를 다시 쓰지 말고 무엇이 잘못되었는지 알려주고 코드를 고치도록 기대하십시오. 당신은 당신이 기대하는 것을 얻습니다. 당신은 그를 당신에게 의지하게함으로써 누군가를 도와주지 않습니다.

코드 검토도 중요합니다. 그리고 프로그램을 페어링하면 키보드를 자주 갖도록하십시오. 무엇을 타이핑해야하는지 말해도, 프로그래밍하는 동안 옆에 앉아 배우는 것보다 타이핑을 더 많이 할 수 있습니다.

응용 프로그램이 어떻게 구성되어 있는지 전형적인 소프트웨어에서 몇 가지 예를 들어 각 행이 필요한 이유와 그 동작을 이해하도록 한 줄씩 살펴보십시오. 코딩 표준과 코드 구성 방법 및 회사 (귀하의 회사)가 자신이하는 방식으로 일을하는 이유를 알도록하는 것이 귀하의 임무입니다.

그가 제안 할 다른 방법이 있다면, 잘 들으십시오. 처음에는 그가 옳을지도 모른다. 두 번째로, 듣는 것이 그가 제안한 것이 실용적이지 않다면 이해의 약점이 어디에 있는지 알려줄 것입니다. 또한 사람들은 당신이들을 때 더 존경하는 경향이 있습니다. 그가 틀렸을 때, 주요한 질문으로 돌아가서 왜 그 생각이 틀렸는 지 스스로 알아볼 수있게한다. 그가 옳은 일에 가까워지면 때때로 그의 아이디어를 가지고 가십시오. 당신의 아이디어가 가치가 없다고 항상 말하는 것보다 더 낙담하지 않습니다.

그의 배경에 대해 질문하십시오. 그는 당신이 일할 기회가 없었던 것들을 알고있을 것입니다. 그렇다면 그리고 그것들을 사용할 기회가 오면 그의 지식에 대해 질문하십시오.

응용 프로그램이 전혀 오래된 응용 프로그램 인 경우 새로운 사람이 알 방법이없는 것보다 비열한 “gotchas”가있을 수 있습니다. 따라서 이러한 문제가 하나 이상있는 영역에서 작업을 시작할 때 코딩하기 전에 속도를 높일 때 그에 대해 이야기 한 다음 코딩 할 때 문제가 발생했는지 확인할 수 있습니다.

마지막으로, 당신은 존중함으로써 부분적으로 존경을 얻습니다. 멘토하는 모든 사람을 정중하게 대하십시오. 그들이 어리 석거나 멍청하게 느끼지 않도록하십시오. 그들은 당신이 그들을 존중한다면 더 잘들을 것입니다.


답변

  • 나는 항상 개발자가 내 도움을 원하는지 확인하고 인내심이 용납 할 수있는 것보다 설명에 더 깊이 들어 가지 않도록 각별히주의한다. 다른 사람들처럼, 나는 내 목소리의 소리를 좋아합니다!
  • 나는 그들을 평등 한 것으로 취급하고, 나는 소리를 낼 때마다 그들의 의견을 묻습니다.
  • 그들이 옳은 일을하고 그들에게 알려주십시오.
  • 나는 내가이 일을 올바르게 할 때, 내 기술, 직업, 개발자 및 교육에 대해 항상 무언가를 배웁니다.
  • 첫 번째 교훈은 항상 : 자신이 너무 오래 시도한 사실을 알아야 할 때입니다. 많은 사람들이 자신의 답을 찾는 것에 자부심을 갖고, 소중한 시간을 원 안에 보냅니다.

답변

저는 주니어 개발자이며 멘토가 이러한 것들을 잘 다루고 있다고 생각합니다. 일반적으로, 그는 나에게 무언가를하는 몇 가지 방법을 말해 줄 것입니다. 그런 다음 거기에 앉아 두 가지 방법을 모두 사용해 보았고 어느 것이 문제에 대한 가장 깨끗한 해결책인지 결정했습니다.

또한, 그가 나에게 도움이 될만한 일을한다면, 그는 자신이하고있는 일과 이유를 살펴보기 위해 전화를 걸었습니다.

이로 인해 소량의 시간이 나와 함께 보내졌으며 본질적으로 올바른 답변과 구현 방법을 스스로 배워야한다는 것을 의미했습니다. 물론, 만약 내가 갇히게된다면 그는 도와 주러 갈 것이지만 이것은 소수의 시간이었습니다. 그와 함께 일한지 5 개월 만에 대학 과정 전체보다 더 많은 지식을 얻었을 것입니다.

기억해야 할 중요한 것은 내가 단지 개인이고 이것은 내가 어떻게 그리고 그가 어떻게 되었기 때문에 나를 위해 잘 작동했다는 것입니다. 두 사람 모두에게 도움이되는 적절한 구조를 찾는 것입니다.


답변

주어진 작업에 따라 몇 가지 다른 접근 방식을 원합니다.

  • 과제를 완수하기 위해 다음에 무엇을 시도 할 것인지 물어보십시오. 이것은 “무엇을해야할지 모르겠다”에서 “글쎄, 시도해 볼 것입니다 …”카테고리에 대한 아이디어를 제공 할 수 있습니다. .

  • 그들이하고 싶은 일을 빠르게 살펴보고 문제를 파악할 수 있도록 힌트를 제공하십시오. 이것은 “이 코드 라인을 꺼내십시오”라는 대답을하기보다는 그들이 무엇이 있는지 살펴보고 모든 것이 필요하다는 것을 제안합니다.

  • 첫 커플이 효과가 없다면 문제를 해결하기 위해해야 ​​할 일에 대한 지시를 따르도록 노력하겠습니다. 이것은 어디에서 시작할지 모르고 힌트가 작동하지 않는 경우 다음 단계입니다.

  • 마지막으로, 다른 것이 효과가 없다면 나는 그들을 위해 일을 할 것이지만 가능한 한 많은 것을 피하려고 노력합니다. 왜냐하면 누군가가 작업을 오프로드하는 것을 볼 수 있기 때문에 한 사람이 시스템을 친밀하게 알고있는 것과 같은 문제가 발생하기 때문입니다. 내가 잘 알고있는이 시스템에 대해


답변

제가 제 직업에서 실제로 유용한 것으로 한 것은 내부 Q & A를위한 포럼 (예 : PHPbb)을 설정하고 질문 및 / 또는 답변이 5 분 이상 걸리면 규칙을 따르는 것입니다. 포럼을 통해 질문하고 답변했습니다. 혜택:

  • 그것은 주니어 개발자가 질문을 명확하게 진술하도록 강요하여, 답변에 대한 자신의 시간을 언급하지 않고 단지 그것에 대해 조금 더 생각함으로써 대답하기가 더 쉬워집니다.
  • 주니어 개발자는 이미 작성한 유사한 질문을 검색하여 시작해야하므로 중복 질문을 피합니다.
  • 향후 고용에 유용한 지식 기반을 구축하고 시간을 잃을 수있는 많은 작은 것들을 문서화하는 데 도움이됩니다.