「社内FizzBuzzコンテスト」
http://d.hatena.ne.jp/JunichiIto/20111007/1317976730
興味深かったのでメモ.
関連:http://d.hatena.ne.jp/JavaBlack/20111009/p3
- 終了宣言をしていない3人は本当に完成していなかった。(!!)
- うち二人はほとんどロジックらしいロジックが書けていなかった。
- 確かに3人ともPerlを業務でバリバリ使っている人ではなかったが、インターネット検索も許可している条件でこの結果はどうしたものか・・・。
「慣れない言語のせい」というのでないとちょっと怖い.
- 業務経験年数は全員5年以上。
....それは大丈夫なのか?
- 当日は欠席者が3人いた。(できたら全員参加してほしかった)
まさかとは思うけど,敵前逃亡じゃないよね?
なんか妙にトリッキーだったり、明らかに不要なコードをあえて残しているようなロジックがあった。
うっかりミスならしょうが無いけど,もし本当にFizzBuzzくらいでトリッキーになるとしたら,本当に難しいコードをかかせたらスパゲッティになりそうな気もする.
- 引数のバリデーション(フォーマットチェックや範囲チェック、引数の個数チェック等)を実装している人はほとんどいなかった。
- テスト駆動開発で開発する人も皆無だった。
これは問題の性質によると思う.FizzBuzz問題の要求仕様に引数チェックは含まれてない上に,今回のは一応はタイムトライアルでもあるから引数チェックを入れる必要は無い.またテスト駆動も,書き捨て型開発では必要性は少ない.
全員の動作確認とプログラム解説が終わった後に、各自がベストプログラマ3人を投票しました。
それからドキドキの開票となったわけですが・・・結果はほとんど全員が同じメンバーを1位、2位、3位に選んでいました。
2位と3位は多少バラつきましたが、1位はほぼ全員が同じメンバーに投票していました。
誰が書いたコードか,また誰が誰に投票したか分からないような形にしないと,「あの先輩/上司に投票しないと後が怖い」みたいな理由で集中する可能性も.その辺の対応は大丈夫だったのかな?
そして、同僚の中に「速い人ほどスキルが高い」と思う人がいれば、速い人に投票するでしょうし、速さ以外の工夫を評価する人がいれば、遅い人にも投票するわけです。
3ヶ月と1ヶ月なら早い方が良いけど,しょせんFizzBuzzだし10分と30分なら早さは必ずしも重要ではないと思う.100m走ならスタートダッシュのコンマ一秒の差が重要かもしれないけど,マラソンにおいてはスタートダッシュの1秒の差は重要ではない.
http://b.hatena.ne.jp/entry?mode=more&url=http%3A%2F%2Fd.hatena.ne.jp%2FJunichiIto%2F20111007%2F1317976730
- id:gomis この問題おすすめ→http://projecteuler.net/problem=1 /何人かにやってもらって三分程度で書き上げる人もいたが、アルゴリズムを改良しようとする人は皆無だった
- id:tail_y FizzBuzz問題を、書けない人は何故だったのか、というのが超重要だと思うのだけど、それについて言及が殆ど無いのが気になる。Perlを題材にしちゃうと、アルゴリズムとかではない部分じゃないかと思うのだけども。
書けない人は本質的に書けない.生まれついての遺伝子の差なのか,後天的な刺激の差かは不明だけれど,とにかく書けないらしい.
一般論として考察は重要ではあるけれど,答のない問題に対する考察は時間の無駄.
- id:Crimson_Apple 初めて書いたとき15で割ってしまって後からうああああ!ってなった記憶があるな…。
...f(^^; *1
- id:unaken 成績を仕事のポジションや給与に反映させる事なく、あくまで能力を高める自主的な場である事を強調して欲しい。利害関係の無い社外の人間も交えて、自主的に出てくる人間だけで軽い雰囲気でやった方がいいと思う。
それをやるとFizzBuzzができないような人は出てこないと思うな.今回欠席した3人の中にも,そういう人がいたかもしれない.*2
- id:gong023 FizzBuzz面接でやったのはいいおもひで