ハクソク

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

Dev Compass – プログラミング哲学クイズ

282日前原文(treeform.github.io)

概要

Dev Compass は、プログラミングにおける 自分の思想や傾向 を可視化するツール。 抽象的・具体的スタイル と 人間・コンピュータ重視 の2軸で評価。 20問の質問に答えることで 自分の位置を確認 できる。 プログラミング哲学 の理解や他者との比較に役立つ。 再度クイズを受けて 傾向の変化 も確認可能。

Dev Compassとは

  • プログラミング思想 を2つの軸でマッピングするツール
    • Abstract Style ↔ Concrete Style （抽象的スタイルと具体的スタイルの間）
    • Easy for Humans ↕ Easy for Computers （人間に優しい・コンピュータに優しいの間）
  • 20問の質問 に回答する形式
  • 自分の傾向 を視覚的に把握できるコンパス表示
  • 再度クイズ を受けて変化や成長を確認可能
  • チーム内や他開発者 との比較・議論にも活用

使い方

  • クイズ形式 で順番に質問に回答
  • 全20問 終了後に自分のコンパスが表示
  • Abstract ↔ Concrete のどちら寄りかが分かる
  • Human ↔ Computer Friendly のどちら重視かも可視化
  • Take Quiz Again で何度でも再挑戦可能

活用シーン

  • 自己分析 や キャリア設計 の参考
  • チームビルディング や 開発方針の共有
  • 技術イベント や ワークショップ でのアイスブレイク
  • 他者の考え方 を理解するためのコミュニケーションツール

注意点

  • あくまで 傾向の可視化 であり、絶対的な評価ではない
  • 質問内容や解釈 によって結果が変動する場合あり
  • 自己理解の一助 として活用推奨

Hackerたちの意見

真ん中に着地した -1, -2。なんか変だよね、こういうことには結構意見があるのに。質問のいくつかは好きだけど、答えを選ぶときはなんか適当に選んでる感じがした。それが多分理由かな。例えば、テストのために「バグを最も効果的に見つける方法」か「プロパティベースのテスト」か、どっちがいいかって？プロパティベースのテストは、通常バグを見つけるのに最も時間効率がいいから、両方とも正解だね。デバッグについては、プリント文を使うか、デバッガーを使うか、論理的に考えるか？全部使うよ。でも、もし選択肢のテストで「デバッガーを使う」って適当に答えたら、私のコーディングスタイルについてあまり教えてくれないと思う！ちょっと物議を醸すかもしれないけど、いくつかの答えは悪いプラクティスを名付けてると思う。例えば、最初に抽象化するのは悪いアイデアだよ。プログラミングを始める前は問題について一番知らないからね。最初に抽象化すると、入ってきた時の悪い仮定がコードに組み込まれちゃう。何かをコーディングして、その過程で学んだことを使ってソフトウェアアーキテクチャの決定を繰り返す方がいいよ。あと、最近のオブジェクト指向はあんまり好きじゃないし、今は動的型より静的型の方が好きだな。でも、面白い質問だね！まとめてくれてありがとう。

└

同じだね。真ん中に着地したけど、強いバイアスがある気がするし、デザインやスタイルの選択で同僚とあまり合わないことが多い。

└

誰が言ったか忘れたけど、「プログラムを6回書くまで、本当に理解していない。」

└

+1 抽象で 0 中立。命令型とオブジェクト指向が同じだと思ったから、ちょっと変だなって思った。

└

同じく。真ん中あたりだけど、これで特に厳しい質問はなかったな。例えば、ユーザーアプリケーションはユニットテストの恩恵を受けないと信じてるし、手動テストの方が早くて質も良いと思ってる。似たような感じで、ほとんどの状況ではPythonのオプショナル型システムは時間と精神的負担の無駄だと思う。バグを見つけるためのものじゃないし、スコープがしっかりしたライブラリコードにはどちらも適してるけど、アプリケーションコードは大抵あまり明確じゃないから、あまり恩恵を受けられないんだ。でもこのクイズはそのことを聞いてないし、これがスコアに大きく影響すると思う。

└

そうなんだ。でも、その後さらに4回受けたよ。どの方向でも最大化しようとして、いつも中心右寄りの的の中にいた。一度だけ、もっとコンピュータ寄りになったけど、中心の20%の半径からは出られなかった。もしかしたら、私たちが極端じゃないのは、気にかけてるからなのかな？それがいいと思う。

このクイズを終わらせようとしたけど、無理だった。どの質問も「文脈による…」って感じで大きな疑問があった。「強い静的型、動的型、またはそのミックス、どれが好き？」って… 9年生にコーディングの入門を教えてるのか、特注のデータ質問に答えるためのスクリプトを書いてるのか、データ処理ライブラリを作ってるのか、どれなの？「アルゴリズムについては…」って、パフォーマンスが気になるの？どこで動かすの？どのくらいの頻度で動かすの？コードはすぐに廃棄されるのか、それとも10年生きるのか？今日必要なのか、来週必要なのか？文脈なしでこれらの質問について意見を形成するのがどう始めればいいのか全然わからない。コンパスの例えを使うと、コンパスの使い方を一番よく知りたいと思わない？「私の好きな方角は東北東です」って言うことにどんな価値があるの？つまり、これらの本質は「文脈による…」って部分なんだ。クイズへの答えは、実際には人々が問題を解決している文脈の種類の代理に過ぎないよ。

└

同じ問題を抱えてる。多くの質問に対して私の答えは「全部、でもAの文脈ではA、Bの文脈ではB」って感じ。多くは相互排他的でもないし。例えば、「デバッグするとき、私は通常:」 > 問題を特定するためにテストを書く 数学関数やもっと原始的なビルディングブロックの場合、テストを書くことで基盤となる関数の正確性を確保できるから、問題の検索から除外できる。 > コードについて論理的に考える これはいつも役に立つ。 > デバッガーを使ってコードを体系的にステップ実行する 大きなコードベースを扱うときや、制御フローが追いにくいときに便利。コールスタックは、手動で制御フローを解読するよりも早くガイダンスを提供してくれる。 > データフローを理解するためにプリント文を追加する: 連続データストリームやイベントをデバッグするときに便利。例えば、マウス入力など、デバッグが必要なユーザーインタラクションを中断したくないときに役立つ。

└

「自分が好きなツールを使って、好きなことに取り組む時のことだと思った。」例えば、静的型付けと動的型付けのミックスが好きなんだ。パフォーマンス最適化のために、技術的には4つの選択肢すべてを使うけど、可能な限り最初からパフォーマンスの良いコードを書くのが好み。これは、仕事に対して正しいツールを選ぶというより、選択肢がある時にどんなツールを使いたいかってことだね。

└

デフォルトで選ぶものを選んでね。複数の選択肢がある場合は、最初に試してみたい選択肢を選んで。これはDSAテストじゃなくて、直感テストみたいなもんだよ。

└

だから、選択肢問題が大嫌いなんだ（試験でも絶対使わない）。

└

性格テストにはそうなんだけど、今回はちゃんとやったよ: 抽象 ↔ 具体: -13 具体的な人間 ↔ コンピュータに優しい: +7 人間に優しい

└

「文脈による」というのは性格の特徴だね。

└

「それ次第」っていう感覚は、実は経験豊富なエンジニアの証なんだよね。文脈を理解することが、教条的なプログラミングと効果的な問題解決を分けるポイントなんだ。

└

文脈によって変わるからって質問を避けるのは、他の人に対して慎重で配慮があるって信号を送る貴重な方法かもしれないし、それには確かに価値があるよね。でも、こういうクイズは文脈なしで設計されてるから、直感で答えるのが求められてる。ランダムウォークの最初のステップだね。実際に文脈に大きく依存してて、どちらの選択肢にも強い好みがない人は、すぐに答えて、興味のあるすべての次元で中心に近くなるはず。私もそうだったよ：""" あなたはコードの明確さと直接性を重視します。理解しやすくデバッグしやすい、明示的でステップバイステップの解決策を好みます。たとえそれが多くの行数を必要とする場合でも。抽象的 ↔ 具体的: -2 具体的 人間 ↔ コンピュータフレンドリー: +5 人間に優しい """

└

いくつかの質問について、その感覚があったよ。特に目立ったのは、""" デバッグするとき、私は通常： * 問題を特定するためにテストを書く * まず論理的にコードを考える * データフローを理解するためにプリント文を追加する * コードを体系的にステップ実行するためにデバッガを使う """ で、私は通常その4つ全部やるんだ。データフローがまだ理解できていない場合は、プリント文かデバッガから始めて理解するようにしてる。すでにデータフローが分かっていて、コードを論理的に考えられるなら、そのまま進めるし。そうでなければ、まずテストを書いてコードを考える手助けをするかも。でも、一般的にはこれら全部やるし、順番は具体的な問題によるかな。

あなたは、他の開発者にとって直感的でアクセスしやすい、エレガントで高レベルな解決策を好むんだね。おそらく関数型プログラミングや、明確な抽象化、文章のように読みやすいコードを好むんじゃないかな。抽象 ↔ 具体: +7 抽象 人間 ↔ コンピュータフレンドリー: +11 人間フレンドリーって感じだね。コードは最高のドキュメントだよ、特注の数学アルゴリズムを書いてるとき以外は。たとえそうでも、明確な変数名や関数名を書くことでそれを補おうとするよ。

このクイズは、順位選択投票を支持する理由を再確認させてくれるね。

└

あなたの好みに応じて結果が悪化するアルゴリズムを使った場合と、そうでない場合、どちらがいい？

これが可能性のあるプログラミング哲学の説明みたいだね（main.jsでキーワード検索して見つけた）。抽象的/人間に優しい: 「あなたは、他の開発者にとって直感的でアクセスしやすい、優雅で高レベルなソリューションを好みます。おそらく関数型プログラミングや明確な抽象化、散文のように読みやすいコードを好むでしょう。」抽象的/コンピュータに優しい: 「あなたは数学的な優雅さと最適なソリューションを評価します。おそらく強力な型システムや形式的手法を持つ言語、コンパイラの最適化を活用したコードを楽しむでしょう。」具体的/人間に優しい: 「あなたはコードの明確さと直接性を重視します。理解しやすくデバッグしやすい、明示的で段階的なソリューションを好みますが、たとえそれが多くの行数を必要としても。」具体的/コンピュータに優しい: 「あなたは効率とパフォーマンスに焦点を当てます。ハードウェアに近いところで作業し、スピードとメモリ使用量を最適化し、システムリソースを直接制御することを好みます。」この文字列もソースコードに存在するけど、表示をトリガーするのは難しいみたい: 「あなたはプログラミングに対してバランスの取れたアプローチを持ち、各状況の特定の要件に基づいてスタイルを適応させます。」

このテストは多くの受験者に中央の値を与えると思う。なぜなら、質問の内部的一貫性が確認されていないから。誰でも10問作って「これがプログラマーの抽象化への好みを測る」と主張できるけど、残念ながらその主張を確認することはできない。できるのは、10問の回答が強く相関しているかどうかを統計的にチェックすることだけ。これは、クイズの試行と、Cronbachのアルファや主成分分析などの統計が必要だ。しばしば、質問が全く同じものを測っていないことがわかる！内部的一貫性のある質問を作るのは難しい。ここで不一致な質問を足し合わせると（最終スコアを得るためにここでやっていること）、強い信号は得られない。相関のない質問からのノイズが打ち消し合って、ほとんどの人がゼロに近い結果になる。OPは著者じゃないことは知ってるけど、もし著者がこれを読んでいたら: 幸運なら、このオーディエンスからのデータが、各次元ごとに内部的一貫性のある2、3の質問のサブセットを明らかにするかもしれない。次回のクイズではそれだけを使って！その後、他の質問を一つずつ試して、最初のセットと一貫性のあるものだけを残せばいいんだ。（これはp-hackingじゃないの？うん、でもこの文脈では誰も気にしないよね。）

└

このテストは、多くの受験者に中央の値を与えると思う。なぜなら、質問の内部的一貫性が確認されていないから。あなたはどれを使うのが好き？ 1. 大文字 2. 小文字 3. 数字 4. 正確で読みやすいテキストに必要な文字

└

グラフも壊れてるみたいで、私が得たのは+2の抽象的、+10の人間に優しいって感じだったけど、プロットすると+10は軸の近くに現れた。グラフは、生のスコアよりも標準偏差や他の指標を半径としてプロットした方が良さそうだね。

うん、アイデアはいいと思うけど、質問はもっと練り直す必要があるね。いくつかやってみたけど、あまりにも曖昧だったり、複数の選択肢に「はい」って言いたくなるのが多かったから、途中で諦めちゃった。例えば、コメントに関する質問は、基本的に全部正しいし。アーキテクチャに関する質問も、答えるのがほぼ不可能だよね。

ソフトウェアエンジニアリングは、ホグワーツやダイバージェントみたいに、こういうラインで派閥に分かれた方がずっと良くなると思う。確かに著者のテストはちょっと不完全だけど、アイデアは正しいよね。多くの「ベストプラクティス」は本当に嫌なもので、XMLとかマイクロサービス、TDD、デザインパターン、DRY、OOP、関数型プログラミング、行動規範、そして「デブオプス」の75%なんかもそう。私たちの多くはその時、これらのことが嫌だと感じていて、反対派として非難されたりもした。でも今振り返ると、みんな考えが変わってきてる。私たちは機械にこだわりがあって、短い変数名を好み、必要なテストを書いて、printfデバッグをする。正しくてエレガントなものを作りたいだけなんだ。ほっといてほしい。どんなトレンドも、業界全体に当てはまるほど良いものではないと思う。派閥に分かれた方が、自分の好みに合ったコミュニティを見つけやすいよ。私はこういう風に生まれただけなんだ。

└

多くの「ベストプラクティス」は本当に嫌なもので、... あなたが挙げた多くのことに対して、私も愛憎入り混じった関係を持っていて、今はあなたの好みの多くを共有しているよ。でも、昔はそうは思ってなかった。ベストプラクティスは、その時の問題に対処するための非公式なアプローチとして始まるんだ。ある程度の成功を収めると、他の人によって言語や機能、文化的なアーティファクトとして神聖視され、新たな問題を生み出すことになる。私は、無思考の「ベストプラクティス化」の広がりが、特定の「ベストプラクティス」よりも厄介だと思う。OOPを例にとってみよう。ストラウストラップの初期のC++プレゼンテーションでは、OOPは「遅いグラフィックス」以上の意味があると主張していた。当時、人々はあまりメモリのない機械のためにグラフィカルユーザーインターフェースを作るのに苦労していたからね。状態と振る舞いを融合させるアイデアは、その時、命令型言語で複雑なユーザーインターフェースを構築するのを容易にした。でもOOPは万能薬じゃない。OOPのアイデアを他の領域に適用しようとした多くの試みは失敗に終わった。幸いなことに、今はもっと強力なマシンと良いツールが手に入るようになった。

もし選択肢を個別にランク付けできたらいいな。単に一つだけ選ぶのじゃなくて、ランク付けスタイルで。スコアを計算するのはできると思うし、クイズを受ける人のフラストレーションも減ると思う。例えばデバッグの質問についてだけど、私はそれらの方法をある程度使ってる。でも「コードについて論理的に考える」って選択肢をほぼ100%の確率で選ぶから、あまり自分を表してるとは思わなかったけど、それを選ばざるを得なかった。

これは楽しかった！エンジニアリングのMBTIみたいな感じ。私は +3 抽象的、+2 人間に優しい - https://pastebin.com/Y7t4ys3J 最後に、各回答が最終スコアにどのように貢献したかを見たかったな。最終グラフにプロットされてたら面白かったと思う。他にどれくらいの人がテストを受けたのか、私の回答が彼らとどう比較されるのかも興味ある。