コードを書かない日に読む本

この記事は約 4 分で読めます。

コードを書く日と読む本は変えるべき

平日にコードを書きながら設計の本を読むと、目の前の実装に引きずられて、本の内容を狭く解釈してしまいます。「この設計原則、今のプロジェクトには当てはまらないな」と切り捨ててしまう。

コードを書かない日は、実装の制約から解放されています。この状態で読む本は、より広い視野で受け取れます。「今のプロジェクトには使えないけど、こういう考え方があるのか」と、結論を急がずに持っておけます。

ただし、保留した知識は必要な場面で自分から出てくるとは限りません。読んだ直後に「どんな状況で使えそうか」を一言だけ書き残しておくと、後の設計判断で思い出す手がかりになります。

コードを書かない日に読むべき 3 つのジャンル

1. 思想・哲学寄りの設計書

ロバート・C・マーティンの「Clean Architecture」やジョン・オースターハウトの「A Philosophy of Software Design」のような、特定の言語やフレームワークに依存しない設計思想の本。どちらも似た書名の本が他にあるので、著者名で確かめてから探すと取り違えを避けられます。この種の本は結論だけを抜き出しても使えません。なぜその原則が要るのかという理屈を追う必要があるため、実装の手を止めているときのほうが読み進めやすいジャンルです。

平日に読むと「で、明日のコードにどう活かすの？」と即効性を求めてしまいますが、休日に読むと「この考え方は 3 ヶ月後のプロジェクトで活きるかもしれない」と長期的な視点で受け取れます。

2. 隣接分野の本

自分の専門外の本は、コードを書いている日には手が伸びません。「今の仕事に関係ない」と後回しにしがちです。

しかし、フロントエンドエンジニアがデータベースの本を読む、バックエンドエンジニアが UX の本を読む。この越境的な読書は、コードを書かない日だからこそできます。隣接分野の本が効くのは、扱う題材が違っても同じ問題の形が出てくるからです。データベースのトランザクション分離とフロントエンドの状態管理は、どちらも「途中の状態を他から見せない」ための工夫です。この重なりに気づくと、自分の専門分野の設計を説明する言葉が増えます。

3. エンジニアの自伝・エッセイ

技術的な内容ではないけれど、エンジニアとしての生き方や考え方に影響を与える本。著名なプログラマのエッセイ、スタートアップの創業記、オープンソースプロジェクトの歴史。

エンジニアのエッセイは、技術力を直接高めるものではありません。ただ、うまくいかなかった判断とその後始末が当事者の言葉で書かれているので、自分がいま抱えている迷いを言葉にする助けになります。締め切りに追われていない日のほうが、こうした遠回りな読み方に付き合えます。

コードを書く日に読むべき本

逆に、コードを書いている日に読むと効果的な本もあります。

言語やフレームワークのリファレンス本。実装中に「この API の使い方は？」と疑問が湧いたタイミングで開くと、その場で書いて確かめられます。手を動かしていない日に同じページを読んでも、引数の意味までは残りません。

リファクタリングのパターン集。午前中にコードレビューで気になった箇所があれば、昼休みにパターン集を開いて該当するパターンを確認する。困っている対象が手元にある状態なら、読んだ内容をその日のうちに当てはめて確かめられます。

分ける基準は曜日ではなく「その日手を動かすか」

平日は実務直結の本、休日は視野を広げる本という分け方は覚えやすいのですが、曜日そのものが基準ではありません。休日に個人開発でコードを書く人もいれば、平日が会議だけで終わる日もあります。基準は「その日、手を動かすかどうか」です。

手を動かす日にはリファレンス本やパターン集を、動かさない日には設計思想や隣接分野の本を。この対応で選べば、読んだ内容をすぐ試せる日と、試せないぶん考えを広げる日を、それぞれの利点のまま使えます。

関連記事

• 寝る前の 10 分間読書が翌朝のコードに効く理由
• 日曜日の午前中に 1 章だけ読む生活

まとめ

コードを書かない日には、実装の制約から離れた視点で本を読めます。設計思想、隣接分野、エッセイ。いずれも手を動かしていない日のほうが読み進めやすいジャンルです。手を動かす日と動かさない日で読む本を分け、読んだ内容を一言残しておく。この 2 つで、休日の読書が後の実装につながりやすくなります。