ハクソク

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

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

2025年8月17日原文(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 人間に優しい

Hacker Newsで議論の続きを見る