嫌われプログラミングの代弁者

「何で頭ごなしに嫌う人間が居るのか」を色々考える

因果推論による良い寿司成分の欠乏 1

どの様な話?

自分の責で、サーバーの動作をおかしくしてしまった場合、

  • 指摘の有った事象から因果推論をして、
  • 原因にたどり着き、
  • 修正範囲を確定して、
  • 過不足無く、誤り無く、とにかく素早く修正する

事を1分でも2分でも早くやり切る必要が出ます。

そうすると、(個人の感想ですが)脳の養分の一部が欠乏する様に思います。

その養分が欠乏すると、まっすぐ歩くのも困難になり、徒歩なのに自動車でも運転している様な風景になります。

そして、それは(たまたま気づいたのですが)良い寿司を食べると改善されるのです。(個人の感想です。多分ですが、その養分は欠乏する前に摂っても無意味だと思います。)

その様な措置をしないまま、安静だけで済まそうとすると、休職半年とかになるかも知れません。

 

だから〜?

プログラミングの初心者の方は、急速な因果推論なんて出来ないでしょうから、その様な欠乏に陥る事は無いとは思いますが、
きちんと勉強をしようとし続けた場合には、(慢性的な意味で)最終的になる可能性が有ると思います。

そうなれたとは、(結局の所)因果推論が上達した事を示すとは思いますが、そのせいで鬱だ云々になっては元も子も有りません。

 

カウンセリングは(致命的な)逆効果

(個人の感想ですが)その様な状態に陥った場合、カウンセリングは完全に逆効果です。

  • 傷口に塩を塗り込め、
  • フォークで傷の中をかき回す様な行為

だと思います。

兎に角、因果推論をする為の養分が欠乏しているのに、カウンセリングはさらに因果推論を強要するものだからです。

 

寿司代をケチると酷い

この話は言ってみればMP欠乏症に対する対処(薬食い)ですので、寿司代をケチると酷い事になります。

前に、50%セールとかをやっていて、とても高くて食べられない上寿司を5人前頼んだ所、

  • 紐の様なネタで、
  • 全般的に漂白剤の匂いと味しかしない
  • のが5人前

で、非常に後悔した事が有ります。20%の割引券でもかなりのご高齢の兄貴が来ました。

薬食いではケチるべきではありません。なお、再度申しますが、欠乏する前に摂っても、因果推論の能力は上がらないと思います。(個人の感想です)

良い寿司だと、

  • 食べ初めに、まず甘エビを食べてから、醤油を舐めても、食べてから1分位は醤油の味を感じない(醤油が変質してしまったのか?と思う)
  • 食べると薔薇の香りがするカニの軍艦

とかに当たる場合もあります。

 

結論

これからも「因果推論による良い寿司成分の欠乏」でプログラミングが絶望的に嫌いになる人は存在し続けることでしょう。

 

 

 

キーのみのER図を書いたら非難された 1

どの様な話?

こちらはちっとも悪く無いのに、非難された(酷い目に遭った)話です。

前に持っていたクロスバイク*1で、何を思ったか輪行で霞1の近辺に行った時の話ですが、

快走路が急に、

  • 田んぼを乾かした上に、
  • L字擁壁が左右に有り、その間に(多分)盛り土がされており、
  • アスファルト敷の道路(一方通行1車線)が数100m続く様に

なり、
タイミング悪く真横を車に占められ、L字擁壁の上の幅10センチの範囲よりも、道路の内側に行こうとすると、車の側面にぶつかる(普通自転車ギリギリの60cm幅の自転車だった)ので、延々数100mを幅10センチの一本橋行かないとならなくなりました。

「減速して車の左後方に付けばいいじゃないか?」と思うかも知れませんが、減速したら、確実によろけて転落し、L字擁壁の地面側コンクリートに激突していました*2

どうしても避けられない困難でした*3

 

プログラミングの話ですが、

  • 商品の属性を入れると金額が出るシステムで、
  • 10個以上のテーブルを特定の順番に検索する内容で

特にテストデータを作るのに、

  • 全体の「外部キー ー 主キー、代理キー」の連鎖(商品によって、連鎖の深さ、検索対象のテーブルが異なる)を毎回調べていて、
  • ER図だけれども、外部キーと主キー、代理キー以外、全部無視するER図が欲しかった
  • テストデータを作るのに必要なものは、まずそれ‼️‼️
  • テーブル毎の項目定義書は正式なものが別に有る

のに、「ER図は全ての項目を書かなければならず、そうで無いものは作ってはいけない」とか指示されて、
毎回調査となってしまった事が有りました。

最終的には、望みのER図を作れたのですが、そうで無い頃は、L字擁壁上の一本橋状態でした。周りの人間の特定手法の凝り固まりのせいで大変でした。

指示を出す人間、権限の有る人間は、右横の自動車と一緒でどうする事も出来ませんが、ソフトウェア開発にはそう言う事もある、と言う情報連携の巻でした。

 

結論

これからも「キーのみのER図を書いたら非難される」事でプログラミングが嫌いになる人は存在し続けることでしょう。

 

*1:Giant Escape R2でした。

*2:しかもその時点でスローパンクチャー状態でした。帰りの駅に着いた頃には9気圧有った空気が全部なくなっていました。
家に帰り、タライの水で調べた所、チューブの円周方向の繋ぎ目の一部(数十ミクロン程度と思われる)が外れて、そこから少しずつ空気が漏れていました。

*3:こんなだから、この辺はカタカナ4文字で呼ばれるのかも知れません。

まともな名前をつけさせてくれず、意味がわからない 4

対抗軸

やはり、

  • 分かりやすい、まともな名前

  • 調査分析、因果推論

と言うのは、対抗軸になると思います。分かりやすい名前が有れば、調査分析や因果推論は不要だ、と言う立場と、そうで無い立場、です。

 

そうで無い立場

昔、物凄く古い(高価な)RHELで出来た社内サーバ(メールサーバーとプロキシサーバー)をCentOS6 Minimal にしろと言う要求があり(内製と言う事になります)、

やったのですが、設定引き写しでは許してもらえず、色々やりました*1

CentOS6 Minimal はGUI は有りませんが、普通のメモリ8GBのパソコンの隅でVMを作って運用出来たので、色々出来ましたが、

結局、

  • 主な機能について、たまたま(確率)On/Off にした、は許されず、
  • 理屈(因果)が有って、それを(メモ書き程度にせよ)文書化しまくり、
  • 反事実もやることで、理屈(因果)を補強する
  • Linuxとはいえ、ソースを見ての理屈(因果)の補強まではしなかった。

でした。

 

反事実

実社会で反事実など適用したら、どんな悪影響が出るか分かりませんが、

Linuxなら、(明らかにOff 一択としか思えないのに)On と言う反事実にして、理屈(因果)を補強する事はアリです。
大抵は壊れますが、VMを作り直して仕舞いです。

調査分析とテストの違いはここに有ると思います。

テストは正しさが有り、それの検証ですが、調査分析は理屈(因果)の補強のためなら、反事実も厭いません。

 

「まともな名前」をなぜ嫌うのか?

その名前から想起される理屈(因果)と、実際の理屈(因果)が違っていて、大コケにコケる可能性が高いからです。

違っていない確率は、特に自明でないデータやプログラムの名前の場合で、顕著に低い、無いも同じだと思います。

 

一人前とは

一人前とは(一人前の仕事とは)、

  • 主な機能全てについて、たまたま(確率)を脱して、理屈(因果)を付け、
  • それを文書化する

だけだと思います。それだけで中堅技術者の一丁あがりです。
名付けに汲々とするのも見識かも知れませんが、別の対抗軸がある事も事実だと、思います。

 

結論

対抗軸で有る以上、永遠に対立は消えない訳で、
これからも「まともな名前をつけさせてくれず、意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

 

*1:なおqmailなど、自動でインストール出来るパッケージが無いものは、ソースからのコンパイルとなりましたが、CentOS6の時代でも、自動テスト(当てにしているOSの機能はちゃんと、当てにしている通りか? などをテスト)は完備されていて、 さすがはLinux だと思いました。
最近は(手抜きで?)パッケージのあるメールアプリを使う様になりましたが。。。

まともな名前をつけさせてくれず、意味がわからない 3

分かりやすい名前?

最近、割とよく、

  • 機械的な連番の名前は生産性が劣り、分かりやすい名前は生産性が向上する

とかの記事を見ます。

確かにCOBOLなんかだと、

  • ある日付:ABC001
  • ある日付の年、月、日:ABC0011、ABC0012、ABC0013

とかやっていました。半角英数8文字のABC001を4文字、2文字、2文字で切って使う、と言う趣向になります。

確かに、普通に聞いていれば「機械的な連番より、分かりやすい名前の方が生産性が向上しそうだな〜」と思うとは、私も思います。

 

昔のエピソード

昔、Delphi言語(Pascal言語の改良版で、オブジェクト指向っぽい文法も入っているが、インターフェースが無く、特定のインターフェースの実装を強制するとかは出来ない)での開発で、5人くらいのチームのお手伝いで1人加わった事が有りました。

私は、その言語のモジュールを受け取り、画面のIDを.incファイルに登録して、ビルドする役だったので、お手伝いでした。

普通に分担したモジュールを作っていたのですが、

 

ある時、リーダーの人に「お前の作ってるプログラムの名前が分からない」と言われ、「どうしたら良いでしょうか?」と尋ねても、
「察しろよ!」的な事しか言いませんでした。

その時はスーパーラッキーで、元請け側の人間だったので、上司に「訳が分からなくなりました。別の仕事に行かせて下さい」が効き、
平穏に立ち去る事が出来ましたが、そういう立場で無かった場合、非常に困った事になったと思います。

分かりやすい名前と言うのは、

  • 人を追い払うツールになり、
  • しかもその責任を追い払われた人に被せやすい

と言う性質が有ると(心の底から)思います。

 

絶対的真実

プログラミングは、

  • 一人か
  • 仲のいい相棒と二人

とかで作る方が絶対に生産性が良いです。これは三国四海どんな立場、人種、信条の人でも、特に異論は無いと思います。

分担して作るのは、間違い無く生産性が下がります。

 

とすると、

とすると、「機械的な連番より、分かりやすい名前の方が生産性が向上しそうだ」と、軽々に決めつけて良いのか、心配にならないでしょうか?
なりますよね?

分かりやすい名前は、

  • 人を追い払うツールになり、
  • しかもその責任を追い払われた人に被せやすい

ので、実質、

  • 一人か
  • 仲のいい相棒と二人

とかで作るのと同等になり、その体制は追い払われた人の責任であり、故に、生産性が良くなるとは考えられないでしょうか?

 

さらに、

さらに、名前を付けやすいプログラミングの部分とそうでない部分が必ず出来、書籍などで紹介する場合は、付けやすい部分のみ記述し、

追い出したい人間にそうで無い部分を割り当て、
名前を分かりやすく付ける能力が客観的に欠けるとして追い払う事も出来ます。

 

根本的には

根本的には、

  • 全てのプログラムの部分に、分かりやすい名前をつける事は原理的に可能なのか

誰も証明していない🔥のが大問題です。

それが証明されていないのに、それを強いるのは横暴で、少し立ち止まって考える必要もあると、思います。

 

結論

名前なんて、区別がつけば良く、もっと言うなら、いて座や水瓶座の様に領域を大まかに区切るだけでも良い様にも思うのですが、そうで無い人がいるのも事実です。

これからも「まともな名前をつけさせてくれず、意味がわからない」事でプログラミングが嫌いになる人は存在し続けることでしょう。