プログラマに限らず、失敗したり、怒られたり、いやがらせをされたり、果てはいじめられたりしても、めげないようにするにはどうしてきたかを書いてみます。
<この項は書きかけです。順次追記します。>
自分しかできないことをする
ぼくの先生 プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4
中学校の技術の先生に、人がやらないことをやれと言われました。
学校の教室内だけだったら、見回して、人がやらないことをやるのは簡単かもしれません。
世間に出て、人がやらないことをやろうと思うと、
誰が、何をやっているかを知らないと、人がやっていないことをやるのは難しい。
自分の直感を信じればいいという人もいるかもしれません。
演劇の寺山修司とか、音楽の松本隆とか細野晴臣（はっぴいえんど）とか、
自分では到底到達できなさそうなところを進んでいる人を遠目にみると、
自分の直感で人がやらないことができる自信はありませんでした。
何年ももがいてい、懸賞論文とか６年とか、７年とか出し続けて、毎年落ちるとめげていました。
あるところで、二位になったことがあり、ああ、上がいるんだという思いが増してきました。
４０年くらい前で、データ解析で賞をいただいたことは、今になっては納得ですが。
理論ではなく、数値計算であれば、勝ち目はあるかもという。
与件解析(data analysis)入門。仮説（195）
https://qiita.com/kaizen_nagoya/items/d9474c3bdb8ea0029bee
とにかく、やたらめったら勉強したり、やたらめったら書き散らすしかないと思っていました。
あるソフトウェアで、ソースコードがあり、知人がマクロを作ったとき、
自分もなにかやらねばと思い、ソースコードを持ち歩き、すべての行をコメントにして振る舞いを確認していったら、思いがけない成果がありました。
失敗の記録は後の人に役立つ
人が育つのに、成功が必要だという説には同意する。
成功した事例をどれだけ書いてあっても、そこには成功の本当の要因が記載されているとは限らない。
時代、環境、人の能力、性格、周りの人々など、書ききれてないことが山のようにある。
失敗の記録でも、失敗の要因も書ききれない程度は同じかもしれない。
ただ、経験則として、本人が失敗の要因だと思って書いた事項の50%くらいは妥当だと思う。
成功の要因は5%くらいしか妥当だと感じたことはない。
成功の要因は本人の見えないところにいっぱいあって、成功している限りみえない場合がある。
失敗の要因は、成功している限り見えないものが見えてしまうかもしれない。
その割合は約１０倍。
失敗したことを、公開できることなら公開の場に記録しよう。
先日、ある実験の報告を拝見した。
大事なのは成功したデータではなく、成功したデータが出るまでに、実験に失敗したデータの記録だと。
学生の電気実験で、前年の報告をもらって、実験をしても、同程度のデータが最初から取れることは半分もなかった。
報告には、失敗した実験の記録がなく、工業高校の頃から実験が得意だった同級生の経験に頼るしかなかった。
できれば、自分たちの報告は、失敗も記録しておけば、翌年からの実験の際に役立つかもしれないと思った。
失敗がいっぱい記録してあれば、経験の蓄積に厚みができ、もっと違う失敗をしてみる勇気がわくかもしれない。
失敗の場
実際の仕事では、失敗すると給料を減らされるかもしれない。
仲間はずれになるかもしれない。
そんな時に、気軽に失敗できるのがOSS（open source software)事業。
いろいろな失敗を報告すると喜ばれる。
自分の操作間違いの報告でも、そういう操作間違いをする人がいると分かれば、操作間違いを防止できるようなソフトに作り変えることを考えてくださる人もいるかもしれない。
利用しやすくはなっても、作りにくいままのソフトウェアもあるかもしれない。
勘違いで作り直したプログラムも公開することに意味がある。
同じ間違いをしないようにすることと、同じ間違いをしても、前提となる知識とか習慣とか道具が違うかもしれない。
知識、習慣、道具が違っても、同じ間違いをするのであれば、なにかシステムの作り方に改良の余地があるのかもしれない。
ソフトウェアをよくすることだけがOSSの貢献ではない。
Re:ゼロから始めるOSS貢献
https://qiita.com/glassmonkey/items/5d7410d41e466451c854
社外の開発に関わることは社内に良いものを取り入れることもできるし、ある意味で社内の再評価につながるとも思ったので後輩たちには積極的にOSSプロジェクトに参加していってほしいですね。」
仮説
失敗する前に、今からやることの制約条件を知っているかどうか。
経験があるかどうか。経験がなければ、経験のある人の記録をみておくかどうか。
学生実験の場合では、前年の実験の報告をみておくこと。
数年前だと、実験装置、実験環境、材料、道具の違いがあるかもしれない。
細かい制約条件が報告に書いてないと、古い報告は、制約条件が違う可能性を想定しておくとよい。
制約条件は無限にあり、書ききれない。
いつ、だれにとって、どういう状況かで、大事な制約条件は違う。
立てた仮説を検証してみる過程で、制約条件の抜け漏れなどで失敗することは、
時間の変化の中でありうることだろう。
一つでも仮説についての新たな知見があれば、プログラミング実験そのものが失敗でも、
報告としては有用な情報が一つつけ加わることになる。
仮説の失敗
「失敗してもめげないプログラマになるには」という仮説そのものが間違い。
失敗は、失敗を記録するためのものであり、着実に成長するための記録でしかない。
問題は、過去に類似の失敗の記録があるのに、その記録を読まずに、同じ失敗を繰り返すこと。
これは、失敗ではなく、怠惰。
怠惰と、失敗を一緒にしてはいけない。
参考資料
モチベーションが落ちた時の対処法
自己参考資料
「駄目だ、もう何もできない」と思った時にするかもしれないこと
初めての CEDD(Compile Error Driven Design) ８回直してコンパイル。
https://qiita.com/kaizen_nagoya/items/9494236aa1753f3fd1e1
C++/C コンパイルエラーを記録するとよい理由7つ
https://qiita.com/kaizen_nagoya/items/85c0e92b206883140e89
今日は何をやってもうまくいかない。明日のために３項目エラー等記録。
https://qiita.com/kaizen_nagoya/items/8ad6e7a2fa19e01ba9bb
「プログラマを目指す」ことの間違い？
https://qiita.com/kaizen_nagoya/items/513f39bcf01a3db36d09
pip install cupyでエラーが出た
https://qiita.com/kaizen_nagoya/items/19a66d86cd7eaf733a3e
docker不調 -> Athrill動作 -> 日報に
https://qiita.com/kaizen_nagoya/items/167c0efd482dbf2cec1f
機械学習・深層学習でできること、できないこと。仮説１０個。
https://qiita.com/kaizen_nagoya/items/41a567f149f78145fd4c
「Qiitaのいろいろランキング2019」への感謝と提案
https://qiita.com/kaizen_nagoya/items/40b8557a20e8d75d62b5
仮説（116）「今日死ぬとしたら」日本語が不得意なプログラマが話をする 日本語（12）
https://qiita.com/kaizen_nagoya/items/61a03864ac6c011e6164
仮説（163）生産縮小、規模縮小、人員縮小時には自動化道具を増強
https://qiita.com/kaizen_nagoya/items/8df1dc7d3a5c7869d3c2
仮説(13)今、技術面で中途半端になっていること（自分）16項目
https://qiita.com/kaizen_nagoya/items/65ccc33ea9f738d02a85
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
#文書履歴(document history)
ver. 0.01 初稿 20190501
ver. 0.02 表現修正 20190503
ver. 0.03 データ解析追記 20200519 夕
ver. 0.04 Re:ゼロから始めるOSS貢献 追記 20200519 夜
ver. 0.05 「駄目だ、もう何もできない」と思った時にするかもしれないこと URL追記 20220312
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.