見出し画像

最終課題を終えました。

プログラミングスクール「テックキャンプ」を開始して2ヶ月。
夜間・休日スタイルとしてはわりと良いペースで「最終課題」をクリアしました。
今回は振り返り記事です。

課題内容やコード自体の詳細は置いといて、
「課題のアプリを1個、自分で作った」という経験を通じて
考えたことを書き残しておきます。


取り組む中で意識したこと

最終課題に取り組むにあたって、意識したことは以下。

  1. 調べたらわかるコードはさっさと調べる

  2. エラーメッセージはちゃんと読む

  3. 毎日時間を取る

  4. 適当に休憩を取る

  5. 翌日やることを把握して終わる

調べたらわかるコードはさっさと調べる

およそ2ヶ月、HTML・CSS、RubyとRails、JavaScriptなんかを勉強して、いざそれらを組み合わせてコーディングしようとしても、全部の文法やメソッドを覚えているわけでもありません。

ここで、トレードオフを考えました。
つまり以下のような感じ。以下のうちどっちがいいか?

  1. 記憶を頼りに、調べないようにしてコードを書いて、「思い出そうとする」経験をたくさん積むことで、より一層記憶に定着させる

  2. 記憶を頼らずに、どんどん調べてコードを書いて、とにかくさっさと進める。代わりに「今、どのへんで何をしているか」を把握するようにする

せっかくお金を払ってスクールで勉強しているのだから、ちょっとでも身につけるためには1の方が良い気がしますよね。学習効果だけ見れば1が正解でしょう。
でも、僕は2を選びました。
理由は以下です。

  • 結局、必要な構文は実務で何度も書くうちに覚える

  • 結局、実務で必要なものはググれば出てくる(AIに尋ねることもできる)

  • いま頑張って1回覚えたとて、しばらくすると忘れるだろう

  • いま覚えなくても、何度も実戦を積めば覚えるだろう

  • それならば、今覚えることに時間を使わなくて良い

という感じ。

もしも時間と記憶力が無限ならば、「いまメチャクチャ覚える」ことには絶大な価値があると思うけれども。
今は記憶への定着をはかるフェーズでもなければ、今覚えたことがずっと定着する保証もないため、今は時間をかけるべきではない。と判断しました。

というわけで、基本的にサクサク進めることを意識しました。

エラーメッセージはちゃんと読む

Railsの実装をしていると、

  1. なんかコード書く

  2. 動かしてみる

  3. 真っ黒+赤の画面(エラー画面)

という光景が多いです(というか、ほぼ常です)。

このように「書く→動かす→エラー」となったとき、すぐにコードエディタの画面に戻って「何が違ったんだろう!こうしたら良いかな?それともこうかな??」と試行錯誤を始めたくなります。

でも、それであんまり上手くいくことはありません。
(もちろん、自分の中で2択の選択肢があって、「これでダメならアレだな」とアタリがついている場合はさっさと試せばいいですけどね)

エラーが出たら、最初にエラーメッセージをよく読むべきです。
エラー内容によってはズバリ問題箇所が示されています。
(〇〇の変数が定義されてないよ、とか メソッドが見つからないよ、とか)
本当にメッセージ内容が分からないときは、ChatGPTにエラーメッセージを見てもらって解決をはかることもありました。
(最初から丸投げすると流石に何も身につかない気がしたので、しばらく自力で考えて、10分くらいで解決しない場合はGPT先生に聞く、みたいな感じでやりました)
そのうち、何回か同じようなエラーにぶつかり、すぐに解決できることも増えていきました。

毎日時間をとる

アプリ開発は大きいプロジェクトです。
つまり、1日ガリガリ頑張っても出来上がったりしません。

そこで重要になってくるのが「毎日やる」ということです。
僕はだいたい毎日2時間ほど時間をとっていました。

毎日やることのメリットは「思い出す時間が減る」という点です。
毎日ちょっとずつ進めることで、「前回どこまでやってたんだっけ?」ということを思い出す時間は最小になります。

逆の好例として、テックキャンプのカリキュラムには「自力でやってみる実践形式の問題」がいくつかあるのですが、これに取り組む時間は週に一回しかとっていません。(本当はもう少し細かく進めた方が良いと言われているけど・・・)
すると、毎週の時間の一部は「先週どこまでやってたか」を思い出す作業に使うことになります。これは大きなロスになります。

学習効果の面でも、毎日やることはいろいろメリットがあるので、30分でも15分でも、途切れずに毎日取り組むのが良いと思います。

適当に休憩をとる

プログラミングは「知的生産」にあたるでしょう。
で、知的生産を行うには脳がしっかり元気でないといけません。

仕事の後なんかにプログラミングをしていると、どうしてもぼーっとする日があります。
ぼーっとしながら「頑張り」でどうにかしようとしても、それは「ガス欠の車のアクセルを強く踏んでいる」だけです。脳は主観的な「頑張り」でパフォーマンスが上がったりしません。多分。

そんなときは椅子をリクライニングして、15分寝るようにします。
充電式のホットアイマスクをつけて、Apple Watchで15分タイマーをつけて寝ます。

15分以上寝ると睡眠が深くなり、起きた時いわゆる「寝起き」になってしまってパフォーマンスが落ちます。
一方、5分だとほぼ「目を瞑っただけ」になります。
10分または15分が個人的にベストです。眠気の強さに応じて時間は決めます。

逆にちょっと歩いたり筋トレをするような「アクティブ・レスト」と呼ばれる手法もたまに使います。余裕があれば、15分寝てから3分筋トレしてPCに戻るとパフォーマンスが上がったりします。

翌日やることを把握して終わる

実はこれが一番大事なTipsのような気がします。

つまり、毎日の作業を終えるときに、「明日はここから、あれをやる」という内容を把握しておき、必要なら手帳などに書いておくようにします。
そうすることで、翌日のスタートが抜群にスムーズになります。

翌日の自分の気持ちになってみればわかりますが、次のシーンのうち、どちらが習慣として継続しやすいでしょうか?

  1. 仕事終わりに、作業内容を確認し、予定を立て、作業を開始する

  2. 仕事終わりに、作業を開始する(何をすべきか分かっている)

後者でしょ???

何をすべきか把握しておくだけで、取り組むハードルが下がるわけです。

いわゆる「やる気」というものは、やり出してから出てくるものである。
というのは割と有名な話だと思います。(作業興奮って言うんでしたっけ?)
やる気を出すためには、まず始めなければなりません。逆に始めてしまえば一気に集中して取り組めたりします。
だから、始めるハードルを下げることは全体のパフォーマンスアップにつながります。

まとめ

ということで今回は、初めて1つのアプリをがっつり実装するというプロジェクトを進めてみて、自分のコントロールに主眼をおいて振り返ってみました。

「自分をうまく制御して毎日取り組めば、まぁまぁ大きなものが作れるんだ」という実感が得られた、良い体験でした。

楽しかった。おしまい。

この記事が気に入ったらサポートをしてみませんか?