えぬ億までの道

アラサープログラマが一発当ててn億を得るまでの記録

生産性の高いプログラマーの特徴

生産性の高いプログラマーの特徴

問題を言語化する

まず問題を言語化する。

思考は幅優先探索

先に大きな方針を決める。ダメそうなら深みにハマる前に他の代替案を考える。例えば、ライブラリの挙動が想定通りでない時、どうにかして動かそうとするよりそもそもそのライブラリを捨てて別のライブラリを使うことを検討するなど。

あまりにハマるようであれば、そもそもその機能は捨てる、という判断もありうる。

公式ドキュメント,GithubリポジトリのIssueを読む

公式ドキュメントを見るのがまず最初にやるべきこと。その際、バージョンをしっかり確認すること。公式ドキュメントが充実しているかどうかはライブラリ選定の判断基準の一つになる。

英語で検索する

日本語で検索し、訳のわからないブログの記事を理解もせずコピペするプログラマーがいるが、最悪である。量、それに伴う質の観点から、英語で検索する以外ない。

仮説と事実分ける

何を想定していて何が事実なのかはっきりさせておく。そもそもの前提から間違えている事がある。

検証はメモを取りながら一個の事だけをやる

原因の究明や挙動の確認に検証を行うことが多いと思うが、一気に複数のことはやらない。仮説検証のパラメータは1個にする。「で、なんだっけ?」とならないようにメモを取る。

掛け算で効いてくるプロセスを最速の環境にしておく

hot loading、AndroidならInstant Runなどを駆使して毎度のビルド等は高速化しておく。キーボードショートカット、ツール、IDEリファクタリング機能など、掛け算で効いてくるところには最初に学習/構築コストを払って整備しておく。

コードを読む時はhow/what/whyの観点に注意する

問題の解決には、どう実装されているか(how)より何をしているのか(what)のみで十分なことも多い。これは関数の実装ではなく関数の呼ばれ方でわかる。全体像を把握し、何をしているのかを把握し、最後に必要ならどう実装されてるかを読み解く。なぜこのような実装になっているのか(why)はコードではなくコメントやドキュメントを参照する。

一旦放置する

30分以上ハマっている場合、一旦放置する。戻ってくるor次の日にすぐに解決することが非常に多い。ハマっている状態だとなかなか出来ない行動だが、非常に有用なテクニック。