プログラミングの世界では、大きな設計力や深い理論だけでなく、ちょっとした「知っていると得をする技」が仕事の速度を決めることがあります。今回の文章は、その小さな知識の価値をあらためて見直した短いエッセイです。派手な新技術の話ではなく、ターミナル、SQL、git、正規表現、Node.js といった日常の道具をどう使いこなすかに焦点を当てています。読み終えると、経験の差はコード量だけでなく、こういう断片的な知識の蓄積にも表れるのだと分かります。
著者の主張はかなり明快です。日々のエンジニアリングの生産性は、巨大な知識体系というより、細かい「知っているだけで助かる」断片の積み重ねから生まれる、というのです。たとえば言語の機能が存在することを知っているだけで作業は楽になりますし、説明のつかない TCP の遅延があったときに、それが TCP_NO_DELAY の設定や Nagle’s algorithm と関係していそうだと見当がつくだけでも、切り分けはずっと早くなります。git で詰まったときに抜け出すための定番コマンドや、sed でファイルを書き換える小技も同じ扱いです。
そのうえで著者は、特に「支える知識があまり要らない」小技が役に立つと述べます。たとえば Python をよく知らなくても、python3 -m http.server を実行すれば、今いるディレクトリで簡易サーバーを立てられます。こうした技は、周辺知識がなくてもすぐ使えます。続けて、いくつもの具体例が並びます。ターミナルの履歴検索は ctrl + r でできるが、fzf を入れると曖昧検索になる。さらに atuin は shell history を SQLite データベースに置き換え、検索性を高める。per-directory-history を使えば、特定ディレクトリの履歴だけを探したり、全履歴に戻したりもできる。履歴の保存量も調整できるという。
SQL では FROM のない SELECT ができる。これはデータベース関数の挙動を試したり、SELECT TRUE <> NULL のような式の結果を思い出したりするときに便利だという。PostgreSQL と MySQL では explain analyze が使え、実際にクエリを実行しながら性能の情報を詳しく見られる。正規表現では \b、つまり単語境界を使うと、単語の先頭や末尾を見つけやすい。メトリクスでは値の分布をざっくり把握するために対数を使う例も示されている。JavaScript では Array.flatMap、Object.entries、Promise.withResolvers が今では使える。Node.js では https.Agent を作ってリクエストに渡すことで接続を維持でき、遅延に大きく効くことがある。
さらに git の話が続く。git log -S pattern は、特定の文字列を追加または削除したコミットを探す「pickaxe」と呼ばれる技で、古いコードベースでは特に役立つ。git log -G pattern は似ているが、行が移動した場合も拾う。cd - が前のディレクトリに戻るのと同じ感覚で、git checkout - で前の HEAD に戻せる。ファイル探索では find . を使わず、**/*.md のような glob で済むことが多い。bash では shopt -s globstar が必要だが、多くの shell は最初から対応している。検索は grep や ack、ag より rg を勧める。zsh の高度な補完も、brew を使う環境では FPATH と compinit を設定しないと有効にならない、と著者は触れている。
最後に著者は、こうした例を全部知っている必要はないし、役に立たない領域の人もいるだろうと認めます。それでも、各人には自分なりの「小技の棚」があるはずだと言うのです。会社の中でも同じで、$PROBLEM を調べるには $DATA_SOURCE を使う、$AREA に詳しい $PERSON がいる、$HARD_THING には良い docs がある、$THING が起きたら手動でスケールアウトする、$THIS_COMMAND で rolling restart できる、$UTIL で $THAT_PROBLEM をスクリプト化できる、といった知識が高いレバレッジを持つ。著者自身も以前の会社で、こういう技術的・会社固有の小技を Slack で毎日 1 つ共有していて、9 個知っている人でも 10 個目が役立つし、1 日 1 個なら押しつけがましくならず議論のきっかけにもなったという。最後に、この発想は Julia Evans のブログで見たものだと述べ、彼女の文章が「small bits of knowledge are powerful! and fun! and approachable!!」という考えをよく表していると締めくくっています。
この文章でいちばん良いのは、抽象論に逃げず、ちゃんと手触りのある例を並べているところだと思う。fzf、atuin、rg、explain analyze、git log -S のような小技は、どれも単体では地味だが、現場では驚くほど効く。しかも厄介なのは、こうした知識が「知らなくても仕事はできる」点にある。だからこそ見過ごされやすい。けれど、詰まりどころで数分、数十分を節約してくれるなら、それはもう十分に価値がある。著者はその事実を、過不足なく言葉にしている。
ただ、ここで面白いのは、小技の価値が「技術力の証明」ではなく「認知負荷の削減」にあることだと思う。大きな設計判断は、背景知識や経験の蓄積がないとできない。一方で小技は、必要な場面で即座に使える。言い換えると、余計な思考を挟まずに済む道具だ。ターミナル履歴を探す方法を知っていれば、過去に打ったコマンドを思い出すために脳を使わずに済む。SELECT に FROM がなくてもよいと知っていれば、DB の挙動確認のたびに無駄なテーブルを作らなくていい。こういう省力化は、派手さはないが、日々の疲れ方を確実に変える。
著者が最後に触れた、会社で毎日ひとつ小技を共有するやり方には、かなり実務的な良さがあると思う。知識共有は、まとめて大量にやると受け手が身構えるし、結局見返されないことも多い。逆に 1 日 1 個なら、読む側の負担が小さい。しかも「今日はこれだけ知ればいい」という粒度は、雑談にもなりやすい。誰かが「それ、うちのサービスでも使えるかも」と反応すれば、文書化されていなかった暗黙知が少しずつ外に出る。これはオンボーディングにも効くし、属人化の予防にもなるはずだ。
一方で、このやり方には落とし穴もあると思う。小技は便利だが、断片のまま増えると、全体の設計を見失う危険がある。たとえば git log -S を覚えても、そもそも履歴が追いづらい運用を変えないままだと根本解決にはならない。explain analyze を使っても、クエリ設計の悪さまで魔法のように消えるわけではない。つまり、小技は万能薬ではない。だが著者はそれを過大評価していない。むしろ「大きな構造の代わり」ではなく「現場で効く補助輪」として置いている。この温度感がちょうどいい。
この文章を読んで感じるのは、経験豊富なエンジニアの強さは、難しい問題を一発で解く能力だけではない、ということだ。むしろ「よくある詰まり」をどれだけ軽く避けられるか、その積み重ねが強い。$PERSON knows a ton about $AREA という社内の人間地図もそうだし、$THIS_COMMAND ひとつで再起動できる運用知もそうだ。頭の中に散らばった小さな知識が、そのまま仕事の摩擦を減らしている。
私は、こういう知識の集め方はこれからもっと重要になると思う。道具が増えるほど、全部を深く理解するのは難しい。だからこそ「深くなくても使える断片」を、いつ、どこで拾うかが効いてくる。著者が Julia Evans に言及したのも象徴的で、技術知識は本来、威圧的なものではなく、試しやすくて、ちょっと面白いものであるべきだという感覚がある。小技を集める姿勢は、単なる時短術ではない。学びを怖がらず、使える形で貯めていくための、かなり健全な態度だと思う。
