「Quantity Always Trumps Quality」の編集履歴(バックアップ)一覧はこちら

Quantity Always Trumps Quality」(2008/08/09 (土) 06:05:09) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

*Quantity Always Trumps Quality - 「量」はいつだって「質」に勝る #center(){ |開始日|2008年08月09日| |翻訳完了日|2008年08月09日| |最終更新日(ちょこちょこ直したり)|&date(j)| } *はじめに 有名なブログ[[Radium Software>http://d.hatena.ne.jp/KZR]]の記事で、「[[質より量に学ぶ>http://d.hatena.ne.jp/KZR/20080808/p1]]」というのがありました。リンク先を読んでもらえれば分かるのですが、ともかく今のボクにはハッとさせられる内容でした。 さて、その中に同記事の元ネタへのリンクが張られていました。 >[[Coding Horror - Quantity Always Trumps Quality>http://www.codinghorror.com/blog/archives/001160.html]] 自戒がてら、この記事を翻訳してみようと思います。 **原著 #center(){ 「Quantity Always Trumps Quality」 http://www.codinghorror.com/blog/archives/001160.html } **注意 -もともと個人利用を目的として日本語化したために、けっこう意訳している部分があります。「意味分からないよ」とか「おかしいんじゃない?」とかいうのがあれば、コメントで指摘してもらえると嬉しいです(がんばって調べます)。 **更新履歴 -2008/08/09 作成開始&作成完了。考えたけれど、「量」というよりは「経験」と捉えた方がしっくり来るね。 ---- *訳文 August 02, 2008 **Quantity Always Trumps Quality **「量」はいつだって「質」に勝る [[Nathan Bowers>http://nathanbowers.com/]] pointed me to this [[five year old Cool Tools entry>http://www.kk.org/cooltools/archives/000216.php]] on the book [[Art & Fear>http://www.amazon.com/dp/0961454733/?tag=codinghorror-20]]. [[Nathan Bowers>http://nathanbowers.com/]]はボクにこの[[5年も昔に書かれたCool Toolsのエントリ>http://www.kk.org/cooltools/archives/000216.php]]を紹介してくれたんだ。[[Art & Fear>http://www.amazon.com/dp/0961454733/?tag=codinghorror-20]]という本についての記事さ。 Although I am not at all ready to call software development "art" -- perhaps "craft" would be more appropriate, or "engineering" if you're feeling generous -- the parallels between some of the advice offered here and my experience writing software are profound. ソフトウェア開発が「芸術」だなんてとても思えないけれど(多分「工芸」がより近いんじゃないかな。もしくは「エンジニアリング」とかならどうだい?)、いくつかの含蓄はボクのソフトウェア開発で得た経験を言い得ているんだよ。 The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay. 陶芸の授業が始まると、教師はクラスを2つのグループに分けました。そして、工房の左側の生徒は 作品を作成した「量」によってのみ評価し、右側の生徒は作品の「質」で評価すると伝えたのです。 教師のやり方はいたってシンプルでした。 「量」グループの作品は、クラスの最終日にバスルームで重さを測り、50ポンドはA評価で40ポンド はB評価、と評価する。「質」グループは唯一の、ただし最高の1個を作れば良く、その質で採点する。 ところが、実際に評価の段階になると興味深い事実が浮かび上がりました。:もっとも高い質を持つ 作品はすべて「量」グループによって作られたものだったのです。どうやら「量」グループは幾つもの 作品をこねくりまわしているうちに間違いから色々学んでいたようで、一方「質」グループはその間 完全性の理屈をこねくりまわし、けっきょく頭でっかちの理論と死んだ粘土の固まりしか生み出せな かったのです。 Where have I heard this before? どこかで聞いたことのある話だよね? -[[Stop theorizing.>http://www.codinghorror.com/blog/archives/000165.html]] -[[Write lots of software.>http://www.codinghorror.com/blog/archives/000684.html]] -[[Learn from your mistakes.>http://www.codinghorror.com/blog/archives/000300.html]] -[[考えすぎるな>http://www.codinghorror.com/blog/archives/000165.html]] -[[とにかく沢山プログラムを書こう>http://www.codinghorror.com/blog/archives/000684.html]] -[[間違いから学ぶものさ>http://www.codinghorror.com/blog/archives/000300.html]] Quantity always trumps quality. That's why the one bit of advice I always give aspiring bloggers is to pick a schedule and stick with it. It's the only advice that matters, because until you've mentally committed to doing it over and over, you will not improve. You can't. 「量」はいつだって「質」に勝るものさ。ボクは計画することと続けることをどん欲なブロガー達にいつもアドバイスとし続けているのはそういうわけなんだ。頭の中で考えているだけなら、いつまでたっても成長しない。成長できないってことさ。 When it comes to software, the same rule applies. If you aren't building, you aren't learning. Rather than agonizing over whether you're building the right thing, just build it. And if that one doesn't work, keep building until you get one that does. ソフトウェアについても同じルールが当てはまる。作らなければ、学べないんだよ。正しいものを作ろうと悩み続けるくらいなら、やってみればいいじゃないか(Just build it)。もしうまくできなかったとしても、出来るまで作り続ければいい。 Posted by Jeff Atwood ---- (&counter(total)) #comment
*Quantity Always Trumps Quality - 「量」はいつだって「質」に勝る #center(){ |開始日|2008年08月09日| |翻訳完了日|2008年08月09日| |最終更新日(ちょこちょこ直したり)|&date(j)| } *はじめに 有名なブログ[[Radium Software>http://d.hatena.ne.jp/KZR]]の記事で、「[[質より量に学ぶ>http://d.hatena.ne.jp/KZR/20080808/p1]]」というのがありました。リンク先を読んでもらえれば分かるのですが、ともかく今のボクにはハッとさせられる内容でした。 さて、その中に同記事の元ネタへのリンクが張られていました。 >[[Coding Horror - Quantity Always Trumps Quality>http://www.codinghorror.com/blog/archives/001160.html]] 自戒がてら、この記事を翻訳してみようと思います。 **原著 #center(){ 「Quantity Always Trumps Quality」 http://www.codinghorror.com/blog/archives/001160.html } **注意 -もともと個人利用を目的として日本語化したために、けっこう意訳している部分があります。「意味分からないよ」とか「おかしいんじゃない?」とかいうのがあれば、コメントで指摘してもらえると嬉しいです(がんばって調べます)。 **更新履歴 -2008/08/09 作成開始&作成完了。考えたけれど、「量」というよりは「経験」と捉えた方がしっくり来るね。 ---- *訳文 August 02, 2008 **Quantity Always Trumps Quality **「量」はいつだって「質」に勝る [[Nathan Bowers>http://nathanbowers.com/]] pointed me to this [[five year old Cool Tools entry>http://www.kk.org/cooltools/archives/000216.php]] on the book [[Art & Fear>http://www.amazon.com/dp/0961454733/?tag=codinghorror-20]]. [[Nathan Bowers>http://nathanbowers.com/]]はボクにこの[[5年も昔に書かれたCool Toolsのエントリ>http://www.kk.org/cooltools/archives/000216.php]]を紹介してくれたんだ。[[Art & Fear>http://www.amazon.com/dp/0961454733/?tag=codinghorror-20]]という本についての記事さ。 Although I am not at all ready to call software development "art" -- perhaps "craft" would be more appropriate, or "engineering" if you're feeling generous -- the parallels between some of the advice offered here and my experience writing software are profound. ソフトウェア開発が「芸術」だなんてとても思えないけれど(多分「工芸」がより近いんじゃないかな。もしくは「エンジニアリング」とかならどうだい?)、いくつかの含蓄はボクのソフトウェア開発で得た経験を言い得ているんだよ。 The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay. 陶芸の授業が始まると、教師はクラスを2つのグループに分けました。そして、工房の左側の生徒は 作品を作成した「量」によってのみ評価し、右側の生徒は作品の「質」で評価すると伝えたのです。 教師のやり方はいたってシンプルでした。 「量」グループの作品は、クラスの最終日にバスルームで重さを測り、50ポンドはA評価で40ポンド はB評価、と評価する。「質」グループは唯一の、ただし最高の1個を作れば良く、その質で採点する。 ところが、実際に評価の段階になると興味深い事実が浮かび上がりました。:もっとも高い質を持つ 作品はすべて「量」グループによって作られたものだったのです。どうやら「量」グループは幾つもの 作品をこねくりまわしているうちに間違いから色々学んでいたようで、一方「質」グループはその間 完全性の理屈をこねくりまわし、けっきょく頭でっかちの理論と死んだ粘土の固まりしか生み出せな かったのです。 Where have I heard this before? どこかで聞いたことのある話だよね? -[[Stop theorizing.>http://www.codinghorror.com/blog/archives/000165.html]] -[[Write lots of software.>http://www.codinghorror.com/blog/archives/000684.html]] -[[Learn from your mistakes.>http://www.codinghorror.com/blog/archives/000300.html]] -[[考えすぎるな>http://www.codinghorror.com/blog/archives/000165.html]] -[[とにかく沢山プログラムを書こう>http://www.codinghorror.com/blog/archives/000684.html]] -[[間違いから学ぶものさ>http://www.codinghorror.com/blog/archives/000300.html]] Quantity always trumps quality. That's why the one bit of advice I always give aspiring bloggers is to pick a schedule and stick with it. It's the only advice that matters, because until you've mentally committed to doing it over and over, you will not improve. You can't. 「量」はいつだって「質」に勝るものさ。ボクは計画することと続けることをどん欲なブロガー達にいつもアドバイスとし続けているのはそういうわけなんだ。頭の中で考えているだけなら、いつまでたっても成長しない。成長できないってことさ。 When it comes to software, the same rule applies. If you aren't building, you aren't learning. Rather than agonizing over whether you're building the right thing, just build it. And if that one doesn't work, keep building until you get one that does. ソフトウェアについても同じルールが当てはまる。作らなければ、学べないんだよ。正しいものを作ろうと悩み続けるくらいなら、やってみればいいじゃないか(Just build it)。もしうまくできなかったとしても、出来るまで作り続ければいい。 Posted by Jeff Atwood ---- (&counter(total)) #comment

表示オプション

横に並べて表示:
変化行の前後のみ表示:
記事メニュー
目安箱バナー