ハクソク

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

HNに聞く: 学ぶのに時間がかかった業界のコツは何ですか？

294日前

概要

  • LLM活用 に関する新たな手法の発見
  • 計画ドキュメント(plan.md) 作成の重要性
  • 段階的な実装 とテストの推奨
  • 経験から得た教訓 の共有
  • 他の人の 遅れて学んだコツ への興味

LLM活用における「計画ドキュメント」作成の重要性

  • 近年、 LLM（大規模言語モデル） のアウトプットを改善するための新しいテクニックを毎週学習
  • これまで、 個人的に段階ごと に作業を進めていたが、全体の設計図となる plan.mdドキュメント を最初に作成することの価値を最近実感
  • LLMに plan.mdアーキテクチャドキュメント の作成と洗練を指示し、その内容を テスト可能なフェーズ に分割
  • 各フェーズごとに 段階的に実装 することで、抜け漏れや品質低下を防止
  • このアプローチは一見 当たり前 だが、実践に落とし込むまでに時間を要した経験

HNユーザーへの問いかけ：遅れて学んだ「トリック・オブ・ザ・トレード」

  • 自身の分野で 習得に時間がかかったコツやノウハウ の共有を呼びかけ
  • 他のHNユーザーが持つ、 より興味深い職業上の知見 への関心
  • それぞれの分野で 「もっと早く知りたかった！」 と思うようなテクニックや手法の発見
  • 経験談の共有 によるコミュニティ全体の知見向上
  • 反省と学び を次世代に伝える意義

Hackerたちの意見

ほとんどの問題（解析的に解決できないものも含めて）は、比較的シンプルなモンテカルロシミュレーションでモデル化できるよ。シンプルなモンテカルロシミュレーションは、スプレッドシートで完全に実装できるしね。粒子物理学の実験でタイミングの一致を利用するのはめちゃくちゃ強力だよ。同じ反応から複数の製品を一度に測定できるなら、調べる価値があることが多い。カーバイドの刃を使った木工用の丸鋸は、アルミプレートを切ることができるし、原子レベルの薄い金属箔を水に浮かべて扱ったり、取り付けたりできるよ。図書館の検索ツールや学術データベースを使ってみて。ウェブ検索やAIよりも全然優れてるから。

└

モンテカルロシミュレーションのモデル化のテクニックは、直感的に身につけた気がするけど、最近になって正式に聞いた感じ。これを使って解決できる例題のリストとか持ってる？実際の問題にこのテクニックをどう適用するかのケーススタディ集みたいなのがあったらいいな。

└

最近のトップクラスの図書館検索ツールや学術データベースって、何だと思う？

└

木の先がついた丸ノコでもアルミプレートは切れるし、学術的な検索や図書館の検索は本当に過小評価されてるよね！

繰り返しの一貫した行動の力に集中して、自分の「未来の自分」を優先するための大事なポイント：もしこれを1,000日（または回）続けたら、何が起こると思う？例えば： - 毎日2時間運動して、正しい食事をとる → すごく見た目も良くなって、気分も最高だし、健康も周りの人よりずっと良くなる - このクッキーを他の食材と一緒に買うべき？もし1,000回の買い物でそれをやったら… - 毎日30分以上、最高の質の資料を読んで、ノートを取り、得た知識やアイデアを実践する方法を考える → …

└

日々の選択を広い人生の目標に結びつけるアプローチが好きだよ。もしまだ読んでなかったら、『Atomic Habits』も気に入ると思うよ。 [1] https://www.amazon.com/Atomic-Habits-Proven-Build-Break/dp/0...

└

これは面白いね。HNのコメントに1000日連続で返事したらどうなるんだろう？やばいな。

└

"私は見た目も良くなって、健康も同年代よりずっと良くなるつもりです。" 健康（や他の何か）を同年代と比べるのは、自信を高めたり維持したりするための素晴らしい方法だね。常にもっと健康的でセクシーで若い人がいるから、その追いかけっこは大変だよ。ありきたりに聞こえるかもしれないけど、自分を昨日の自分と比べるのが一番いいアプローチだよ。

└

どうやって1日2時間にたどり着いたの？私の理解では、1日1時間で2時間の90-95%の効果が得られるよ。言い換えると、2時間と比較して、15分で50%の効果、30分で75%の効果、60分で90-95%の効果、120分で100%って感じ。みんなそれぞれの閾値があるけど、5-10%のために倍の時間を払うのは、私にはあまり価値がないように思える。

└

多くの人が自分に体があることに気づくのに、あまりにも時間がかかりすぎる。

└

これいいね！ポッドキャスト好きなら、https://trypodly.com/をチェックしてみるといいかも。

└

私も似たようなことがあるけど、購入をコンテキストに入れるためのもの。質の良いジーンズを買って、毎年200日着ると、100〜200ユーロ払ってもコストパーウェアはほとんど無視できる。一方で、結婚式やおばあちゃんの誕生日にしか着ない高級スーツパンツは、コストパーウェアがめちゃくちゃ高くなる。だから、トップシェルフのものを買う必要はないかも、レンタルでいいかもね。おばあちゃんはビジネスカジュアルで大丈夫だから、ジーンズにブレザーで行けるし =) サブスクリプションも同じことが言える。YouTubeファミリーは安くないけど、私たちはYouTubeのコンテンツをたくさん見るから、広告をスキップできるだけで時間が節約できるのは十分価値がある。（それに、13歳未満の子供はYouTubeのファミリーに登録できないから、スキップできない広告がたくさん流れてくるのも面白いよね…）

Git bisect。特定のソフトウェアの回帰に対しては、生活を楽にしてくれるよ。多くの人（私も含めて）はこの機能があることを知らなくて、自分で車輪を再発明しちゃうんだ。 https://git-scm.com/docs/git-bisect

└

それとインタラクティブリベース。インタラクティブリベースとリフログをマスターして、目隠ししてもできるようになろう。

└

すごく役立つね。後からいつも言うのは「もっとテストが必要だ」ってことだよ。

└

git worktreeについて同じような気持ちだね。一度に複数のブランチをチェックアウトできるのは、stashを気にしなくていいから革命的だよ。

└

小さくて意味のあるコミットが大事じゃないって言う人には、必ずgit bisectを紹介するんだ。これを知ってる人で同意しない人に会ったことがないよ。

└

git bisectを生産的に使った回数は、片手で数えられるくらいだ。

└

便利なツールだけど、最後の手段的なツールって感じだね。

大体の人は、自分が何を求めてるかを合理的に説明できないから、面倒なインタビューやレビューなしにソフトウェアの良い仕様を期待するのは完全に夢物語だよ。人は「見たら好きだって分かる」から、時間をかけてラピッドプロトタイピングするのがいいよ。最近の小さいやつだと、iTermはtmuxのサポートが深いよ。セッションを始めるにはtmux -CCを使うか、接続するにはtmux -CC aを使えば、tmuxのコマンドを全部覚えなくても大丈夫。

└

それに、その人たちの半分は「何を作るべきか」を教えてくるから、そこから逆算して実際の問題を見つけ出さないといけないんだよね。それからまた前に進んで、実際に何を作る必要があるかを考えないといけない。

良いコードは期待通りに見えないこともある - 重複コードが必ずしも悪いわけじゃない。* 同じコードをコピー＆ペーストしたり繰り返した方が、サブルーチンにまとめるよりも理解しやすいことがあるよ。コードを書くときは論理的に思えるけど、コードを読むときには理解を妨げることがある。予測可能な方がコンパクトよりも良い場合が多い。 - コードは早く失敗すべき。* "堅牢であること"、エラーを修正することやエラーの後に続けることが間違っている場合もあるよ。予期しないことが起きたときは、失敗して早く失敗することが重要かもしれない。 - 明示的な方が暗黙的より良い。* 何かからリストを構築するよりも、リストをハードコーディングした方がずっと良いことがあるよ。具体的な例としては、.cをコンパイルするmakefileと、one.c、two.c、three.cをコンパイルするmakefileがある。リストをハードコーディングして、何かが欠けていたり追加されたりしたら、厳しく失敗させるようにするんだ。そう、もっと手間がかかるけど、それを防ぐための狂気は価値があるよ。こういうことは多分何千もあるだろうね。全部意見だから、キャメルケースがダメだとかインデントは4にすべきだとか、タブ文字は使わない方がいいとか。* いつもではないけど。

└
  • 同じコードをコピー＆ペーストしたり繰り返した方が、サブルーチンにまとめるよりも理解しやすいことがあるよ。 "Write Everything Twice"の原則は、馬鹿げたDRYプラクティスに対する必要なサンティチェックだね。基底クラスと2つの特殊化クラスを書くことで、2つのクラスを書く手間が省けるって真顔で主張するナイーブな人が多すぎるよ。
└

今週だけで、これらの項目についてジュニア開発者と話した気がするんだけど、もしかして監視されてる？私たち、同一人物なの？

└

あなたの2つ目のポイントには強く同意する。エラー処理をしようとして、実際にはエラーを隠してしまってデバッグが難しくなる問題に何度も直面したことがある。典型的なアンチパターンは、SomeErrorTypeをキャッチして「そのタイプのエラーが発生しました」とログに残すこと。そうすると、関連するエラーメッセージやスタックトレースが隠れてしまう。さらに悪いのは、すべてのエラータイプをキャッチしようとすること。役に立つことをしない限り、エラーをキャッチしない方がいいよ。それでも、再スローするのが良いアイデアなことが多い。

└

そう考えるのが好きだな。DRYコードを書くような原則は持つべきだけど、原則を行き過ぎてしまうと悪い結果になることもある。極端にならないで、やることすべてにおいてバランスを大事にしよう。これはプログラミングだけじゃなくて、人生のほとんどのことにも当てはまると思う。

└

あと、時にはコードブロックを一般化しようとするより、コピー＆ペーストの方が早いこともあるよね。

└

あなたの最初のポイントについてだけど、リスコフの置換原則を理解することが大事だと思う。要するに、今はコードが同じに見えても、そのコードの周りの文脈が変われば将来的に分岐する可能性があるってこと。だから、そのヒューリスティックのおかげで、特別なケースがたくさん必要になるかもしれない統合をするのにちょっとためらいが出てきた。

└

三の法則：「同じコードを三回書いたら、そこで立ち止まって抽象化するべきだ。」これはマーチン・ファウラーの『リファクタリング』からの引用だと思う。（ちょっと前のことだから忘れかけてるけど）要は、一つか二つのケースでは間違った抽象化を作ってしまうかもしれないけど、三つあると正しい部分を抽象化できるってことだ。無駄なオプションやブール値のモンスターを作らずにね。

プログラミングのトリックじゃなくて、人生はきれいでスムーズに進むわけじゃないってことだよ。物事がめちゃくちゃになったり、計画が狂ったりするのに対処する方法を学ぼう。「連続記録を失った」とか、そういうのを受け入れることも大事。明日は新しい日だし、いつでもやり直していいんだ。長期的な最適化は大事だけど、明日の朝には死んでるかもしれないってことも忘れないでね。

└

遅すぎるくらいに学んだライフハックの一つは、仕事でもプライベートでも楽しむことが許されているってこと。毎週、ちょっとした軽い瞬間やリラックスした時間を楽しむべきだと思う。なぜか、常に生産性を追求しなければならないと信じ込んでいて、それが燃え尽きる最も早い方法だった。

└

こういうことを考え始めると、地球上の多くの人たちの生活がどれだけ大変か想像しちゃうんだよね。私たちって、恵まれてるよね。

└

くそ。

└

この例えには異論があるかもしれないけど、私は人生をインデックスファンドへの投資みたいに考えてる。いろんな側面やプロジェクトに分散投資する感じ。インデックスファンドがいろんな会社やセクターに分散してるのと同じようにね。多くの投資は失敗するけど（市場の多くの会社が崩壊したり上場廃止になるのと同じ）、中にはものすごいリターンをもたらすものもあって、それが他を支えてくれる。でも、どれがいつ成功するかは事前にはわからない。波があるけど、長い目で見れば、続けて生き残れば期待される結果は上向きになるよ。

└

明日は新しい日だ。今日は新しい日だ。

一時的な解決策は、特定の時間内に修正することを自分に課さない限り、永続的な解決策になってしまう。時間が経つほど難しくなるからね。これは、コードベースのTODOから、開けてない引越しの箱、友達からもらったソファの交換、毒のある関係を続けることまで幅広い。しばらくすると、その状況に慣れてしまって問題が見えなくなり、本当に壊れていない限り、変化するモチベーションを持つのが難しくなるんだ。

└

それに、これを学んでも他の人は信じようとしないし、全く無意味で、むしろ世界にマイナスな貢献になるような何ヶ月もの作業に堂々と取り組むことに同意するんだよね。必要な他の数ヶ月の作業は絶対にやらないから。そして、45番目のプロジェクトプランに「いや、これやるべきじゃないよ」と言うと、彼らは怒って、自分の心に誓って、後半を実現させるか、何もかもダメにするかのどちらかを強制しようとする。で、6〜12ヶ月後にまた同じことを繰り返すんだよ！まるで金魚みたいに！

└

古いコードベースって、ほんとにたくさんあるよね。

└

うわ、マジか。何か学んだ気がする。ありがとう :)

└

16年前、今の会社で契約社員として働き始めたとき、テストデータをもらったんだ。それを{domain}Tempっていうテーブルに入れたんだけど、そのテーブルは今も存在してる。実際、私たちの生産データの約半分がそこを通ってるんだよね。で、15年間ずっとそれを変えようって話をしてる。うーん、辛いね。

└

これは素晴らしいアドバイスだね！

└

これは多分私だけかもしれないけど、逆のことを思い出す必要があるんだ。すべての解決策は一時的で不完全だってこと。だから、何かをやってみるべきだよ。いつでも戻って修正できるしね。私にとっては、引っ越しボックスから3つのものをしまっておくことが許されるってこと。まだ他のものをどこに置くか分からなくても、他の人を招待したり、何を作るか決めていなくても、まずは手早く悪い実装を書いてみる。最適なものを見つけるのに何時間もかけるよりはね。完璧主義と「やってみる」姿勢のバランスが大事だと思う。でも、人それぞれの傾向があるから、状況によってはどちらのアドバイスも意味があるかもしれないね。

ドイツのことわざに「Auch nur mit Wasser kochen」ってのがある。ざっくり言うと「彼らも水で料理しているだけ」って意味。要するに、誰も何も知らないし、特別な人はいないってこと。

└

HNで見かけるアドバイスには、非常に関連性がある。

└

でもプログラミングでは、スキルや基礎的な理解が大きく異なるから、みんなが水で料理しているとはいえ、料理の仕方には大きな違いがあるよ。 :P

└

いい言葉だね。昔聞いたことがあるんだけど、大人は年を取った子供だって。人は理性的に見えたり、そうしようとしたりするけど、実際には感情にすごく影響されてるし、コントロールされてることもある。理性的に見られたいという欲求もその一つの原動力だよね。「これは正しいことだから」という理由でやってることの多くは、実は自分の不安を減らすためにやってるんだ。この意味では、私たちはまだ子供なんだよね。

└

みんなのクソは同じ匂いがする。

  1. 女性の月経周期の影響について理解するのに時間がかかりすぎた。男の子にはあまり知られてない（特にインドでは）。女の子が不規則に振る舞う理由を不思議に思ってる。もっと早く性教育が必要だね、特にインドでは子供たちが大人のコンテンツに触れる機会が増えてるから。 2. rmコマンドを使うときはすごく気をつけて（alias rm='rm -i' を使うといいよ）。 3. バックアップのバックアップのバックアップを持っておく。 4. バックアップが正しく復元できるか定期的にチェックする。（もしうまくいかなかったら、かなりショックを受けることになるから） 5. あなたに報告する人たちは、日によって違う。数回の出来事で判断しないで。（少なくとも20回はチャンスを与えてから、プライベートでネガティブなフィードバックをあげるべき） 6. 友達は家族よりも役に立つ。（人生の優先事項が似てるから）50歳を過ぎたら、特に学校や大学の友達と連絡を取り続けるのが大事。今は連絡が取りやすいからね。（コロナで家族のサポートが少ないクラスメートを何人か失った） 7. お母さんや妻、祖母の好きなレシピを全部覚えておくといいよ。絶対に悲しくならないから。少なくとも2人分作って、シェアしよう。（普段使う器具のサイズを適切に選んでね。小さすぎず、大きすぎず） 8. ヴィパッサナーを使って現実をそのまま受け入れること。これは不正なAIの使い方に対抗するためのスーパーパワーだよ。（インドのボーパールで10日間のコースを終えたばかり。新しいコースは世界中にある）* これはお金をもらってるわけじゃない。私は本当に#Vipassanaが効果があると思ってる。ちなみに、ユヴァル・ノア・ハラリ（『サピエンス全史』や『ネクサス』の著者）もこれを支持してるよ。https://www.youtube.com/watch?v=i1_YhlXiuxE このリンクから近くのコースを見つけられるよ。https://www.dhamma.org/en-US/courses/search?current_state=Ne...（無料で、寄付で運営されてる） 9. 水筒と平たいお弁当箱を持っておく（空でもいいけど、ビスケットや残り物を入れておくのもあり） 10. 楽しむことを忘れないで。（私たちはよく忘れちゃう）(kk.orgにはその方法についてのアドバイスがあるよ)

プロのソフトウェア開発についてだけど、顧客は解決策を買うんだ。仕様書やエレガントなコード、自動テストのカバレッジなんて買わない。これらは、顧客に解決策を早く提供するのに役立つ限りでしか意味がない。もっと努力するなら、実際に顧客のために解決策を作ることに使った方がいい。メンテナンス性はほぼ最優先だけど、本当に最優先なのは、そもそもメンテナンスするものを持っていること。補足として、クイック＆ダーティには理由がある。クイック＆ダーティがただの汚いものだと言うのは簡単だけど、実際その通りで、長い目で見るとクイック＆ダーティは正しいことよりも時間がかかる。でも、ここにポイントがある：時間には常に同じ価値があるわけじゃない！締切直前の時間は、締切後のリラックスできる時間よりもずっと貴重だ。今すぐ動かして出荷しよう。来週にはもっと良い状態にするから、顧客は新しいおもちゃで遊んで喜んでるよ。

└

顧客に「あなたが望んでいることは、a) うまくいかないし、b) コスト効率が悪い」と伝えるのも良いアイデアかもしれない。顧客を「失う」かもしれないけど、無駄なものを作らないっていう評判が広がるかもしれない。それが後々、もっとビジネスを呼び込むことになるかも。あと、クイック＆ダーティな解決策を作るときは、見た目も汚くするべきだよ。派手なUIにジャンクなバックエンドだと、顧客には洗練されたソフトウェアに見えるから、ユーザー体験をコードの進捗と合わせておくべき。バックエンドが進行中なら、デモのときはUIはスタイルなしのプレーンなHTMLコンポーネントだけにするべきだし、UIがないなら、バックエンドは生産準備が整っていないことを明確にするために、いろんなジャンクなデバッグメッセージを出力すべきだよ。