世界を動かす技術を、日本語で。

小屋を守る

概要

  • 超高層ビル建設裏庭の小屋作り を対比し、エンジニア人生の二面性を描写
  • 企業での大規模開発個人プロジェクト の経験が相互に作用する重要性を強調
  • 個人プロジェクト がエンジニアとしての好奇心や創造性を維持する役割
  • 大規模開発 で得た知見を 個人開発 で応用することで成長を実感
  • キャリア維持 には個人プロジェクトの継続が不可欠であると結論

エンジニア人生の二つのモード

  • 超高層ビル建設 :設計図、許可、監査など多くの準備工程が必要
  • 裏庭の小屋作り :計画なし、自由に材料を使い、即興で構築
  • 企業開発 :数百人規模の連携と長期間のプロジェクト進行
  • 個人プロジェクト :週末だけで完結する自由な創作活動
  • 仕事と趣味 の二重生活という捉え方

企業開発で学ぶスケールの物理

  • 実際のコーディング は全体作業のごく一部
  • 設計書、テスト計画、レビュー などのドキュメント作成
  • 大規模システム では設計やテストの手抜きが許されない現実
  • Cloud Spanner など規模特有のツール利用経験
  • 防御的設計思考障害モード の事前検討
  • 規模の大きさ が生む硬直性と自由度の制限

個人プロジェクトで設計を遊ぶ

  • 個人開発初期 は設計やアーキテクチャを軽視しがち
  • 企業で培った設計パターン が自然と個人開発にも浸透
  • Homelab でのインフラ自動化やコードによる構成管理
  • 自由な実験環境 で構造的規律を自分流に応用
  • 個人プロジェクト が安定し、成長を実感

個人開発の自由と学び

  • 失敗のコスト が小さく、試行錯誤が容易
  • 開発者・レビュワー・ユーザー を一人で兼任
  • 新しいツールや技術 を気軽に試せる環境
  • GBAエミュレータ をGoで構築するなど、好奇心主導の開発
  • 実験ごとに新しい知見や反省点 を獲得

好奇心とキャリアの持続

  • 企業開発 は価値が大きいが、単調さや疲弊に陥りやすい
  • 個人プロジェクト はソフトウェア開発の楽しさを再発見できる場
  • 仕事と趣味 の両面から技術を体得することで、成長の加速
  • 失敗や試行錯誤 を通じて、現場で即戦力となる知識を獲得
  • 個人開発 がエンジニアとしての本質や創造性を守る役割

エンジニアとしての自分を守るために

  • 日常業務 だけに依存すると、創造性ややる気が低下
  • 個人プロジェクト は好奇心や実験精神を維持する生命線
  • 企業開発 が「生き残るコード」の書き方を教え
  • 個人開発 が「書きたいコード」を守り続ける理由
  • 自分をエンジニアたらしめる場所 として、個人プロジェクトの継続が不可欠

Hackerたちの意見

この投稿にはすごく共感した。毎日の単調な作業の中で、子供の頃にプログラミングに夢中になったその「火花」を失ってしまって、しばらくは不満を感じてたんだ。趣味(またはシェッド)プログラミングに戻ろうと自分を奮い立たせてから、昔の情熱が再燃して、結果的に仕事がずっと耐えやすくなったよ。

逆に、俺は実際にシェッドを持ってて、そこでメンテナンス作業をしたり、物を作ったり(最近作ったのは自動給水器)、ビールを作ったりしてる。デスクワークでテクノロジー中心の仕事をしてるから、オフの時間に手を使うのがすごく充実感があって、精神的にも助かってる。人それぞれってやつだね。

これを約10年やってたけど、全く後悔はないよ。すごく楽しかったし、サイドプロジェクトがエネルギーをくれた。今はちょっと難しいけど、新しい言語を学びながら彼女もいて、フルタイムで demanding な仕事もあるから、いじる時間があまりない。これについては少し悲しいけど、ただの人生だと思ってるし、子供がいたらどれだけ不可能になるか想像もつかない。LLMを使って基本的な家事をやろうと考えたこともあって(依存関係の更新とか、プロジェクト間のテストの標準化とか)、実際に200以上のサイドプロジェクトがあることに気づいた。ほとんどがウェブサイトやJSライブラリ、Reactライブラリだけど、80%はゴミだとしても、実際にやったことの多さにはちょっと驚いた。

夜遅くに数時間いじったり、落ち着いて挑戦的でインスピレーションを与えてくれる本を読んだりする特別な感覚があるよね。でも、時間もエネルギーもないときは、毎日少しでもこういうことをするようにしてる。0分と15分では大きな違いがあると思う(運動や瞑想も含めてね)。もっと時間があればいいけど、30分や45分を超えるとリターンが減ってくる。

シェッドでいじってることを記録して共有できる場所ってあるのかな?人々の発明やデバイスを「恩送りサークル」で回して学びやインスピレーションを得るってアイデアがあったんだ。クリスタルのことで既にやってる人もいるし。同じことに取り組んでる人が何人いるかを知ることで、協力し始めたら最先端の開発につながるかな?DIY好き同士のアイデアのやり取りと、研究所で作られたプロトタイプの間には常に緊張感があると思う。このアイデアは、ただの別のサブレディットや既存のチームワークソフトを使う以上のものなのかな?もし何かを共有したいなら、すでに作ったものの中からどうやって選ぶ?商業化の助けが必要かも?DIYデバイスを共有することには責任やリスクがあるのかな?https://openhardware.directory/ や https://ohwr.org/ について考えてたんだけど、プロジェクトをリストアップすれば、エージェントが人を集めて新しい開発方法を見つける手助けをしてくれるかも。分散しているプロジェクトに価値を加えることが大事だよね。計画を立てたり、それを追ったりする簡単な方法はないかな?世界中での重複作業を最小限にするには?科学者向けの「ユニバーサルコマースプロトコル」(http://ucp.dev)みたいなものが必要かもね。

Hackaday.comが思い浮かぶね。あそこはそういういじり系のブログだよ。Hackaday.ioは、みんなが自分の回路図や作業ログを保存したり、発明やいじりをリアルタイムで発表したりする大きなプラットフォームだ。

GitHubって聞いたことある?それともフォーラム?

趣味関連のフォーラムは、似たようなプロジェクトに取り組んでる人たちが協力して最新情報を共有するのにすごくいいよ。いくつかのランダムな例を挙げると: https://www.lathetrolls.com/ https://www.shroomery.org/

高層ビルの構造的な規律を取り入れて、自由な空間に応用するってことだね。うーん、いや、実際に家に持ち帰ると毎回失敗するんだよね。企業向けのシステムを維持するために必要な作業のスケールが、俺が合理的に割ける時間をすぐに超えちゃう。別のケースでは、つまらない企業のゴミみたいなもので興味を失っちゃうし。みんなの「ホームラボ」ってどうやって耐えてるのか分からないよ。仕事で手がかかるLinuxボックスが十分すぎるくらいあるし。著者の言ってることは一理あるけど、実際には双方向じゃないんだよね。趣味のことはキャリアに繋がるけど、逆にすると大抵は逆効果か、メンタルに悪影響だよ。キャリアを進めるために小屋でいじくり回すのはやめた方がいいよ。がっかりするだけだから。ネタバレごめん。小屋でいじるのは、自分が楽しいから、人生に喜びと意味をもたらすからやるべきだよ。そうすればもっと生産的になれるし、俺の経験上、仕事に役立つことを学ぶ可能性も高くなるよ。

プロの「ホームラボ」と個人の「ホームラボ」を持ってるよ。君の言う通り、時間を食うことがあるよね。大事なのは、時間を「メンテナンス」じゃなくて「設定」に使うこと。コツは二つあって、もし「宣言してデプロイ」じゃないなら、動かさないこと。バックアップ/リストアパイプラインに入ってないなら、動かさないこと。PfsenseとHome Assistantは本当に面倒くさい。他のは簡単なんだけど。Proxmox/pbs/truenas/talos/linstor/DRBDは全部素晴らしいよ。今はpfsenseをtailscale/cloudflareトンネルに切り替えようか考えてるけど、今はその時間をかける価値はないかな。HAのための実行可能な代替は持ってないし。

趣味を過剰に設計しないことがコツだよ、もしそれが単にポイントを証明するためだけなら。つまり、そうだね、フルの企業CAを運用して、ドメインのSSL証明書を発行したり、手動でWireGuardを設定して自分の内部企業VPNを運営することもできるけど… 1人の同時ユーザーしかいないイントラネットなら、TailscaleとワイルドカードLE証明書を設定する方がずっと良いってことを受け入れた方がいいよ。ブラウザが静かになるからね。(これはまだ良くないけど、HTTPSとイントラネットについての議論は今は置いとこう。)Dockerのような他のデプロイツールも同じで、サーバーレスのセットアップのための永続ストレージをするための素晴らしい方法がたくさんあるけど、現実を見よう。ソースフォルダを/opt/に放り込んで、そのサーバーにはちょうど1つのドライブしかないんだから。面倒を避けるために、ファイルシステムのどこかにバインドマウントするだけでいいよ。フォルダをcp/rsync/rclone/scpでバックアップできるのは、Dockerの曖昧なoverlay2サブフォルダをいじるよりずっと簡単だから。今日の過剰設計の決定は、明日の「くそ、またサーバーにSSHしなきゃいけないのか、予期しないエッジケースのために」につながるんだ。

実は、今日、家の古いサーバーの山を一掃した雷の一撃に感謝してる。これで一気に全てから解放されたんだ。その時点で、自分が何かをコントロールしているなんて思い上がりは完全に消えたよ。UPSを使っているから大丈夫だと思うかもしれないけど、数フィート以内で直撃したら、電磁的な影響を止めることはできないからね。すべての銅が光ることになるよ。100%保証された解決策はないけど、EC2とスナップショットは、そういう単一のイベントから生き残る可能性がはるかに高いよ。

OPは理想的な社員って感じだね。8時間働いて、さらに週末に4時間家で学んだり働いたりするみたい。別のことをやりたい人にとっては、仕事が5日間のほとんどの時間とエネルギーを奪ってるから、他にやることがあまりないように思えるよ。

OPは理想的な社員って感じだね。8時間働いて、さらに週末に4時間家で学んだり働いたりするみたい。これを理想的な社員って呼ぶのは気をつけた方がいいよ。例えば、俺はちょっとそんなスケジュールになりがちだけど、家でやってることの方がずっとワクワクするから、仕事がそれに比べてすごくイライラするんだよね。それに、通常は、家でテストしたり実装したりした良いアイデアを仕事に適用することは許されてない(または不可能)。だから、こういうパターンを適用する社員は、プログラミングに対して非常に情熱的だけど、その情熱が仕事でのフラストレーションを増やすことが多いんだ。つまり、 - シニカルになったり、 - 従順じゃなくなったりすることがある。彼らは「夜の仕事」でより良いことを知っているから、要件が意味をなさないことを声高に言ったりするし、 - 自分の「技術的な好み」に対して非常に意見が強いけど、雇用主が望む技術的な好みとは必ずしも合わなかったりする。彼らはもっとたくさんのプログラミング技術を見てきてるからね。

一つ学んだことがあるんだけど、みんな同じ言い訳をするよね。「時間が足りない」って。特に多いのは、運動と瞑想。時間はたっぷりあるのに、優先順位がないだけなんだよね。

小屋は、仕事で学んだ設計図を実際に遊ぶ場所だよ。 > 週末に小屋で何かを試すのは、好奇心からだよね。トレードオフや粗い部分、ドキュメントには書いてないことを学ぶんだ。数ヶ月後、職場のチームが同じツールやアプローチを評価しているとき、ゼロから始める必要はないんだ。これらは対立する概念だけど、どちらも真実で補完し合ってる。クライアント(または企業)向けの仕事と、家でのサイドプロジェクトは表裏一体で、お互いを補完し合うんだ。どちらの場合も、あなたを駆り立てるのは好奇心と役に立つことをしたいという情熱だよ。俺の夢は、家でのプロジェクトを収入を生むものにすること。自分が愛することや、役に立って利益を生むプロジェクトに取り組む自由を持つことが目標なんだ。

あなたの夢について話す電話をかけてもいい?俺も似たような状況だから。メールアドレスはプロフィールにあるし、コメント履歴も残ってるよ。ちょっと前のめりだったらごめん。こういう夢についてブレインストーミングするのは楽しそうだし、補完的な経験があるかもしれないから。

俺はリタイアしてる(本当は選んだわけじゃないけど)、で、コードを書くのにめっちゃ時間を使ってる。20個以上のアプリを作ったよ(いくつかはもう使われてないけど)。リタイアしてからがほとんどだね。仕事の範囲を大幅に減らさなきゃいけなかったけど、クオリティは落としてない。ひとりで作業するから、目標も小さくなるしね。LLM(大規模言語モデル)はここでゲームチェンジャーだよ。範囲を再拡大するのに助けられてる。給料もらってた頃には戻ってないけど、たくさんのことを成し遂げてるよ。

俺は小屋を持ってるんだけど、その意見には賛成だな。ロックダウン中にそこでプロとして働いたのは失敗だった。創造的なスペースが、悪い職場の感情的な重荷を背負った場所になっちゃった。でも、今はほぼ克服したよ。どうやって作ったか見たいなら、ここを見てね: https://www.secretbatcave.co.uk/house/shed/ 最近の「完成した」プロジェクトはこれだよ: https://www.secretbatcave.co.uk/projects/despatchbox-pro/ これは電子機器が含まれてないんだ。俺には珍しいことだね。特に誇りに思ってるプロジェクトはこれだよ: https://www.secretbatcave.co.uk/projects/electromechanical-c... これは音叉を使った時計で、https://www.secretbatcave.co.uk/projects/stock-ticker-machin... これは株価ティッカーの模倣だよ。

このポイントが大好きなんだけど、「高層ビルと小屋の違いがわからない」ってのが、ソフトウェア開発について考えたり話したりする上での最大の障壁かもしれないと思う。例えば、「バイブコーディングは良いのか悪いのか?」って。状況による!小屋には問題ないかもしれないけど、高層ビルにはひどいかも。もしかしたら、高層ビルの中にはバイブコーディングできる部分もあるのかな?わからないけど。

高層ビルの仕事も、低層の仕事も持ってないけど、このアーティクルには感謝してる。ボロボロの小屋プロジェクトを、頑丈な低中層に変える方法を独学してるからね。無限に長い迂回路をたどって、行き止まりにぶつかることも多かったけど、OSからCSSまでたくさん学んだよ。ようやく、以前思い描いていたよりもシンプルな形でまとまってきた。多分、今年中には完成すると思う。