주니어 개발자를 멘토링하는 방법

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

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

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

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

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

또는 아마도 :

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

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

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

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

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

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

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

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

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

• 그들이 실수로부터 배우도록 도와주십시오. 실수가있을 것이므로 실수가 학습의 일부이며 실수를 학습 기회로 사용해야한다는 것을 보여주십시오.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

여기서 추세를 극복 하고 주니어 개발자가 스스로 답을 찾는 방법을 배우도록 권장 하지 말 것을 제안합니다 . 이것은 "나는 가지고 있지만 당신에게 줄 수는 없습니다"라는 게임처럼 보입니다.

대신 답을 찾기 위해 그들과 짝을 지어 라. 당신은 어쨌든 구글을 할 것입니다. 그들은 이것이 답을 찾는 방법이라는 것을 알게 될 것입니다.

그들과 긴밀히 협력하면 IDE를 올바르게 사용하는 방법을 알게 될 것입니다. 데이터베이스를 정규화하는 방법; 코드를 건조하는 방법 ... 알고있는 가치가있는 모든 것.

열쇠는 다음과 같습니다. 하나-자신이 사용 가능한 방식으로 작업 방식을 확인할 수 있습니다. 그리고 두 번째- 왜 당신이하고있는 일을 큰 소리 로 말하십시오 . "이 코드는 반복되므로 리팩토링 할 것입니다." "세 줄에 추출 방법을 사용하지 마십시오."

저는 주니어 프로그래머를 한 번만 훈련시켜야했습니다. 내가 구축 한 시스템을 유지하는 데 도움이되었습니다. 목표는 결국 전체 시스템을 그에게 넘겨주는 것이 었습니다.

그가 나를 가리고있는 짧은 기간 후, 나는 그를 불에 던졌다. 나는 그에게 사건을 할당하고 완료 될 것으로 기대한다. 만약 그가 어려움을 겪었다면, 나는 그 문제가 무엇이며 어디를 보았는지를 설명하게 할 것입니다. 그런 다음 가장 일반적인 용어로 다음에 볼 곳을 알려줄 것입니다. (어떤 앱, 어떤 모듈을보아야하는지 등). 나는 그를 flo 치게 만들지 않았지만, 또한 그 어떤 일도하지 않을 것이다. 방향 만 제공하십시오. 그래도 문제가 발생하면 어깨를 으 rug하고 "코드 추적 시작"이라고 말하면됩니다. 그리고 내가 말할 때마다 그는 지루한 운동을하고 있다는 것을 알고 울었습니다. 우리는 둘 다 내 엉덩이를 벗고 도와 주면 10 분 안에 문제를 발견 할 수 있다는 것을 알았 기 때문에 그를 망쳤다.

몇 년 후, 그는 더 큰 일로 넘어 갔으며 이제는 자신의 후배들을 훈련시키고 있습니다. 그리고 그가 가장 좋아하는 이야기는 내가 항상 "코드 추적"을 지시하는 방법과 이러한 코드 추적 연습이 그를 오늘날 프로그래머로 만드는 데 결정적인 방법이었습니다.

빠른 Google 검색으로 해결할 수있는 질문을받을 때마다 문서 나 관련 기사를 찾아 질문을하는 사람에게 전달합니다.

어디를 찾아보아야 하는지를 아는 것은 중요한 기술이며, 때로는 새로운 개발자를 생각하는 것보다 어렵습니다. 그들은 그들이 무엇을 찾고 있는지조차 모를 수도 있으며, 이것이 당신이 그들을 도울 필요가있는 곳입니다.

일단 기사와 문서를 작성하면 다른 개발자에게 빠른 답변을 요구하지 않고 솔루션에 대해 읽어야합니다.

이것은 다음을 달성 할 것입니다 :

• 노련한 개발자의 부담을 덜어줍니다.
• 새로운 개발자가 배우도록 강요합니다.
• 모두를위한 행복.

때로는 그들이 배우기를 원하는 것처럼 보이지 않는 경우에, 당신은 그들에게 약간의 사랑을 주어야만합니다. 그들에게 답을주지 말고 올바른 방향으로 향하게하십시오.

나는 당신이 가진 실제 과제의 일부를 시작하고 그의 코드를 사용할 수 있도록 모든 것을 만드는 것이 좋습니다. 다른 말로하면 그를 대신해 그를 훈련 시키십시오.

이런 식으로 당신은 주니어와 함께 일할 시간을 할당 할 것이며, 그는 "실제"를 볼 수있을 것입니다. 실제 과제를 수행하고 활발한 피드백을 들음으로써 속도를 빠르게 달성 할 수 있습니다.

나는 사람들에게 과거에 다양한 주제를 가르쳤으며, 가장 큰 충격을받은 것은 대부분의 사람들에게 문제 해결 능력 이없는 방법 입니다. 즉, 당신이 그들에게 정확한 해결책을 보여 주면, 그들이 필요하다고 인식하거나 들었다면 나중에 그것을 재사용 할 수 있습니다.

그러나 인생의 상황은 거의 없습니다. 작업 C가 도구 C를 사용하여 위젯 B를 위젯 B에 고정시키는 "정적 팩토리"가 아닌 경우 몇 가지 항목이 필요합니다.

• 기술과 도구의 도구 상자
• 문제 해결 방법

예를 들어 내가 게시 한이 답변을 살펴보십시오 . 많은 사람들 이 가지고 있지 않은 문제 해결 방법을 다루고 있습니다 . 대학은 CompSci 프로그램의 누구에게도 이것을 가르치지 않았습니다. 이미 알고 있거나 스스로 알아 냈습니다.

하급 개발자가 문제 해결 방법을 이해하고 나면이를 해결하는 도구 세트가 필요합니다.

• 디버거 (대학은 이것을 언급하지 않았습니다)
• 프로파일 러
• 텍스트 에디터
• 쉘 (및 관련 유틸리티)
• 자료 (도서, Google, SO, 맨 페이지)

주니어 개발자에게 부족한 점을 파악하고 개선 할 수 있습니다. 일부 사람들은 자신의 문제를 해결하는 방법을 배우는 데 관심이없고 "단계적으로 명확한"해결책을 원합니다. 이들은 좋은 개발자가 아닙니다.

바라건대, 당신은 그중 하나가 없을 것입니다. 그렇게한다면 시간이 얼마나 걸리더라도 그들 스스로가 도움이되는 것은 아니라는 점을 명심하십시오. 노력이 필요하며, 요청하기가 더 쉽습니다. 복지 문제와 비슷하며 경제 이론에 의해 설명됩니다.

계몽 된 자기 관심사는 사람들이 어떤 상황에서도 가장 유리한 선택으로 생각하는 것을 취할 것이라고 말합니다 . 그것이 그들이 보는 것임을 주목하십시오 . 나는 가장 중요한 것은 자급 자족하고 배우는 것으로 본다. 그래서 저는 스스로 일을합니다. 그러나 다른 사람들은 마감일까지 작업 코드를 제공해야한다는 것을 알 수 있습니다. 따라서 가장 비용이 적게 드는 방법을 찾습니다. 그들에게 "공짜"를 제공함으로써 그들의 목표를 달성하기위한 최소한의 노력이 필요합니다. 그 목발을 제거 할 때까지 자라지 않습니다 .

당신이 묘사 한 당신의 조직은 나의 것과는 매우 다릅니다. 나는 나의 후배 일을 정복하고 있으며, 그것을 판단하는 나의 역할로 본다. 많은 것이 다릅니다.

어쨌든 당신에게 조언하고 싶은 한 가지는 처음 2 주 동안 책상을 자주 방문하는 것입니다. 첫 주에 하루에 세 번 정도 점차 감소합니다.

이 방법으로 보내려는 메시지는 생산성에 관심이 있다는 것입니다. 나는 그들이 막히지 않도록합니다. 나는 그들이 규칙을 따르고 바퀴를 재발 명하지 않도록합니다. 나는 그들에게 가능한 한 자주 헌신하도록 가르친다. 점진적으로 개발하는 방법을 배우고 점진적으로 디자인에 대해 생각하십시오.

최악의 악몽은 매일 개발자가 기능을 수행하기 위해 하루 만 더 필요하다고 말하는 개발자입니다. 몇 주가 지연된 후에는 제작자가 처음부터 해킹 한 복잡한 디자인을 얻게됩니다. 추가로 요청되지 않은 버그가있는 기능은 지연을 보상하기 위해 혼합되어 발생하며 디자인의 자유로운 부작용이기 때문입니다.

많은 개발자들이이 접근법에 관심이 있다고 생각합니다. compex 과제를 가지고 혼자 남아 있다면 스스로 할 수 있음을 증명하는 것은 자연스러운 반응입니다. 그러나 잘못된 답변입니다. 품질은 팀워크이며 학습이 빠를수록 좋습니다.

다른 답변은 매우 좋지만이 문장에 대해 언급하고 싶었습니다.

최근에는 과거와는 다른 개발 / 프로그래밍에 대한 태도를 가진 사람들을 여기에서 시작했습니다. 그들은 작업을 수행하기에 충분한 정보 만 추출하는 것 같지만 실제로 학습하지는 못합니다.

대부분의 사람들 은 무언가를 하는 방법 을 알고 싶어합니다 . 이 태도는 새로운 것을 배우고 일을하는 법을 배우는 데 어려움을 겪을 때 처음에는 좋습니다.

왜 무언가가 행해지고 있는지 알고 싶어하는 사람들은 드 are니다 . 똑똑한 관리자는 때때로 관리하기 어려운 사람도 있습니다.

어떤 사람들은 돈을 잘 벌기 위해 코딩합니다. 다른 사람들은 코딩 비용을 행복하게 받아들입니다. 디자인과 코딩에 대한 열정이있는 사람들과 함께 일하는 것이 훨씬 좋습니다. 불행히도 나에게는 꽤 드문 일이었습니다. 적어도 스택 오버플로를 찾을 때까지.

후배 개발자를 위해이 모든 멘토링을 수행 할 것으로 기대되는 사람들에게주의 해야 할 사항 : 경영진이 진행 상황을 이해하도록하십시오.

다른 사람들을 가르치는 것은 일반적으로 어려운 일입니다. 집중과 집중, 계획과 노력이 필요하며 무엇보다도 시간이 걸립니다. 어떤 접근법을 사용하든, 어떤 방식 으로든 진지하게 가르치고 멘토링을하면 시간이 많이 걸릴 것입니다.

• 고위 경영진이 교육 업무를 수행 할 것으로 기대하면서 경영진이 경험이 적은 개발자를 고용하는 경우 명시 적이어야합니다. 기간이 무엇인지 확인하고 개발 일정에 교육에 소요 된 시간과 노력이 반영되도록하십시오. 경영진이 합의 된 시간에 멘토링 노력의 성공을 평가할 계획이 있는지 확인하십시오. (물론, 교수 및 멘토링이 필요한 개발자를 고용하고 있지만 경영진이 계획 하지 않은 경우 분명히 심각한 문제입니다.)

• 모두가 훌륭한 교사 나 멘토가 아니며, 모두가되기를 원하는 것은 아닙니다. 나는 피 각질의 또는 쓴 소리를 의미하지 않습니다; 나는 가르치는 것을 좋아 합니다. 그러나 모든 사람이 자신의 재능에도 불구하고 그것을 능숙하게 이용할 것이라고 기대하는 것은 어리석은 일입니다. 또한 멘토링을 즐기지 않는 선임 개발자 이거나 교사 나 멘토에게 좋지 않은 선택이라고 생각되는 경우 해당 업무 수행과 관련된 계획이 심각한 결함. 반면에, 가르치거나 멘토링을 잘하고 싶다면 의사 소통을해야합니다.

• 교육 및 멘토링이 선임 개발자 모집단에서 불균등하게 부담되는 부담 인 경우, 이러한 과제는 제품 개발 성과가 인정되는 것과 동일한 방식으로 회사에 귀중한 것으로 인식되어야합니다.

나는 당신에게 그것에 대한 내 모습을 줄 것이다.

기본적으로 다음과 같은 경우에 잘 배웁니다.

1. 주제에 대한 공식적인 소개가 제공됩니다. 새로운 개념에 대해 내가 가진 모든 질문에 답하는 사람 (예, 사람)이 없으면 새로운 것을 배울 수 없습니다. 내가 그 일을 마치면 ...
2. 책을 받으세요. 저의 멘토로서, 당신은 항상 똑같은 책을 가지고 있어야합니다. "언제나 제 4 장 72 페이지 6 절의 의미는 무엇입니까?" 약. 책이 있으면 더 독립적이며 실제로 질문 만합니다. 그럼 내가...
3. 프로젝트를 함께 시작하십시오. 이것은 프로세스에서 가장 중요한 부분입니다. 여기에서 모범 사례, 알고리즘, 어려운 (그러나 유용한) 언어 기능 등에 대해 가르쳐 시작할 수 있습니다.

지금 당신은 당신이 돌보는 자신의 프로젝트가 있고, 항상 시간이 없다고 말했습니다. 우리가 StackOverflow 로 축복받은 이유 입니다. 나는 그가 그의 코드를 디버깅하도록 기꺼이 도와 줄 것이라고 확신합니다. 주제에 맞지 않는 질문은 여기에서 물어볼 수 있습니다.

그렇게 말하면서, 당신은 여전히 정기적으로 그와 함께 일해야합니다. 일반적인 "타임 라인"은 다음과 같아야합니다.

• 1 개월. 기본 구문을 알아야합니다. 코딩 할 때 여전히 독립적이지 않습니다.
• 3 개월. 이 시점에서 그는 손등과 같은 구문을 알고 간단한 문제를 쉽게 해결할 수 있어야합니다. 그는 훨씬 더 독립적이며 아직은 아닙니다.
• 6 개월. 그들은 베스트 프랙티스, 공통 알고리즘 등과 같은 다른 모든 것 위에 알아야합니다 . 그는 아마도 SO의 약간의 도움으로 프로젝트를 스스로 만들 수 있어야합니다.

위의 것 외에도 누군가를 독립적으로 만드는 가장 쉬운 방법은 배우기 어려운 주제를 제공하고 인터넷 이외의 도움을 줄 수있는 것입니다. 그는 스스로 배워야 할 것이며 그의 지식을 알게 될 것입니다.

그가 당신이 알고 싶은 것을 알고 난 후에는 그를 자유롭게 해주십시오. 그에게 가서 배우고 싶은 것을 배우도록하십시오 (언제나 그 언어로 계속 일하고 싶다고 말할 수 있습니다).

이게 도움이 되길 바란다! 그건 그렇고, 그는 이것을 읽게하십시오 : 10 년 안에 자신을 프로그래밍하십시오 .

낮은 수준과 높은 수준의 학습을 구분하십시오. 지식, 이해 또는 응용 프로그램과 관련이 있으면 다음에 어떻게 볼 수 있는지에 대한 간단한 설명과 함께 대답을 제공하는 데 아무런 문제가 없습니다. 이것은 학교가 아니고, 부정 행위가 아니며, 그런 식으로 당신에게 영원히 의존하지 않을 것입니다. 첫 번째 또는 두 번째 주에 다른 일을 할 계획이 없으므로 그렇게하지 않아도 귀찮게하지 않습니다.

처음 몇 주 후에 이러한 종류의 질문으로 너무 자주 중단되는 경우, 포모 도로 타이머를 사용하고 포모 도로 끝까지 질문에 대답하지 마십시오. 무엇을 검색해야하는지 알기 때문에 Google이 쉬워졌습니다. 그들은 종종 그렇지 않기 때문에 Google에 무언가를 말해야하는 경우 최상의 결과를 얻을 수있는 검색어를 알려주십시오.

문제가 분석, 합성 또는 평가와 관련이 있으면 주제에 더 많은 시간을 보냅니다. 여기에서 의사 결정에 대한 추론을 제공하고 동일한 결론에 도달 할 수 있습니다. 이것은 디자인과 스타일의 문제에서 가장 자주 나타납니다. 그들에게 특정 디자인을 사용하라고 말하지 말고, 왜 그들이 첫 번째 선택보다 우월한 지 보여 주십시오. 그들이 실수를하게하고 그들 자신의 실수를 고치게하십시오.

나는 내 개인 영웅 Randy Pausch를 언급하는 사람을 본 적이 없다 .

실제로 프로그래밍을하고 가르치거나 멘토링하는 사람 (또는 의미있는 삶을 살고 싶은 사람)에게 도움이 될 수 있다고 생각합니다. 귀하 및 / 또는 동료는이 강의를 제가 가진 시간만큼 가치있게 볼 수 있습니다.

• 당신의 꿈을 이루고 (그는 교수였으며 이것은 다른 사람들에게 동기를 부여하는 것과 크게 관련이 있음)
• 시간 관리 .

나는 주니어 개발자로서 문제를 겪으면 답을 바로 얻고 해결 방법을 이해하는 데 시간을 보내는 것이 더 좋다고 생각합니다.

나는 지불했다. 고용주는 학습 비용을 지불하지 않습니다. 나는 하루의 끝에서 일을 할 것으로 예상했다. 작업 환경에서 시간을 낭비하지 않고 해결책을 찾으려고 노력하십시오. 그것이 내가 한 일을 잘하면 희망적으로 빨리, 제 시간에 픽업 할 것입니다.