(Neo)Vim Made Me a Better Software Developer

https://www.youtube.com/watch?v=5u604lTkGAY&list=WL&index=44

https://scrapbox.io/files/681a98094d9d98e812c71e22.png

https://scrapbox.io/files/681a9afab48c1a1b65bfd375.png

OpenSource は成長のツールとしてとてもよい

ただ、複数の要素が絡むので再現が難しいかも

https://scrapbox.io/files/681a9d60a141c143fecf3b9f.png

Epic で働いているときは顧客も見えないし、何をしているかが分かりづらかった。

一方で、Neovim 設定の場合は

やっていることがわかる

他の人と話せる

リズムがよい（開発スピード）

というメリットがいっぱいあった

https://scrapbox.io/files/681a9ecdcc58b5e7c3fb65e0.png

とにかく練習しよう。

API 設計がきれいだね、と言われたが、生まれたときからAPI設計がうまいわけでは当然ない。

Practice, 練習することでうまくなった。

バスケの本を読んでもうまくならないように、プログラミングもAPI/デザインパターンの本を読むだけではうまくならない。

PlayGround を用意してそこでどんどん練習すべき

https://scrapbox.io/files/681aa0816d6aebe83368c716.png

https://scrapbox.io/files/681aa08b9003ae285cde52a3.png

code:txt

ご提示いただいたソースは、YouTubeチャンネル「vim-jp」にアップロードされた「(Neo)Vim Made Me a Better Software Developer」という動画のトランスクリプトの一部ですね。

この動画で、発表者のTJ DeVries氏（オンラインではte TVとしても知られる）は、Neovimがどのように彼をより良いソフトウェア開発者にしたのかについて語っています。

まず、「ソフトウェア開発者」とは、主に日々の業務でコードを書いてビジネス上の問題を解決するプロフェッショナルであると定義しています。そして、「より良いソフトウェア開発者」とは、単にコーディングが速いだけでなく、同僚（未来の自分自身を含む）が自分の書いたコードを一緒に作業しやすいと感じること、顧客が自分と仕事しやすいと感じること、そして可能であれば顧客が自分の作ったものを喜んで使ってくれることによって特徴づけられるとしています。これは、高速なコーディングや特定のツールを使うこと自体が目的ではなく、より包括的な開発者としての資質を指しています。

氏は、Neovimが開発者をより良くするという議論には、多くの「ひどい議論」や「ましだが本質ではない議論」が存在すると指摘します。例えば、「C言語で書かれているから速い」とか「ブラウザでコードを編集する人を見下す」といった議論は、相手を遠ざけるだけで建設的ではありません。また、「他のツールより速い応答性」や「Vimのモーションによる素早いテキスト編集」も、それ自体は良いことですが、素早く悪いコードを生成できるだけでは本質的な問題解決にはなりません。多くのプラグインを使うことも、ジュニア開発者をシニア開発者にするわけではないとしています。

では、何が開発者をより良くするのでしょうか？氏は、オープンソースへの貢献や、使っているツールへの「楽しさ（Joy）」も重要だとしつつも、これらもまた本質ではないと述べています。楽しさはキャリア（マラソン）を続けるモチベーションにはなりますが、必ずしもスキルを向上させるわけではありません。

氏がたどり着いた核心は、「練習（Practice）」のための「遊び場（Playground）」練習の場が必要です。

氏は、自身の最初の仕事である医療記録システム会社Epicでの経験と、自分のNeovim設定に取り組む経験を対比させて説明します。

•

Epicでの仕事では、開発する製品や顧客が自分にとって馴染みがなく、顧客からのフィードバックを得るまでの時間が非常に長く、リリースのケイデンスが遅いため、アイデアを試して反復するサイクルが非常に長かったと述べています（変更が本番環境に反映されるまで6ヶ月から1年かかることもあった）。

•

一方、自分のNeovim設定や小さなプラグインに取り組む際は、自分が製品のユーザーであり、顧客であり、アイデアを試すサイクルが非常に速い（1秒以下で変更をテストできる）。バックワードコンパティビリティを考慮する必要も少なく、大胆な実験も容易です。

この「遊び場」のような環境では、以下のような開発者として重要なスキルを練習することができます。

•

ビジョンの明確化：最初のアイデアが失敗しても、それを改善する方法を考える。

•

デバッグ：エラーメッセージを読む練習（職場での問題解決にも役立つ）。

•

他人のコードからの学びや、シンプルさへの感謝（多数のプラグインが引き起こす問題から依存関係を減らす重要性を学ぶ）。

•

コラボレーションや技術的なアイデアの伝達：ドキュメント作成などを通じて、非同期のコミュニケーションを練習する。

•

人間関係の構築。

•

素早く、効率的に作業を進める練習。

結局、このトークはNeovim自体の話ではなく、「コードを書く練習をするための遊び場を見つける」ことの重要性を伝えるためのものだと氏自身が語っています。その遊び場はNeovimである必要はなく、他のエディタやプロジェクトでも構いません。

最後に、氏は「物事をVimのようにする（Make things Vim）」という奨励をします。これは、職場やチームのワークフローに、遊び場の原則（製品理解、顧客視点、イテレーション速度向上など）を取り入れることを意味します。例えば、リリースのケイデンスを月単位から日単位、時間単位、あるいは秒単位へと短縮したり、テストやビルドのプロセスを自動化・高速化したりすることです。そして、製品を使う人々（顧客やチームメイト、そして自分自身）に**喜び（Joy）**を振りまく方法を見つけることの重要性を強調しています。

結論として、氏がより良いソフトウェア開発者になれたのは、Neovimという**練習のための「遊び場」**を見つけ、そこで様々なスキルを継続的に練習できたからであり、他の開発者にも自分自身の「遊び場」を見つけること、そして職場の環境をより「Vimのように」（遊び場のように）改善していくことを勧めています。

まとめ

学んだことを遊び場でどんどんアウトプット・試行錯誤して、自分の「よいエンジニアとしてのスキル」を磨く

職場・チームのワークフローに、遊び場の原則を取り入れて、短いサイクルでリリースを行おう。

個人でまずは遊び場を作りそこで得られた経験を、会社・チームのプロジェクトでも導入する。