John Graham-Cumming / 青木靖 訳 2010年5月17日 プログラマであれば、何かの問題を同僚に説明していて、説明し終わる前や、何かフィードバックをもらえる前に自分で答えを見つけたという経験があるのではないかと思う。私は同僚さえ必要ないということに気づいた。話す相手は何でも良くて、ただ問題を口に出しさえすればよいのだ。 私が本を書いていたとき、解説しようとしている科学の話を自分でちゃんと理解しているか確認するため、声に出して説明してみることが良くあった。あまりばからしく感じないように猫を相手にそうしていた。猫は私の言うことを理解しないか、少なくとも言葉を返すことはなかったが、はっきり口に出して言うのはとても助けになった。 デバッグしているときコンピュータに話しかけることもある。問題をはっきり口に出すことで頭の中の歯車がかみ合って、自ずと答えが出てくるのだ。 Coders
1. 万人に受け入れられるゲームは理想だが存在しない ラピュタみたいな物 2. 正しいデザインは機能性と相反しない デザイナーを説得しろ 3. スケジュールは工数を当てはめるパズルではない 無理な物は無理だ 4. 言わずに後悔するより言って後悔しろ ああすればよかったのに…という後悔は無駄だ 5. リサイクルよりフルスクラッチ 他人が作った物を直すより最初から作った方が速い この点においてプログラマーを信じるな 6. プログラマー、プランナー、デザインの言う「可能」はそれぞれ意味が違う 時間があれば出来る、なんとなく出来ると思っている、気が向いたら完成する 7. 企画書は企画が通ったら捨てろ さて、俺の好きなゲームをゼロから構築するぜ! 8. よく出来ている は褒め言葉ではない どちらかと言うとdisの言葉だ 9. パクリを気にするな お前の作っている物も多分パクりだ 10. 理論的な説明
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く