この文は個人的美学です。人間性で誉められていない人間の遠吠えです。
はじめに(introduction)
プログラマとして、プログラムを書く時、文章を書く時、言い訳をする時に心がけていることを整理します。
一番は、誰か、具体的な特定の個人を思い描いて書くことです。
プログラマが心がけるとよい文章の書き方
<この項は書きかけです。順次追記します。>
背景(back ground)
Twitterで、弟子から師匠と呼ばれている人が、つまらない言い訳書いているのを拝見して思い立ったものです。
決して、すべてのプログラマに言い訳を言うなという趣旨ではありません。
仕様、制約条件の違いを公開することは、言い訳には分類していません。
1.プログラム
1.1 書いたものは保存する
shell のコマンドでなければ、書いたものは保存している。
shell のコマンドでもshellのhistoryは保存しておくとよい。
一度っきりのScriptで、なおかつセキュリティ上やばい内容で、流出すると大事になるようなものでも、自分しか見えない場所に、こそっと保存することがある。
電子的に保存しない方がよさそうであれば、印刷して金庫の中に入れておくこともある。
暗号化については、暗号化して復号できなくなっている暗号済みファイルの存在も危険。
いろいろ迷うことあり。
自分が積極的に書いたものだけでなく、コンパイルエラー、実行エラーなど副産物もなるべく記録する。
C++/C コンパイルエラーを記録するとよい理由7つ
初めての CEDD(Compile Error Driven Design) ８回直してコンパイル。
コンパイル用shell script C版(clangとgcc)とC++版(clang++とg++)
プログラマの「日報、週報、月報、年報」考
計算機と計算機網の使い方、使い方の覚え方、使い方がわからない時の検索の仕方、使い方がわからない時の報告の仕方
open な issue がどんどん溜まる現象を解決するために
1.2 機密（個人情報を含む）でない限り公開する
Review, 試験を依頼するにあたり、公開しておくと相手も作業がしやすい。
思い違いや、書き方のよくないところを指摘くださることもある。
docker hub とQiita
機密だと言われても、三社で同じことをしていれば、三社のうちのどこかに、他でも同じことをしているからと公的な投稿を共同でして公開してしまうという手を使ってきました。
1.3 自分用か、他人用か、プログラムを使う人、直す人を意識する
自分用であれば、ひとまず動くことを目指す。
他人用で、誰がこのプログラムを直すかで、関数名、変数名、定数名を決める。
実際にプログラムを変更してくれそうな人の顔と態度を思い浮かべながら書く。
明日自分が直す可能性があれば、明日の自分がわかるような注釈を書いておく。
英語文化圏の人にも使ってもらう場合は、英語の語源を調べる。
プログラマが知っているとよい英単語の語源
1.4 人のプログラムで気になった時は、書き足す・書き直す
人のプログラムで気になった時、原則、文章で意見を言わない。
動作させたエラーや、現象を記録したり、
自分ならこう書くという部分を書き足したり、
全部書き直したりする。
プログラマが欲しいのは、意見じゃなくて、プログラムかエラーの結果か、書き直し方の例。
VZエディタ移植(porting)に当たって実施したことと成果
2.文章
2.1 書いたものは保存する
夢の中で考えたことは、起きたらすぐに書き留めるようにしている。
すごいアイデアを朝はおぼえていて、昼に忘れることがある。
書いたものは保存する。
紙、ホワイトボードに書いたものは写真を取り、
電子化したものは予備はネットにあげる。
http://researchmap.jp
というサイトでは、ネットワークが不安定だったり、ログイン後時間が経過していると、
保存時に警告を出さずに、ネットの彼方に消えてしまう。
2.2 機密（個人情報を含む）でない限り公開する
文章の見直し(review)を依頼するにあたり、公開しておくと相手も作業がしやすい。
思い違いや、書き方のよくないところを指摘くださることもある。
wiki, git系のWikiなどに書くか、Qiitaに書くようにしよう。
Qiita記事 いいね と views の関係
今年のQiita記事の目標
楽しいQiitaの使い方 壁１０罠6つ技7つ
2.3 読んでくれる人の顔と態度を思い浮かべながら書く
Qiitaであれば、よくいいねを押してくださる方の態度を考えながら書く。
知り合いではなくても、いいねを押してくださった方の場合は、その方の
過去の記事を拝見したり、いいねの傾向を拝見し、
その人が興味を持ちそうな話題や、論理展開を書き足す。
2.4 人の文章で気になった時は、書き直す
プログラムは、部分的な書き直しをしても、試験をすれば違いが確認しやすい。
文章は、部分的な書き直しが効く場合と、書いた人の立場で、書き直しが理解できない場合がある。
原則は、別途書き直してみて、違いが明確になれば、気になった文章の書き手に連絡する。
相手が理解できそうな水準に達していない場合には、精進しながら書き直す。
なぜ少しづつQiitaの記事を追記しているか
2019年に入ってからのQiita記事の書き方
Qiita記事の最近の書き始め例
3.言い訳
3.1 師と呼ばれたら言い訳しない
原則、言い訳は言わない。
プログラムにしても文章にしても言い訳が欲しいのではなく、書き直したものが欲しい場合に、言い訳されるとむっとする。
弟子の１割は弟子になる前から自分よりも優秀だし、師匠だと思ってくれる人がいたら、言い訳をしたら、師匠であることを恥ずかしいと思わせてしまう。
プログラム、文章で恥ずかしいことはいっぱいある。言い訳だけは言わずに、言い訳で恥ずかしい思いをさせるのだけは避けたい。
弟子とかいない人でも、プログラムを書き直した後で、実はって言い訳を添えるのは可愛げがあると思ってもらえるかも。描き直す前の言い訳はいいわけ？
3.2 機密（個人情報を含む）でない限り制約は公開する
資金面、時間などの制約で、実現できない事は、お断りの意味で公開する。
仕様、制約条件の違いを公開することは、自分では言い訳には分類していない。
人によっては、言い訳と感じる場合があるかもしれない。
人の口に戸はたてられないし、プログラム以外の概念の分類は自由。
3.3 特定の人に言い訳をしないとまずそうな場合は個別に連絡する
仕様や制約だけでは、伝わらない可能性のある大切な人には、個別に言い訳を書いて送るかもしれない。
心配されている方に安心してもらうための記述。
3.4 人の言い訳で気になった時は、科学的に分析する。
言い訳分析。
4 社会的分析
4.1責任転嫁
訴訟などを起こされる可能性がある場合に、責任転嫁をして、社会的な損失を受けないようにするための行動。
責任転嫁をする先があるかどうか。責任転嫁のつもりが、パワハラやセクハラや、裸の王様でもっとはずかしい事態になっていることについて、本人の自覚がない場合は近寄らないに限るかも。
4.2 人間的分析
言い逃れ
他人から褒められること以外が嫌な人が取る行動の一つ。
他人に責任転嫁するよりはいいのかも。人間力の評価に使えるかも。
相手への攻撃
激しい攻撃だけでなく、相手の書いたもののあらさがしや、別の表現を取るようにすすめたり、他のことをするように推奨したり、見た目はさまざまな手法がある。
相手を黙らせて、話題を変えたり、責任転嫁をさせたりする手法の一部の場合もある。
4.3 物理的分析
現象を、社会、人間面で捉えるのではなく、具体的な物理量で測定する。
書き込みの回数、書き込みの文字数。口頭であれば、声の大きさ、抑揚の変化率など。
情報処理学会若手の会で1990年前後に、ネットワークでの発言回数、発言量の分析を発表したことがある。
発言回数、発言量が多ければ、社会的にゆとりのある職業または立場という社会的分析にも発展できる。
4.4 論理的分析
記述内容の、物理的特性、生物的特性、社会的特性を洗い出し、その確率分布から、
論理的分析の可能性がほぼゼロであることを結論づけると面白いかも。
あるいは、論理的分析として、正しいことしか言っていない文章は、文章としての価値がゼロであることを結論づける方法も有効かもしれない。
論理的に正しいことは、社会的には役に立たない場合がしばしば。
論理、物理、生物（人間）、社会の各層とその関係を分析してみる時間があれば学会などで発表するとよい。
考察(consideration)
「Winnyの技術」を読む
で、ゴミファイルへの対応はある。有償のファイルへの対応していないところが問題だと感じた。
著者のさまざまな言明が言い訳になっていないことがわかるかもしれません。
せっかくよいプログラムを書いても、おかしな文章を書いたり、おかしな言い訳すると台無しになるかも。
Winnyの技術を評価している記事はこちら。
日本のプログラマが世界で戦える16分野・事例. 仮説・検証（53）
参考資料(reference)
Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる５つの道
プログラミング言語教育のXYZ
プログラミング言語教育のXYZ(youtube)
プログラミング言語の勉強の仕方と水準
プログラム初心者が知らなくてもいいこと
プログラマで飛び抜けた人が少ないという仮説
確率・統計(probability and statistics)
計画者(programmer)のための横顔(profile)入門 (1)「お金のセンスを測ってみる」on「確率論及統計論」輪講演習
確率論及統計論
科学四分類と算譜(program)
言語論と確率論
事業計画確率(project plan with probability)
科学四分類と算譜(program)
確率論及統計論輪講 精度より成果, 小寺浩司, 柏原一雄, 石津和紀,北野敏明, 佐藤克, 小室睦, 小川清
機敏(agile)
公開算譜は機敏だ＜完全版＞(open source is agile ＆名古屋のIoTは名古屋のOSで
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e
顧客指向のプログラミング(customer oriented programming)
https://qiita.com/kaizen_nagoya/items/6f3bc42253486b4b4818
分析(analyze)
効率的なHAZOPの進め方
安全分析（HAZOP）の際の声かけ
見直し(review)
Reviewerの数
プログラマの「日報、週報、月報、年報」考
作業改善(process improvement)
プロセス改善が改悪へと突き進む
ペアプロの３つの種類
ITシステムの見積もりの見積もり
作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
ソフトウエアプロセスの改善に向けて ~SPIへの今後の取組み~ (ソフトウエア開発・調達プロセス改善協議会報告書の公表)
記録(record)
コンパイラが生成したエラーを消してしまう人たちがいる。
ソフトによっては上書きしてしまうものがある。
システムが消してしまうなら、作業するたびに、自動で日付時間を入れたファイルとして写しを取れば良い。
手間はかからない。あとで、検索したり、分析したりするのに役立つ。
自分がやって記録していないことを、後で人に聞くのは仕事をする人間の態度ではない。
メモを取れよバカ野郎！
https://qiita.com/hatakkkk/items/62bf99e3149e32d3e0e2
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20190222 午前
ver. 0.02 自己参照追記 20190222 昼
ver. 0.03 参考資料追記 20190222 午後２時
ver. 0.04 小寺浩司(Kodera Hiroshi)さんがいいねしてくださった。日本語表現を訂正 20190222 午後３時
ver. 0.05 参考資料追記 20190222 午後９時
ver. 0.06 「Winnyの技術」を読む 追記 20190223 早朝
ver. 0.07 見出し番号変更 20190223 朝
ver. 0.08 師と呼ばれたら言い訳しない 20190223 午前
ver. 0.09 参考資料追記 20190223 午後
ver. 0.10 参考資料追記 20190224 午前
ver. 0.11 shell scriptについて記載 20190224 午後
ver. 0.12 加筆 20190225 早朝
ver. 0.13 はじめに、背景 みだし追記・加筆 20190225 朝
ver. 0.14 「自分用か、他人用か、プログラムを使う人、直す人を意識する」「読んでくれる人の顔と態度を思い浮かべながら書く」追記 20190225 午前
ver. 0.15 「確率論及統計論輪講 精度より成果」追記 20190303
ver. 0.16 誤植訂正 20190526
ver. 0.17 標題追記 20190601 夕
ver. 0.18 表現訂正 20190601 夜
ver. 0.19 参考資料追記20200328
ver. 0.20 記録、「メモを取れよバカ野郎！」URL 追記 20201226
ver. 0.21 表記補正 202112076
ver. 0.22 加筆 20220312
ver. 0.23 ありがとう追記 20230521
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.
