Edited at

仮説・検証(87)プログラマとして、「プログラムを書く時、文章を書く時、言い訳をする時」に心がけていること


はじめに(introduction)

プログラマとして、プログラムを書く時、文章を書く時、言い訳をする時に心がけていることを整理します。

一番は、誰か、具体的な特定の個人を思い描いて書くことです。


背景(back ground)

Twitterで、弟子から師匠と呼ばれている人が、つまらない言い訳書いているのを拝見して思い立ったものです。

決して、すべてのプログラマに言い訳を言うなという趣旨ではありません。

仕様、制約条件の違いを公開することは、言い訳には分類していません。


1.プログラム


1.1 書いたものは保存する

shell のコマンドでなければ、書いたものは保存している。

shell のコマンドでもshellのhistoryは保存しておくとよい。

一度っきりのScriptで、なおかつセキュリティ上やばい内容で、流出すると大事になるようなものでも、自分しか見えない場所に、こそっと保存することがある。

電子的に保存しない方がよさそうであれば、印刷して金庫の中に入れておくこともある。

暗号化については、暗号化して復号できなくなっている暗号済みファイルの存在も危険。

いろいろ迷うことあり。

自分が積極的に書いたものだけでなく、コンパイルエラー、実行エラーなど副産物もなるべく記録する。

C++/C コンパイルエラーを記録するとよい理由7つ

https://qiita.com/kaizen_nagoya/items/85c0e92b206883140e89

初めての CEDD(Compile Error Driven Design) 8回直してコンパイル。

https://qiita.com/kaizen_nagoya/items/9494236aa1753f3fd1e1

コンパイル用shell script C版(clangとgcc)とC++版(clang++とg++)

https://qiita.com/kaizen_nagoya/items/74220c0577a512c2d7da

プログラマの「日報、週報、月報、年報」考

https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69

計算機と計算機網の使い方、使い方の覚え方、使い方がわからない時の検索の仕方、使い方がわからない時の報告の仕方

https://qiita.com/kaizen_nagoya/items/d6e0c201a71af8670510

open な issue がどんどん溜まる現象を解決するために

https://qiita.com/kaizen_nagoya/items/efe22d9a23ad2e9934d6


1.2 機密(個人情報を含む)でない限り公開する

Review, 試験を依頼するにあたり、公開しておくと相手も作業がしやすい。

思い違いや、書き方のよくないところを指摘くださることもある。

docker hub とQiita

https://qiita.com/kaizen_nagoya/items/798358bba382d693e391


1.3 自分用か、他人用か、プログラムを使う人、 直す人を意識する

自分用であれば、ひとまず動くことを目指す。

他人用で、誰がこのプログラムを直すかで、関数名、変数名、定数名を決める。

実際にプログラムを変更してくれそうな人の顔と態度を思い浮かべながら書く。

明日自分が直す可能性があれば、明日の自分がわかるような注釈を書いておく。

英語文化圏の人にも使ってもらう場合は、英語の語源を調べる。

プログラマが知っているとよい英単語の語源

https://qiita.com/kaizen_nagoya/items/9de6d47c47e2c211222b


1.4 人のプログラムで気になった時は、書き足す・書き直す

人のプログラムで気になった時、原則、文章で意見を言わない。

動作させたエラーや、現象を記録したり、

自分ならこう書くという部分を書き足したり、

全部書き直したりする。

プログラマが欲しいのは、意見じゃなくて、プログラムかエラーの結果か、書き直し方の例。

VZエディタ移植(porting)に当たって実施したことと成果

https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949


2.文章


2.1 書いたものは保存する

夢の中で考えたことは、起きたらすぐに書き留めるようにしている。

すごいアイデアを朝はおぼえていて、昼に忘れることがある。

書いたものは保存する。

紙、ホワイトボードに書いたものは写真を取り、

電子化したものは予備はネットにあげる。

http://researchmap.jp

というサイトでは、ネットワークが不安定だったり、ログイン後時間が経過していると、

保存時に警告を出さずに、ネットの彼方に消えてしまう。


2.2 機密(個人情報を含む)でない限り公開する

文章の見直し(review)を依頼するにあたり、公開しておくと相手も作業がしやすい。

思い違いや、書き方のよくないところを指摘くださることもある。

wiki, git系のWikiなどに書くか、Qiitaに書くようにしよう。

Qiita記事 いいね と views の関係

https://qiita.com/kaizen_nagoya/items/d30240b2a9adec288ca9

今年のQiita記事の目標

https://qiita.com/kaizen_nagoya/items/33988e811b174e443bfa

楽しいQiitaの使い方 壁10罠6つ技7つ

https://qiita.com/kaizen_nagoya/items/7828d0b1d47ad21b45c6


2.3 読んでくれる人の顔と態度を思い浮かべながら書く

Qiitaであれば、よくいいねを押してくださる方の態度を考えながら書く。

知り合いではなくても、いいねを押してくださった方の場合は、その方の

過去の記事を拝見したり、いいねの傾向を拝見し、

その人が興味を持ちそうな話題や、論理展開を書き足す。


2.4 人の文章で気になった時は、書き直す

プログラムは、部分的な書き直しをしても、試験をすれば違いが確認しやすい。

文章は、部分的な書き直しが効く場合と、書いた人の立場で、書き直しが理解できない場合がある。

原則は、別途書き直してみて、違いが明確になれば、気になった文章の書き手に連絡する。

相手が理解できそうな水準に達していない場合には、精進しながら書き直す。

なぜ少しづつQiitaの記事を追記しているか

https://qiita.com/kaizen_nagoya/items/fa8b102a92d094437416

2019年に入ってからのQiita記事の書き方

https://qiita.com/kaizen_nagoya/items/1786ed40dc5c73ed8b46

Qiita記事の最近の書き始め例

https://qiita.com/kaizen_nagoya/items/c37a680065010b3eab5a


3.言い訳


3.1 師と呼ばれたら言い訳しない

原則、言い訳は言わない。

プログラムにしても文章にしても言い訳が欲しいのではなく、書き直したものが欲しい場合に、言い訳されるとむっとする。

弟子の1割は弟子になる前から自分よりも優秀だし、師匠だと思ってくれる人がいたら、言い訳をしたら、師匠であることを恥ずかしいと思わせてしまう。

プログラム、文章で恥ずかしいことはいっぱいある。言い訳だけは言わずに、言い訳で恥ずかしい思いをさせるのだけは避けたい。

弟子とかいない人でも、プログラムを書き直した後で、実はって言い訳を添えるのは可愛げがあると思ってもらえるかも。描き直す前の言い訳はいいわけ?


3.2 機密(個人情報を含む)でない限り制約は公開する

資金面、時間などの制約で、実現できない事は、お断りの意味で公開する。

仕様、制約条件の違いを公開することは、自分では言い訳には分類していない。

人によっては、言い訳と感じる場合があるかもしれない。

人の口に戸はたてられないし、プログラム以外の概念の分類は自由。


3.3 特定の人に言い訳をしないとまずそうな場合は個別に連絡する

仕様や制約だけでは、伝わらない可能性のある大切な人には、個別に言い訳を書いて送るかもしれない。

心配されている方に安心してもらうための記述。


3.4 人の言い訳で気になった時は、科学的に分析する。

言い訳分析。


3.1 社会的分析


責任転嫁

訴訟などを起こされる可能性がある場合に、責任転嫁をして、社会的な損失を受けないようにするための行動。

責任転嫁をする先があるかどうか。責任転嫁のつもりが、パワハラやセクハラや、裸の王様でもっとはずかしい事態になっていることについて、本人の自覚がない場合は近寄らないに限るかも。


3.2 人間的分析


 言い逃れ

他人から褒められること以外が嫌な人が取る行動の一つ。

他人に責任転嫁するよりはいいのかも。人間力の評価に使えるかも。


 相手への攻撃

激しい攻撃だけでなく、相手の書いたもののあらさがしや、別の表現を取るようにすすめたり、他のことをするように推奨したり、見た目はさまざまな手法がある。

相手を黙らせて、話題を変えたり、責任転嫁をさせたりする手法の一部の場合もある。


3.3 物理的分析

現象を、社会、人間面で捉えるのではなく、具体的な物理量で測定する。

書き込みの回数、書き込みの文字数。口頭であれば、声の大きさ、抑揚の変化率など。

情報処理学会若手の会で1990年前後に、ネットワークでの発言回数、発言量の分析を発表したことがある。

発言回数、発言量が多ければ、社会的にゆとりのある職業または立場という社会的分析にも発展できる。


3.4 論理的分析

記述内容の、物理的特性、生物的特性、社会的特性を洗い出し、その確率分布から、

論理的分析の可能性がほぼゼロであることを結論づけると面白いかも。

あるいは、論理的分析として、正しいことしか言っていない文章は、文章としての価値がゼロであることを結論づける方法も有効かもしれない。

論理的に正しいことは、社会的には役に立たない場合がしばしば。

論理、物理、生物(人間)、社会の各層とその関係を分析してみる時間があれば学会などで発表するとよい。


考察(consideration)

「Winnyの技術」を読む

https://qiita.com/kaizen_nagoya/items/b6639c9f827be9a68a91

で、ゴミファイルへの対応はある。有償のファイルへの対応していないところが問題だと感じた。

著者のさまざまな言明が言い訳になっていないことがわかるかもしれません。

せっかくよいプログラムを書いても、おかしな文章を書いたり、おかしな言い訳すると台無しになるかも。


参考資料(reference)

Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる5つの道

https://qiita.com/kaizen_nagoya/items/c72fa39e3191ea0290df

プログラミング言語教育のXYZ

https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4

プログラミング言語教育のXYZ(youtube)

https://www.youtube.com/watch?v=He1_tg4px-w&t=486s

プログラミング言語の勉強の仕方と水準

https://qiita.com/kaizen_nagoya/items/ba2651035339ef45b3aa

プログラム初心者が知らなくてもいいこと

https://qiita.com/kaizen_nagoya/items/3eaeb88e583898b8aae7

プログラマで飛び抜けた人が少ないという仮説

https://qiita.com/kaizen_nagoya/items/f0d22e20f6d2c58f2c1b


確率・統計(probability and statistics)

計画者(programmer)のための横顔(profile)入門 (1)「お金のセンスを測ってみる」on「確率論及統計論」輪講演習

https://qiita.com/kaizen_nagoya/items/c77cafd3fe47a558bfe5

確率論及統計論

https://qiita.com/kaizen_nagoya/items/cc3730e4494e7d37ea4d

科学四分類と算譜(program)

https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603

言語論と確率論

https://qiita.com/kaizen_nagoya/items/cc3730e4494e7d37ea4d

事業計画確率(project plan with probability)

https://qiita.com/kaizen_nagoya/items/f2dc5d216e57df844f50

科学四分類と算譜(program)

https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603

確率論及統計論輪講 精度より成果, 小寺浩司, 柏原一雄, 石津和紀,北野敏明, 佐藤克, 小室睦, 小川清

https://www.slideshare.net/kaizenjapan/ss-70572076?qid=1ddc1378-fa37-4753-ac70-0ce575e87198&v=&b=&from_search=28


機敏(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の進め方

https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446

安全分析(HAZOP)の際の声かけ

https://qiita.com/kaizen_nagoya/items/381649a6ea025ecba173


見直し(review)

Reviewerの数

https://qiita.com/kaizen_nagoya/items/36aefeea21fb190bf873

プログラマの「日報、週報、月報、年報」考

https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69


作業改善(process improvement)

プロセス改善が改悪へと突き進む

https://qiita.com/kaizen_nagoya/items/0f3a1174f81935bb6d85

ペアプロの3つの種類

https://qiita.com/kaizen_nagoya/items/5c80663799d99b807870

ITシステムの見積もりの見積もり

https://qiita.com/kaizen_nagoya/items/93a7d3ba13da0a7a9c15

作業診断(process assessment)を成功させる5つの鍵。失敗する5つの罠

https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab

ソフトウエアプロセスの改善に向けて ~SPIへの今後の取組み~ (ソフトウエア開発・調達プロセス改善協議会報告書の公表)

http://warp.da.ndl.go.jp/info:ndljp/pid/1368617/www.meti.go.jp/kohosys/press/0002639/0/020419spi.pdf


文書履歴(document history)

ver. 0.01 初稿 20190222 午前

ver. 0.02 自己参照追記 20190222 昼

ver. 0.03 参考資料追記 20190222 午後2時

ver. 0.04 小寺浩司(Kodera Hiroshi)さんがいいねしてくださった。日本語表現を訂正 20190222 午後3時

ver. 0.05 参考資料追記 20190222 午後9時

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 夜

http://b.hatena.ne.jp/guide/bbutton

このエントリーをはてなブックマークに追加