URL投稿ありがとうございます。Resigが、プライベートの時間でサイドプロジェクトを進めるにあたって、毎日継続してコードを書くことの効用を紹介しています。Dewalt(すごいな。)に感化され、20週間、毎日コードを書いてみたという話。彼のGitHubレポジトリの更新状況はこちら。大事なものを覚えるときは、極力頻度を挙げて取組みます。仕事のタスクでも、一つづつ片付けていくよりは、毎日平行していくつかの作業を進めるタイプ。アイデアとか判断はその日のものがベストとは限らないので、内容を忘れないように毎日てがけながら、リフレッシュした頭で前日よりもいい結果をだそうと取組んだほうが効率がよいです。このブログに話しを戻すと、「そもそも毎日サイドプロジェクトやるほど、よく時間あるな。A以降の時期になると、6時くらいで帰る人たちはけっこういます。いえ、その環境の違いを嘆いても仕方ないので、ポイントとしては、そのサイドプロジェクトが自分にとってどれだけ大きな意味をなすものかということ。時間を無理矢理つくっても値するほどの課題を自分がもつことができているのかどうか。集中できるのかという問題もあるかと。自分もかつて英語を真剣に勉強しようと思ったときは、本業とまったく関係なかったけど自分にとって大きな意味があったので、毎日継続できました。個人的には、本業の仕事と同じような作業をサイドプロジェクトですると、本業のことが気になって集中できる気がしません。それと、相反するようですが、長期的に成功するために休むペースをつくるのも大切かと。オフシーズンのほぼないスポーツのプロも、長期の休暇をとって体をベストな状態に保ちます。自分はスポーツを極めようと頑張ったらときに、プレーの頻度が落ちたらまったくペースがつかめなくなった経験もあります。できる人は、休むペースをうまくつくることもできるのかと。話が散乱しましたが、毎日継続することで、断絶コストを最小限にすること。集中できる、かつ大切度の高い課題を選択すること。長期的な成功のために、必要であれば休みをとるというペースづくりができること。このあたりをうまくバランスとれれば、本業であれ、サイドプロジェクトであれ、成果がでるよに思えます。この全文翻訳の記事が人気を集めているのを見て、この話題に関して親近感を覚えるエンジニアが多いのだと思いました。スポーツや楽器演奏もそうだと思うのですが、企業内の他の職種と違ってブランク期間が長くなると、予想以上に腕が落ちるのにもかかわらず、それが企業内でなかなか理解されていない、構造的にそれを防ぐ手段がないという背景もあると思います。定量的に調査したものを見たわけではないですが、より便利なテクノロジーへの変遷のペースが加速してきているのだとすると、かつては「エンジニアは新しいテクノロジーも勉強すべきだね。」だったのが、常に一定時間新しいものの習得に努めていないと、ものすごい勢いで自分の商品価値が下がっていくという時代になりますかね。人間のキャパって限られているので、学ぶ姿勢も大事ですが、「過去の自分を思い切って捨てるスキル」というのも重要になるのかな。