【続】「プログラミング上達がはやいヤツの特徴10個」を3年間実践してわかったこと

ウェブエンジニアとしてスタートした社会人3年間が終わったので,振り返ってみる.

いいことだとわかっていても,実践している人・続けている人はそんなにいない

社会人1年目の冬に9ヶ月目を振り返ったブログ記事 「プログラミング上達がはやいヤツの特徴10個」を9ヶ月間実践してわかったこと」 を書いてから早2年とちょっと,あっという間だった.

「本や記事を読んだ時にみんないいとは思っている.でも,実際に実践してるやつはどれくらいいるんだろう」と思って実際に試そうと思ったのがきっかけだった.

“はじめはなかなか辛かった” と書いていた.

その時はわからなくてハマるという状況が辛かったと感じてていたと思う.

ハマって抜け出せないケースは多々ある. 経験が浅いうちは,何がわからないかもわからないような状況だったり,周りの経験者がいともカンタンに成果物を仕上げているのを見て焦る.

その時点の知識をベースに仮説を立てて,時には人の力も借りて解決まで持っていく. 問題解決を繰り返していると,気づいたら関連技術に対して理解が深まっていく. 知識が多い少ないは,あまり焦る必要はなかったかもしれない.

どんなにベテランの人でもハマるときはハマる. ハマった時に,楽に解決できる・事前にハマらないように・ハマりにくいようにできる,というのがプログラミングが上達したというならば, 日々継続してやりつづけるしかない.

プログラマに向いているかどうかは,ハマった状況から解決に導けるかどうか,さらに,好奇心を持って日々取り組むことが苦にならないか が判断軸になると感じた.

【続】プログラミング上達がはやいヤツの特徴10個

① 毎日コードを書く

3年前はとにかく毎日やることを意識してやっていたが,気づいたら楽しくて, 趣味的に毎日やるようになっていた.

毎日手を動かしていると,手が覚えるということがあるようだ.

ソフトウェアをリリースするまでに必要な工程にはプログラミング以外のことも多くある. 全体のアーキテクチャについて考えたり,要件定義・テスト方針について考えたりでもいい.

毎日続けることで問題解決する機会が増えるので,経験値的に上達は早くなる.

② テストコードも書く

テストコードを書くために適切な設計をすることが大事なのは,引き続き実感している.

しかし完璧なテストコードを仕上げること単体では,ビジネスの価値を1円も上げない.

工数とか優先順位の関係上,今は敢えてテストコードを書かないと判断したとしてもいい. 書くところと書かないところを明確に分けて,書かないところはテストしないと割り切り, テストしなくても大丈夫な設計にすることが大切だと感じた.

定められたテストカバレッジあげるために、テストしづらい部分もモンキーパッチで無理やりテストしてしまうのは完全に無駄だ. Rails x Angular のプロジェクトをやった時は,テストコードを全く書かなかったため, UIの変更を加えるとたちまちJSエラーが大量に出たりするなど,テスト書かなすぎ問題に陥った. そこで,capybara x turnip を導入してE2Eテストを書くようになったが,今度はテスト書きすぎ問題 に陥り, E2Eテストを書きすぎて,modelとかに変更を加えるだけで今度はテストが落ちまくる状況になった. テストコードがボトルネックになって些細な変更も気持ち的に重たくなる.

今思うと,この時はアプリケーションの設計がダメだったから,テスト書かないとバグるし, いざテスト書こうと思ったら書きづらくて無理やりなテストになって,メンテナンスに難があったという感じだった.

③ ソフトウェア全体を仕上げるまで書く

進捗確認をしていると「だいたい8割くらい終わりました」と言っていながらじわじわと作業が長引き,結局倍くらい時間かかったりすることがある.

最後リリース完了するまでが一番労力を費やす.

ローカルでは動いていたけど,本番にアップしたら動きませんでしたとか,とりあえず動くけどランダムにエラーがでますとか, 最後の大詰めが一番大変で,ちゃんとした理解が求められる.

その大変な部分を経験するかしないかで,全然違うと思う.

④ コードを公開する

コードを公開していないエンジニアが優秀でないということは,経験上ないとは思う. ただ,コードを公開することで人に見られ,そこから得られるフィードバックはいい勉強材料になる.

Github に公開してる. コード公開すれば,ソース見てくれる人もいて,それが仕事につながったりもする(かもしれない).

⑤ ソフトウェアを動作する状態で公開する

社内で使っていたオレオレライブラリを整理して, google-spreadsheets-parser とかをOSS化してメンテするようになった. 普段使うツールを自分で作って,運営していくのは楽しい.

OSSを運営していると,JetBrains製品が無料で使える.

Free Open Source Licenser

申請後審査があるが,上のライブラリでWebStromのライセンスを貰えた. 有償ライセンスだとなんだかんだ合計で数万かかったりするので,やってみたらいいかも.

⑥ How to を見たら実践する / ⑦ How to にアレンジを入れる

以前は,とりあえず写経したりしてたけど,最近は必要な部分だけ手を動かしてみるようにしている. 一回書いたことあるコードをわざわざ書くのは時間の無駄なので,必要な部分だけ.

How toもウェブの記事や本が多かったけど,動画コンテンツを流し見することも増えた. ウェブブラウザで試せる技術なら,さくっと試せるけど, 環境構築が必要な技術だったりするとscreencastとかの動画観て終わったりもする.

⑧ 好きな言語がある

JavaScriptは3年間ずっと使っていて,ググったりする回数は減ったと思う.

CoffeeScriptを書いていることが多かった. 生JavaScriptより見た目は簡潔にかけてコード量は減っていいんだが,やはりインデント言語はあまり好きではない. ES6 x Babel なプロジェクトを経験してから,やっぱりJavaScript書いた方が比較的コードは読みやすいなぁと感じている.

⑨ プログラミング以外に趣味がある

プログラムを書くのが好きだと,気づいたら何時間も経っていて,気付かず集中力は低下している. なかなか抜け出せないバグに陥ったら,思いっきり趣味に没頭してから再開すると, ハマっていたのが嘘だったかのように解決することがよくあるので,趣味は大事だと思った.

⑩ 常にハックするテーマを持っている

日々,ハックする=集中して取り組むテーマがあるとモチベーションを保ちやすい.

3年間,広く浅くやってきたので,僕はXXの人みたいなのがない. JSとかRailsは多少あるかもしれないが,次の1年はスパイク型人材を目指したい.

スキルセット

Skill 1 Skill 2

プロダクションで使ったり実用化した技術を中心にスキルセットをまとめた.

はじめは会社がマイクロソフト製品を使う方針だったこともあって,そっちよりの技術が中心だった.

1,2年目はサーバーサイドのWebAPIとか認証周りをやっていた.

元はネイティブアプリエンジニアになりたかったけど,サーバサイドもやってみたら面白かった. コード的にフルスクラッチでやるプロジェクトに多くかかわらせてもらえて, プロジェクトの進め方もある程度自由にやれたのは,いい経験で,今でも自分の礎になっている.

転職してからは, JS, Ruby, Rails, Angular, AWSを使った開発が中心になった.

特にこの1年間は,技術の選択が自由にできる環境だったこともあり, OSSに触れる機会が多かったのはプログラミング上達の後押しになった.

GitHubに上がってる人のコードを読む機会も圧倒的に増えた. 調べれば大体答えにたどり着くし,issueやPullRequestを辿る中で,その答えにたどり着くまでの過程も知ることができて面白い.

最近,機械学習とかに興味があってPython触っている. 次の1年はWeb周りを中心にそっち系の分野にも手を出したい.

プログラミング上達のために,サービス全体を構成する要素を一通りを経験してみる

1つのサービスをやる上で必要なレイヤーは一通り経験しておいた方が,トータルでプログラミングスキルは向上した.

ネイティブアプリエンジニアなら使っているAPI周りに関わったり, サーバサイドエンジニアならネイティブアプリやフロントエンドの実装をやってみたりするといい.

フロントエンドのJSは結構書いていたが,HTMLやCSS部分はあまりやってこなかったため, ある案件でガッツリやることになって,自分のHTML, CSSのクソコードたるや甚だしかった.

インフラ周りも手を出した. アプリケーションレイヤーを触ることがメインで,インフラ構築をほとんどやったことなかった中, AWSのインフラ周りのセットアップもゼロから経験して,色々ハマった. まずはnginx, unicornの設定にも手間取り,AmazonLinuxの書き込み権限・実行が足りなかったりして500エラーがでるなどなど.

普段やらない部分を敢えてやることで,いかに総合的な実力不足だったかを思い知ったと同時に, 一緒に仕事している人の気持ちがわかった.

Done is better than perfect

「技術を学んでから,実力がついたら次のやりたい仕事をやる」と思っていた時期もあったが, その“たられば”の時期は,待っていてはこない.

仕事を通して,その技術をつかっていたら,学んでいたことがほとんどだった. 「わかっていることをできる」より「その都度調べでキャッチアップ→アウトプットできる」方が重要だった.

スキルがあれば仕事もついてくるし,仕事をすればスキルもついてくる.

環境によって学習の機会をもらえたことに感謝する一方で,目標にしている某社のCTOからこんなことを言われてササった.

技術のキャッチアップでビジネスの遅れをとるのは,エンジニアの怠慢だ

会社の人数も少ないので自分ひとりで調査・検証・導入をすることが多かった. その分得られたものも多かったかもしれないが,ベンチャーのエンジニアとして反省した.

スピード優先の中で,ビジネスの問題解決の手段である技術を導入するまでに時間がかかりすぎてては元も子もない.

技術は予め検証して温めておいて,いつでも使える状態にしておきつつ, Done is better than perfectの精神でやっていきたい.

00000