Arai60の取り組みの軌道修正を考える

• Arai60を大体半分くらい解いたが、以下の目標からは遠い位置にいると感じる。全く手ごたえがない。
• https://docs.google.com/document/d/11HV35ADPo9QxJOpJQ24FcZvtvioli770WWdZZDaLOfg/edit?tab=t.0#heading=h.a90s3txtp3u

このコーディングの練習は、仕事の引き継ぎであると思ってください。つまり、60問解いた後には、今の講師陣は引退をし、みなさんは独り立ちをして、各々このコーディングの練習会を開きます。それができるようになるのが目標ということです。 「各々このコーディングの練習会を開けるようにする」ということから逆算して、自分に何が足りないかを考えてみませんか。

• 最近気づいたが、コーディング練習会を開けるようにするとは、「少なくとも、ある問題を解いたとき、その問題の練習会を開催できる」ことだと思った。開催できるとは思わないので取り組みの軌道修正が必要に感じる。

スタートラインにたつためにはどうするのかを読み直してもコードの読み書き、アルゴリズム、ロジックは十分ではない状態。

• p29の内容

コードの読み書き、アルゴリズムやロジックが、ほとんどの人は十分でない
コードが書けたの定義や基準がだいぶ違う
知っているかではなく、パズルなど手作業でできることをコンピュータにお願いできる
言われた問題に対して入出力と計算量が一致したコードが書けるでは道半ば
仕事では2割くらいできたというイメージ
面接では(書く能力の配点に限れば)6割くらいか
ただし、点数として加点される(算術平均)という感覚はだいぶ違う(後述)
コードが読めるか(大規模なコードを読解し理解する能力)のほうがだいぶ重要
あとは、コードを思ったように変形させられるかの自由度がかなり重要
ゼロからそれっぽいコードを書くのは比較的易しく、頭の中で走らせて修正する方が難しい
私の採用基準はどうやら実際よりも厳しいようだが、それを割り引いてもおそらくこう
調査能力
自分の外部があるという認識と、外部の状況を調べたことがあるか
ためらい
専門性はためらいで分かる

• ある問題を解いた後に、その問題の練習会を開けるようになるためには、以下の3点が特に重要だと感じている。

  • コードが読めるか(大規模なコードを読解し理解する能力)のほうがだいぶ重要
  • あとは、コードを思ったように変形させられるかの自由度がかなり重要
  • ゼロからそれっぽいコードを書くのは比較的易しく、頭の中で走らせて修正する方が難しい

• これらは実際のエンジニアの仕事でも重要。

• 練習会を開けるようになるための取り組み方法について考える。

  • まず、コードを書く負荷を下げることが重要だと感じている。

    • なるべく自力で書きたいという意識はあるが、その負荷が高く、視野が狭くなっている。
    • これまでの流れとしては、解法を1つ考えた後、実装で時間を使いすぎ、書き上げて整理した時点で多くの時間が経過している。
    • そのため、短時間で考えて分からなければ、生成AIや他の人の解答を参照し、自分の思考とコード表現を早めに結びつけた方がよいと考える。これにより、他の選択肢を検討する時間を確保できる。

  • 本来目指すべきは、以下ができる状態である。

    • 他者のコードを読み、理解できる
    • コードを適切に変更できる
    • 複数のアプローチを思いつける
    • その中から適切なものを選べる
    • 選んだアプローチを複数の方法で表現できる

  • 「選択肢を知ること」がこれまで不足しており、上記の5つすべてができていない。

  • 以上を踏まえ、今後の練習方針は以下の通りとする。

    • 問題を見た際に、考えられるアプローチを列挙し、それぞれの計算量を検討する。さらに、他者のコードや生成AIを参照し、見落としている選択肢がないか確認する。
    • 各アプローチをコードで表現する。さくっとに書けない場合は、他者のコードや生成AIを参考にし、なぜ書けなかったのかを分析して次に活かす。それぞれのコードで3回エラーを出さずに書く。
    • その後、他者の解答を再度確認する。この段階では実装の理解も進んでいるため、「練習会の講師として説明できるか」という観点で読み、PRにコメントを残す。
    • 最終的には、どのPRを見ても他者のコードを素早く理解し、頭の中で実行して妥当性を判断し、必要に応じて修正提案ができる状態を目指す。liquo-riceさんによくコードの修正をしてもらっているがそれができるようになることを目標とする。

• 気を付けること(コメント集より)

狙いとしては、別によいコードを写すなり書くなりして褒められることではないはずで、同じものを見たときに専門家と同じ反応(もちろんブレはあるのでブレの範囲内で)をするようにすることでしょう。ならば、何を悪いと感じたか、何を避けたいと思ったかについての記述が必要なのです。

あと、実はソースコードやドキュメントを読むほうが遥かに大事なので、それができるようにすること。気になったら CPython の実装なども読むものなのですよ。

コードを頻繁に書き、仮想的な同僚である他の練習している人たちとコードについてコミュニケーションを取る

レビューにおいては、書かれていることを読み取って、書いた人の頭の中を推測し、どのような情報を伝えるとよりよくなるかを考えて、その情報を出すというのが理想的なプロセスです。

読み取れなかったならば、読み取れなかったので教えて欲しい、から入って、上のプロセスに合流します。

今回、読み取れていないところで止まらず連想した情報をたくさん出していますが、分からなかったときに止まって確認に入らないのはエンジニアリング全般においてかなり悪い癖です。

一般論として、「文字を書くこと」も「コストを増やす」行為であり、読んでもらった結果として「ベネフィットがコストを上回るか」のバランスで書くかを決めましょう。

最終的な目的は、独立して仕事をすることですよね。

その時には、このコーディング練習会を独立に開けると思っています。

そういうわけで、教える能力をつけるにはどうしたらいいかという見方をして欲しいですね。

つまり、自分で基準をもって、常識の範囲が分かるという状態になったらいいと思っています。