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

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

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

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

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

「Clean Architecture」「A Philosophy of Software Design」のような、特定の言語やフレームワークに依存しない設計思想の本。これらは実装の手を止めて、「そもそもソフトウェアとは何か」を考える余裕があるときに読むと、最も深く吸収できます。

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

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

しかし、フロントエンドエンジニアがデータベースの本を読む、バックエンドエンジニアが UX の本を読む。この越境的な読書は、コードを書かない日だからこそできます。そして、隣接分野の知識は予想外の場面で自分の専門分野に活きます。

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

エンジニアのエッセイは、技術力を直接高めるわけではありませんが、モチベーションや視座を引き上げてくれます。休日のリラックスした状態で読むのに最適です。

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

言語やフレームワークのリファレンス本。実装中に「この API の使い方は？」と疑問が湧いたタイミングで開くと、即座に実践に結びつきます。

リファクタリングのパターン集。午前中にコードレビューで気になった箇所があれば、昼休みにパターン集を開いて該当するパターンを確認する。この「課題 → 本 → 実践」のサイクルが最も短い距離で回ります。

シンプルなルールとして、平日は実務直結の本、休日は視野を広げる本、と分けるだけで読書の効果が上がります。

平日の通勤時間にはリファレンス本やパターン集を。日曜の午前中には設計思想や隣接分野の本を。この使い分けが、短期的なスキルアップと長期的な成長の両方を支えます。

コードを書かない日には、実装の制約から離れた視点で本を読めます。設計思想、隣接分野、エッセイ。これらは休日だからこそ深く吸収できるジャンルです。平日と休日で読む本を意識的に変えることで、読書の効果を最大化してください。