language-agnostic - ジュニアプログラマーを指導する方法

Question

ジュニアプログラマーを指導する方法について何か提案はありますか? 誰かを指導したことがある場合、何らかのプロセスに従いましたか、それとも非常に非公式でしたか?

過去に指導を受けたことがある場合、どのようなことが最も役に立ちましたか?

score 48 · Accepted Answer

一緒にコードを確認するために、1 日 30 ～ 60 分を確保するようにしてください。これができない場合は、非常に基本的なものでない限り、コードをコミットするたびに集まってコードをレビューするようにしてください。他の方法ではなく、なぜ自分が取ったアプローチを選んだのかを説明してもらいます。このようなプロセスは、素晴らしい関係を築くのに役立つだけでなく、生徒が自分で考え、自分の決定を擁護できるように刺激します。学生は、信頼できる親しみやすい人に出会うだけでなく、コードとロジックの品質の向上にすぐに気付くでしょう。

編集：また、後輩との共同レビューにこれほど多くの時間を費やすことができない場合は、おそらく彼らを指導するのではなく、他の誰かがそれを許可するスケジュールを持っているかどうかを確認する必要があります. メンタリングの要点は、学生の専門能力開発を積極的に支援することであり、適切な注意と指導が与えられない場合、学生は多くを学ぶことはありません.

score 18 · Accepted Answer

小さなソフトウェア会社でインターンとして働く機会があり (2 人のうちの 1 人)、彼らが持っていた「ほぼ新しい」プロジェクトに取り組む機会がありました。彼らは私に必要なものすべてをセットアップさせ、プロジェクトが実際にどのようなものであったか (要件などの基本的なもの) を紹介してくれました。

最初は、プロジェクトにとって重要なことを調査するなどの小さなタスクを実行する必要がありました (トピックのリストが提供されていました)。これは、私たちが自分たちでどれだけ処理できるかを確認するためだったと思います。調べて調査する必要があることはそれほど簡単ではなく、2 週間ほどかかりました (そのために作成する必要のある基本的なデモを数えます)。 . そのテスト段階は、実際にはあまり「コーチング」なしで行われました。

ただし、その期間の後、実際のプロジェクト自体に取り組むことができました。これは、私たちが 3 人 (インターン 2 名と「コーチ」1 名) だったことを除いて、ペアプログラミングに似たスタイルで、一緒にコーチングを受け始めた瞬間でもありました。

私たちは彼から多くのことを学びましたが、それは非公式な方法であり、彼は「すべてを知っている、私に耳を傾ける」人のようには行動しませんでした. 私たちが提案をしたとき、彼は耳を傾け、それが良いかどうか私たちと一緒に考えました. または、アイデアがそのように行われるべきではない理由についての彼の見解を述べてください...今思うと、彼は積極的に私たちに提案をしたり、物事を行うためのより良い方法を考えたりするように勧めました。おそらくあなたよりも何をすべきかを知っている誰かからの注文です。

要するに：

ジュニアプログラマーに (ほとんどの場合) 独力で手元の資料を学習させ、情報の検索や小さなデモの作成などのマイナーな TODO のリストを提供します。
彼が定期的に行った仕事をチェックし、物事を行うためのより良い方法があれば彼にアドバイスしてください. また、彼が実際にうまくやったアイテムを指摘してください。そうすれば、彼は後でそれらを覚えています。
彼に実際のプロジェクトに取り組ませ、同じプロジェクトで一緒に作業して指導し、質問があればアドバイスを与えます。
努力は両方向から行われなければなりません: 彼に質問をするよう促し、「現在行われている方法」に異議を唱えるよう促します。彼がそれをどのように行うべきだと考えているかについて質問し、あなたの意見も伝えてください.
「楽しい」ものにしましょう - 命令しているように見えないようにしましょう。

score 14 · Accepted Answer

社内ITが多い大企業でのインターンシップ中に、メンターとペアになりました。このプラクティスは、技術スキルとビジネススキルの両方の面で、私のキャリア開発に確実に役立ちました。メンタリングがうまくいった理由のいくつかを次に示します。

信頼できる: メンターは 8 年以上の経験があり、リーダーシップとトレーニングで利用できる優れたバックグラウンドを持っていました。彼はさまざまな課題を経験し、さまざまな環境で働いていたので、素晴らしい視点を持っていました。
本物: メンターシップはスーパーバイザーによって奨励されましたが、モーションを実行する練習になるほど形式的ではありませんでした。メンターはメンターになりたがっていたので、私は誰かから学びたいと思っていました。
情熱: メンターは、自分がいる分野、解決している問題、使用しているテクノロジーを愛していました。私が彼の翼の下に来たとき、私はこれが伝染性であることに気づきました。
鋭く明確に: メンターは問題に批判的にアプローチし、簡潔にまとめました。私たちの議論にはあまりあいまいさがありませんでした。私たちは問題の根源にたどり着き、彼は問題解決と行動の賢明な方法を私に教えてくれました。
有意義：私がメンターと一緒に行っていた仕事は有意義な仕事であり、忙しくしていたり、スキルセットを増やしたりするための単なる練習ではありませんでした. 組織を具体的に支援するタスクに共同で取り組むことで、私の関心を集中させ、メンタリングプロセスを正当化することができました。

score 6 · Accepted Answer

私が最初に就職した場所には、私の差し迫った問題を解決するのをいつも助けてくれ、重要な根本原理を教えてくれる本当に辛抱強い男がいました。より良いプログラマーになる方法を教えながら、生産性を維持するのを手伝ってくれるので、私はこれが大好きでした.

score 3 · Accepted Answer

私はジュニアになると思います:)私は非公式のアプローチを重視すると思います。それはおそらくあなたとあなたのメンティーの性格に大きく依存しますが、エゴが邪魔をしない場合に最もよく学ぶことができると思います. 緊張をほぐし、両方向にフィードバックがあることを確認します。コードレビュー (双方向?) や、ときどきのペアプログラミングなどもうまくいくかもしれません。

score 3 · Accepted Answer

面接の際に (お金が必要であることに加えて) 協力したい理由を説明しなければならなかったので、マネージャーは、私の最初のプロジェクトでは、私が弱点として特定した分野に取り組むことができるようにしました。 Linux のみの R&D チームなので学習せざるを得ない)、便利なテキストエディターを知らない (Vim を本当に学びたかった)、別のプログラミング言語を学ぶ方法 (プログラミングを学ぶときに言語を学ぶのとはまったく異なるアプローチ) . 彼は私がしばらく勉強するためにお金をもらっていると言った。

私は本を読むのが一番勉強になるので、Unix for Dummies についてくすくす笑った後(やった! これが曖昧で頭が悪いと思ったのは私だけではありませんでした)、Unix in a Nutshellと Sobell's Practical Guide to Linux Commands から始めました。その後、Vim のドキュメントを印刷して読み始めました。次に、最初のプロジェクトの言語である Python に関する本を何冊か調べました。私はこれらのことについて快適に感じるために必要なすべての時間を与えられ (これが本当の問題であることが、今理解できるようになりました)、その後、以前の生協のプロジェクトに機能を追加し始めました。

Kamikaze Mercenary が言ったように、コードレビューのために 1 日か 2 日誰かと会えたら最高だったと今では思います。

score 3 · Accepted Answer

私の経験では、誰かをメンタリングするとき、メンティーが本当にもっと学びたいと思っていることが非常に重要です。

決してスプーンで食べさせないでください。代わりに、価値のあるものに向けて、彼らが使用しているプロジェクトで彼らが学んでいる新しい情報を利用するように指示してください. 知識は実践しなければ意味がありません。したがって、メンティーにコーディング、コーディング、コーディングを奨励してください。

score 2 · Accepted Answer

これが私の短いリストです：

ペアプログラミング-これは、さまざまなアイデアや実践を強化するなど、多くのことに役立ちます。Resharperを頻繁に使用する人とペアリングすると、Resharperに慣れるのがはるかに簡単になります。

非公式のチャット-ここでは、飲み物を飲んだり、外に出て煙の休憩をとったり、一緒に昼食をとったりします。机から離れている間、話し合いはすぐに行われる作業に関連している場合もあれば、誰かのゲームを1、2ノッチ上げるのに役立つ抽象的な哲学的なもの。今後のさまざまなテクノロジーや今後の変化について話すことは、刺激的であり、絆を築くのにも役立ちます。

フィードバックと提案-これは、上記の両方の場合に発生したことです。デール・カーネギーの「人を動かす方法」のような本は、さまざまな人間関係のダイナミクスを理解するのに役立ちます。それは非常に技術的に聞こえますが、実際にはさまざまな方法で他の人をやる気にさせる方法についてです。ここでの重要なポイントは、単に答えを与えるのではなく、何かについてのヒントを次々に与えるなど、いくつかのプラクティスを習得するためにパンくずリストを残す方法を知ることです。私には、このスキルのいくつかをどのように開発したかについて、これに対する贈り物を持っていたさまざまな数学の先生がいました。

ですから、これの一部は単に他の人をやる気にさせ、誰かが自分のために何かを理解するとき、それは力を与え、啓発する経験になることができるように彼らを導くことを試みています。「やった！そうだね、モイ、本当にあなたのものだ！」それが起こったとき、一種のセルフトークは非常にいいです。

score 2 · Accepted Answer

タスクを完了するために次に何を試すかを尋ねます。これにより、「何をすべきかわからない」から「まあ、これを試してみますが...」のカテゴリまで、出発点として役立つ可能性のある独自のアイデアを持っているかどうかのアイデアが得られます。 .

彼らが何をしたいのかを簡単に見て、問題を理解するためのヒントを提供してください。これは、「このコード行を取り出してください」という答えを与えるのではなく、そこにあるものを見て、それがすべて必要かどうかを提案することです。

score 1 · Accepted Answer

数年前、私は小さな会社で働いていましたが、初日に完了する小さなタスクのリストを与えられました。コードに小さな変更を加え、プロジェクトの小さなバグを見つけて修正しました。メンターに適切な質問をして、環境やコードベースに慣れることができて本当に助かりました。これらのタスクは簡単に完了できたので、より大きなタスクに取りかかる前に、少し自信が持てました。

このメンタリングの方法は私にとって非常にうまく機能したので、新しい同僚にも同じことをしようと計画しています。

score 1 · Accepted Answer

あなたが持っている実際の割り当ての一部を提供し始め、彼のコードを使用できるようにすべてを作成することをお勧めします. つまり、自分の代わりとして育成する。

このようにして、後輩と一緒に仕事をする時間を確保することに専念し、後輩は「実生活」を見ることができるようになります。実際の課題に取り組み、活発なフィードバックを聞くことで、彼は p をかなり迅速に処理できるようになります。

このアプローチの欠点は、特定のプロジェクトへの焦点が狭すぎる可能性があることです。そのため、研修生に可能な代替案を示し、トレードオフ分析を奨励して専門的な視野を広げてください。

score 0 · Accepted Answer

これまで何人かの後輩を指導してきました。私のアプローチは、その人がどのように学んだかによって少し異なります。

手短に言えば、私は後輩たちに、可能なときに自己完結型の小規模なプロジェクトを与え、そのタスクを完了するための比較的一定の時間を彼らに与えました。タスクが完了したら、彼らのアプローチ、コード、およびソリューションを確認し、問題を処理するための改善またはより良い方法を提案しました。こうすることで、彼らははるかに大きなプロジェクトの一部であることに圧倒されることはないと思います。

これが少し役立つことを願っています。

language-agnostic - ジュニアプログラマーを指導する方法

12 に答える 12

Related

Reference