量には独自の質がある。

その結論には大体同意するけど、ちょっと naive すぎるかも。量のグループはメトリックを「ハック」する簡単な方法があるんだ。何でも写真を撮りまくるだけでいいから。カメラをセットして、昼夜問わず自動で写真を撮らせることもできる。正直言って、動かない壁の前でやってない限り、良い写真が撮れる確率は高いと思う。サンプルが十分あれば、ほんの小さな確率でも期待される結果になるからね。でも、本当の魔法の成分は説明にあると思う。>「グループは自分たちの作品の質を気にしなかったので、照明や構図などを試す時間を持っていた。」この文を読むと、「量のグループは成績に自信を持っていたから、プレッシャーなしで創造的になれた」ってことだと思う。でも、もし実験を変更して、学生を曲線で評価し、撮った写真の数に比例させたら、結果は違ってくるかもしれない。誰かが「ただ写真を撮りまくってるだけだ」って伝えるだけで、成績が不安定に感じるかもしれない。この状況では、質のグループよりも探索や実験の能力がさらに少なくなると思う。でも、メッセージは正しいと思うし、創造的な仕事や主に頭を使う仕事（コーディングを含む）ではこの戦略が正しいと思う。プロセスが創造性に依存するほど、このタイプの探索や自由に多くの時間を割く必要がある。研究のような仕事では、これが構造の基礎になるべきで、評価基準はほとんど取り除いて、基本的にアドホックな性質を受け入れるべきだと思う。コーディングのようなことでは、もっとミックスが必要で、その適切なミックスは実際の目的に大きく依存すると思う。だから、何がその目的なのかを考える上で、この区別が重要だと思った。

幸運なことに、成功しなきゃいけないプレッシャーなしでミュージシャンを目指すことができるよ。この道を進んでいけば、いつか自分自身で成功を宣言できる日が来る。

学校でロボティクスを専攻しなかったことを本当に後悔してる。プログラミングがしたかったから、コンピュータ工学を勉強したけど、授業ではあまり吸収できなかったな。でも、学校が持ってたロボティクスの設備や指導を受けることはもうできないだろうし。もちろん、何かを試すのに遅すぎることはないけど、比較的小規模なクラスでの構造化された高等教育にはかなわないと思う（ロボティクス専攻はたしか24人くらいだったかな？）。

面白い偶然だね。俺もロックスターになりたかったし、少なくとも成功したミュージシャンになりたかった。 今も音楽はやってるけど、フルタイムじゃなくて、日中の仕事で自分を支えながらやってる。人によっては「夢を追いかけなきゃ後悔するよ」って言うけど、これは自分の選択を後悔してる人が言うことだよね。他の人は「夢を仕事にしちゃダメ、そうすると特別じゃなくなるから」って言うけど、これは夢を追うことが何を意味するかを誤解してる人が言ってる。俺はこう思う。幸せは追いかける夢や選んだ職業にはない。毎日自分が何をするか、どう見るか、そしてそれを持つことを許すかの選択にあるんだ。毎日を構成するものは重要じゃない。でも、これは俺の考え。

まずやってみて、それから正しくやって、最後にもっと良くする。

これは大体正しいと思うけど、メンタルモデルを持つことと反復することの必要性も強調したい。プログラマーがモデルを考えずにプログラミングを始めて、ただコードを重ねて問題を解決しようとするのはよくあることだと思う。最初の「動く」実装で満足して、反復しないプログラマーも多い。最近は、プログラムについて考えることが少なすぎる気がする。コードを書く前に、少しでも紙にマッピングすることが大事だと思う。

事前にハード要件を知っておくことは、正しいものを作るために重要だよね。「一時的な」ものが本番環境に乗っかって、ずっと残っているのは怖い。もちろん、緩やかな結合や明確なインターフェースがこれを助けるけど、簡単な例として「シングルプレイヤーバージョンを作るだけ」っていうのは、野菜を食べるよりも悪いことがあるかもしれない。マルチプレイヤーを後から追加するのは難しいから、最初からそのつもりで作る方がいい。

「スタートするために“バカな”コードを書いた方がいいと思うよ。 momentumを得るためにね。最初のイテレーションに依存しすぎると、プロジェクトやスタートアップ全体が技術的負債に溺れちゃうかも。だから、飛び込むのは次の条件があるときだけだよ：A) それが一回限りのもので、すぐに結果が欲しいとかデモ用とか B) 捨てやすくて、誰もそれを出荷しようとしたり、メンテナンスさせようとしない場合。とはいえ、あまりにも摩擦が多くて分析麻痺になって、何も出荷できないのも良くないね。」

俺は両方やることが多いよ。時間はかかるけど、全体的なアーキテクチャが良くなる。最初に機能的なものをゼロから書いて、要件や制約を理解するんだ。それが有機的に成長して、アーキテクチャは悪くなる。製品をよりよく理解したら、まずはより良いアーキテクチャについて深く考えてから、基本的にゼロから書き直す。複雑な製品では、何度もイテレーションが必要になることもある。

だから、コードを書かない「ソフトウェアアーキテクト」は好きじゃないんだ。自分が設計したコードすら書かない人は特に。

いつもアーキテクチャを考えておくべきだよ。でも、今のアプリケーションの規模や複雑さに合ったものであるべきだね。5年後の姿を想像するんじゃなくて。進化させていくのはいいけど、常に持っておくことが大事。

「まずは存在させろ。後で良くすればいい」っていうフレーズが、周りの界隈でちょっとしたマントラになってるよね。

動くプロトタイプがあれば、コードだけじゃなくて仕様やユーザーもテストできるからね。

だから、ソフトウェアエンジニアリングの職業が嫌いなんだ。出すために「バカなコード」を書いて、昇進して次の仕事に移って、未来のエンジニアがそのゴタゴタを片付けなきゃいけなくなる。だけど、経営陣や他の人たちは、未来のエンジニアがなんでそんなに苦労してるのか、技術的負債がなんでこんなに多いのか、そして大きな改善にはなぜ大規模な再作業やリファクタリングが必要なのか理解しないんだよね。だから、バカなコードを書いた人は昇進して良く見えるけど、その後のゴタゴタを処理する人は悪く見えちゃうんだ。

以前は先を考えたり、計画を立てたり、「アーキテクト」しようとしてたんだ。 何をするかによるよね。ネットワークプロトコルを作るなら、構築を始める前に慎重にアーキテクトするべきだし（他の人もそうするかもね）。問題は「これを間違えたら、どれくらい影響があるのか？」ってこと。コアサービスのAPIを間違えると大きな影響が出るけど、小さなモバイルアプリを書くのはそのアプリ自身にしか影響しない。でも、もし小さなアプリの反復を始める前にそのことを考えたら、もうアーキテクチャの決定をしてるってことだよね :-)。

俺の考えでは、特定のタイプのソフトウェアにはテストや計画、メンテナンスが不要だと思う。プロトタイプ（スタートアップ）は「正しく作る」贅沢はあまりないから、実際の目標は「市場に早く出すこと（そして市場を維持するために十分に動作させること）」だよね。ゲーム開発者は、だいたい作って出荷して終わり、プレイヤーはほとんどのバグを許容するし、すぐに次のキラキラしたものに移るから、すべてを修正する時間が来る前に進んでしまう。製品が市場で traction を得て、支払い顧客ができたら、その時に負荷（スケールアップ）やバグに対処するべきだと思う。どこかで読んだことがあるけど、スタートアップチームは解散させた方がいい、彼らは仕事を終えたから（次の素晴らしいアイデアに進む自由がある）、スケールアップチームに置き換えるべきだ。彼らが計画や設計、ソフトウェアの長期的なライフサイクルの準備をする。例えば、Facebookのアプローチはうまくいったと思う。彼らは市場をすぐにキャッチしたPHPプロトタイプを持っていたし、（俺の意見では）スケールアップチームに移行すべきだった。元のコードをファサードとして使い、何か新しいもの（当時はJava/C++が利用可能だったけど、今はGoを勧める）に置き換えることができたはずだ。

綺麗である必要はない EVEN IF あなたのためでなくても。 計画には「演劇」がたくさんあって、実際にコードを書く前に何週間も無限のチケットを書いて洗練するのは、ソフトウェアを作る上で逆効果だよね。 「高給の仕事」があって、プロトタイピングや問題のモデリングを始めて、反復的に完全なソリューションに改善していけるなら最高だと思う。改善の雪だるま式の進展や機能の完全性が「納品スピード」の加速として現れるのは否定しないし、コードを生み出す体験はすごく楽しい。好奇心に駆られた問題解決に深く入っていくのはとても楽しい活動だよね。でも、実際の世界では、上司が「いつこれを納品するの？」って聞いてくることが多い。俺は一度だけ、仕事で「やってるよ、終わったら終わるし、すごくクールになるよ」って言える特権を持ったことがある。計画やタスクの分解は、開発者にとっては保険みたいなもんだ。なぜなら、上司（直接のマネージャーまで）が「どれくらい進んでる？」って聞いてきたときに、「合意した計画に従って、N個のうちk（< N）個を終えたよ。ただ、この(k+1)番目のことでは、計画中にあのことが見つからなかったから、スコープクリープや外部依存、道の真ん中に牛がいる問題で詰まってる」って言えるから。そうなると、ある種の人は他の同僚に責任を押し付けて、自分を良く見せようとして昇進のチャンスを狙うんだ。みんなに「計画の演劇」に参加して、自分の「役割」を果たすことを強く勧めるよ。あるいは、可能なら自分のやりたいように何かを始めてみて。

「... 実際にコードを書き始めるまで数週間かかる... こういう仕事をしている人がいるのが気になる。実際に見たことがないから。」

これを言うタイミングだと思うけど、「How Big Things Get Done」って本、Bent Flyvbjerg著。 「長期計画 vs. プロトタイピング開始」は偽の二項対立だよ。プロトタイピングは計画そのもの。言い換えれば、何週間もチケットを洗練するのが問題じゃない。問題は、プロトタイピングなしでこれをやると、実際にはチケットを洗練していない可能性が高いってこと。計画は、元に戻せないステップを踏むと止まるし、そのステップをできるだけ遅らせることには価値がある。そうすれば、プロジェクトが外部リスクにさらされることになるから。長期計画はこれが理由で価値があるんだ。ただ、長期計画を支持する人たちの中には、ただ時間をかけて計画に使わない人も多いけどね。

「データや関数、型をそのドメインに特化しすぎて名前付けや構造をしちゃうことがある。」昔、"Harry"にメールを送る必要があるPerlスクリプトを作ったことがあるんだ。（無実の人を守るために名前は変えてるよ）。Harryのメールアドレスを"$HARRY"という変数に保存したんだ。後で別の人（違う名前の）もメールを受け取りたいと言ってきた。問題ない、スカラーを配列に変えればいいだけ、"@HARRIES"に。自分ではすごく面白いと思ったけど、他の人はそう思わなかったみたい。