会社のイベントで初めてハッカソンのメンターを行ったので、その時に『いいアドバイス』について考えたことを記録しておく
ハッカソン
比較的短い時間でテーマに沿ったアイデアを出し、開発を行うこと
例)レッドブル、ピザ
思ったこと
短期間での開発を行うためには、学生にとってメンターはとても重要な立ち位置にいますよね
せっかくいいアイデアを思いついても、使ってるイメージが伝わるくらいには実装できないとハッカソンの意味がないと僕は思うのです。
そこでメンターとしてはどうしても、最低限の機能を実装してもらうためにサポートを行う心構えで学生の周りをウロウロしているわけです。
ある学生Aくんが質問に来ました。
Aくんは〜な機能を作りたくて〜のコーディングをしてるのですが〜の部分が上手くいかなくて...ということ
僕はできる限りそのコーディングに沿った流れでアドバイスを行います。
という部分で疑問に思いました。
これは本当にその子のためになるのか??(たぶんそれだけではならない)
ハッカソンは機能の実装も大切なのですが、自分だけの開発(内向的開発)で、普段触れたり聞いたりしないようなことを行う(外向的開発)機会でもあるわけです。
もっと上手くやれる方法であったり、早くやれる方法を習得できる場なわけです。
結果、何が言いたいのかというと
メンターは
- 現在のコーディングによるゴールに結びつくアドバイスの提示
- コーディングする前だったら自分ならこうするとか(こんな実装をしたことがある)というアドバイス
の2つを提示するのがいい
日常に戻った時どちらも必要だけど、少し性質が異なる。
1番の場合自分で考え、想像している機能を実装するための思考のプロセス、対して2番は同じ状況に遭遇した時に上手くやれる知識を提示することになる。
どちらも重要だなと改めて考えた。
そういえば僕もインターンで、質問を行った時に流れるようなデバッグを魅せつけられた記憶があり、さらに設計についてアドバイスをいただいたことがある。
あんなに原因がわからなかったのにこうやればできるんだと感心した + あんなわかりにくいバグを作らないようにはどうすればいいかを教えてもらい意識するようになった気がしている。
やってもらってた( ；´Д｀)ありがとうございます!!
というわけで、僕的いいアドバイスとは、考え方のプロセス + 知識(他のいいやり方)を提供することだと思いました。
わかってるけど難しいよね!というメモでした。
