Notices by ひだお初段@Qiitadon (hidao@qiitadon.com), page 53

今日は早く仕事上がって、体力も残っているので#孫子bot の仕込みをする

ちかごろマスターばななのトゥートが深みを増して、ばなな感が薄味になっている。いい意味で。

転職とか小難しいこと色々考えると、よくわからなくなりますねー
私は正直、生活できれば良いかなぐらいの思い
自分が生活を支える人たち（家族に限らず）に対しては責任を負いつつ

私はある程度一つの案件/コード母体に深く突っ込む感じじゃないとあんまり効率的ではないと思ったので、そういう仕事を志しました

開発のノウハウを、それこそ普通の意味に近い意味で「横展開」してきちんと他業種に活かせれば、それがSIerが存在する価値だと思うのですが、それも中々難しいというのが私の感想でした…自分が事業会社の社員になったら、コスト1/3とか1/4とかになるやん、と思うとすごくやるせなかったんですよね

野生動物の毛は基本防御シールドなので油で固めてゴワっている。犬猫は人がモフりやすいよう進化させたというか…

Android9はPen Pineapple Apple Penになると信じてたので、期待を大幅に裏切られた
Appleを串刺しにするという、強烈なライバル意識を表現するはずだったのに

おはヨードン。
キラキラトゥートに飽きたので、#孫子bot にでもなる。

「善なる者とは 、勝ち易きに勝つ者なり 。故に善なる者の戦うや 、奇勝無く 、智名無く 、勇功無し 。」
（意訳：有能な人は楽に勝てる時に勝つ。ので、有能な人が勝つときは変わったこともしないし、すごいアイデアもないし、勇気のいる決断もしない。）

既存コードへの編集権限が与えられていないので（運用ルール的に）、ブラックボックス部分はソースが見えてもチェックライトが入れられない。
テスティングフレームワークも存在しない開発環境なので、自由にデバッグできる人たちが羨ましい。

さっきの"コツ"はプログラミングはもちろんのこと設計にも効いて、かつ即効性がある
「この設計であればユーザーが見てもひっくり返されないと、なんらかのユーザー目線の根拠がある」
「仮にユーザーからの要望が出るとしても、可能性としては○○、××、△△などがあるので、○○にしてほしいと言われてもただちにそれを受けずに××や△△も聞く」
と思って設計するようにすると、よほど失敗しなければ大間違いはしないし、選択の幅が広がりながらも正しい方向に物事が進む
これはほんとに、結構な即効性がある…慣れないうちはやりきるまでに少し時間がかかるけど、漏れ的なミスが劇的に減る
漏れ的なミスを一度劇的に減らせるようになると、楽しいのでモチベーションになる
そういうのをやると、やっぱり仕事にも"技術"の部分が沢山あるんだなーと思う…普通の意味での技術ではないけど

さっきの１と２も、最初は全く違いが分からなくて、新人の頃から２の気持ちはあったけど、１の気持ちが全く理解できなかった
でも確かに、上司と呼ばれる人たちは自分よりもプログラム書けないけど仕事は早いなーと思って、よく観察してたら、やっぱり初手とかやり方が賢かった
一日にタイプできるキーの数とかは限りがあるので、その限りある打数の中で効率よく動くためにどうするかを考えたら、先のことを不安に思いながらも「えいや」で作業をするのではなくて、
・何らかの根拠を持って、ある程度の自信がある
・仮に間違える可能性があっても、その間違いに対してそれなりの仮説がある
という状態を維持しながら作業しないと、結果的に工数を削減できないと思った
私個人的には、それを実践しようと思ってから、仕事の作業が相当速くなったと思う…社会に出る前に気付いとけよ、という事かもしれないけど

サブタスクが泥沼化するとサブサブタスクやサブサブサブタスクとかいった概念が果てしなく発生するアレを何とか可視化したかったが可視化したところで誰も見ないのではという気もしてきたし、畢竟プロジェクト管理者の仕事というのはタスクワーカーに目の前だけ見てればいい状態を提供することではないかとも思い始めた

コンウェイの法則の陽の部分「システムはコミュニケーションのパターンに基づいて作られる」の陰の部分「コミュニケーションが不足している部分のシステムが不足する」の威力って結構ばかにならない。

この件だけではないんだけど、色々細かく技術的に問題になった事象を紐解くと、だいたい全部が「そこで手を抜いとるからやん」てなる
みんな、冷静なときに目の前に他人事として出されたら「そんな馬鹿なことするわけあるか」と思うんだけど、上司や顧客との交渉とか、部下との調整とか、色々人間関係的な問題が絡んでくることによって、一気に間違うためのハードル（？）が激下がりする
私はしばらく、そういうのって技術力の問題だと思ってて、まあ一部には確かに技術力の問題もあるんだけど、本質は人間の問題だった

かなしくなった

テストしてはいけない金融案件は、テストでどれぐらいエラーが出るかを量りたいというメトリクス的な思想もあるようですね
実際、コード量とかを算出して提出する必要があるプロジェクトも結構あったので
それでバグの量が範囲を超えていると、それに対する反省文みたいなものを書かないといけない
品質が良すぎるものを作ってもダメで、それはテスト不十分ともみなされたりする…ので、細かいバグを頑張ってみつけたりする

@shimisunet ?

ある言語を使える環境を整えたら、テスト環境も一緒についてくる
というのがこれからの標準になってほしいなと、ふと思った

テストの意義を理解していないプログラミング初心者には、テストフレームワークを選定して導入するというのは心理的に大きな障壁になるし、テスト自体を怖いものと思ってしまったり、チュートリアルのテストの章を読み飛ばしてしまったりするかもしれない

最初からテスト環境が整備されてさえいれば、繰り返し処理や関数を学ぶのと同じように、すぐにでも試してみることができる
これならテスト嫌いに陥る初心者も減ってくれるはず

白身魚フライ featuring ゴーヤタルタル、提案はしたものの実際会うかどうかの感想が気になる。

世界が平和になったといことは、うまかったのだろう。
ファボられたらそう思おう。そうしよう。