ソースコードはしゃべるように書け
https://qiita.com/chooyan_eng/items/72f86a2ce2ca67d3b4a4

に触発された記事です。

20代の頃から、約40年

Programming like a poem

プログラムを詩のように書くを信条にして、プログラミング、プログラミング教育、プログラム試験をしてきました。

プログラマの、プログラミングの量と質の差は、
小説家の小説の量と質の差と似ているというのが経験則です。

仮説１　量を多く書く人は質がわるい

量を多く書いて来た人の品質の分布と、量を少ししか書けない人の品質の分布は、
量を多く書いて来た人の方が、品質のよい方に偏っているというのが経験則です。

根拠としては、多く書くと、多くの不具合に遭遇し、その治し方も習得するため、
すこししか書いてない人とは品質が段違い。

量が多くなるように書く人の品質の分布と、量が少くなるように書く人の品質の分布は、
量が少なくなるように書く人の方が、品質のよい方に偏っているというのが経験則です。

根拠としては、量が多ければ、誤りも混入しやすく、量が少なく書く人の方が品質がよい。

「量を多く書く人は質が悪い」という誤解は、「量が多くしか書けない人は品質が悪い」という理解とが混ざったのかも。

量が少しで品質のいい人と、量がそこそこで品質の悪い人を見て、経験則に取り入れているのかもしれません。いろいろな人の確率、分布を調べてみてはどうでしょう。

仮説２　飛び抜けた人はそんなにいない

ある年に面白い道具(tool)を１本書いた大学４年生がいました。
その次も期待していました。
担当教授が、方向性を振り回し、その後、大学院の２年かかっても４年時のほどの成果はでませんでした。

なぜ、書きたいものを書かせればいいものが書けるのに、
不必要な制約や、方向性に対する批判をするのかうんざりしました。

企業の中では、金になるかならないかで、３年かければ金になるものも、１年で回収しなきゃといって、飛び抜けた人をつぶしていくのを、遠くから眺めることがあります。

飛び抜けた人はそんなにいないと言う人が、ひょっとしたら潰している人かもしれません。

経験則では、学生で10人に１人は、最初にあったときに、自分よりプログラミング能力が上でした。やりたいようにやってもらうと、その一人と、もう一人が、飛び抜けた状態になってくれます。

小説家になろうと思って文学部に入った学生で、プロになれる確率より、
プログラマになろうと思ってプログラムを書き始めた人の方が、
飛び抜けたプログラマになる確実に高いと思います。

文学は最初の障壁は人です。
プログラミングの最初の障壁はプログラミング言語です。
プログラミング言語に、そうとう駄目出しされ、よいものしか通らないようになって、世の中に出る。
小説家よりもプログラマで飛び抜けた人が多い理由は、障壁の違いだと思っています。

仮説３　飛び抜けた人に依存していてはいけない

いかにももっともらしく聞こえます。
GCC, Linux、今、世の中でものすごい量で使われているソフトウェアは、ほとんどが、飛び抜けた人が書いたものに依存したソフトウェアです。

これらのソフトウェアのうち、オープンソースであれば、飛び抜けた人以外の人も、よくすることに協力できる仕事の仕方を組織できるため、使う危険性はありません。

飛び抜けた人を支える組織、作業の仕方(process)が大事であることは歴史的な経験則ではないでしょうか。

数学、物理の法則と同様、誰かが発見してくれれば、あとの人はそれを利用する仕組みを作ればいいのですから。

飛び抜けた人に依存する仕組みと、飛び抜けた人を潰さない仕組みの均衡が大事。
どちらかだけに力をいれているとまずい。

仮説4 若いうちしかプログラムは書けない。

10代で燃え尽きる人はいます。
20代が全盛期の人もいます。
30代からプログラムを組み始め、仕事にされる方々がおみえになります。

当方で、言語処理100本ノックを一番最初に、最後まで実行された方は30代です。
言語処理100本ノックをdockerで。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

40代で、管理職はプログラム組んじゃだめだと言われ、転職してプログラム書かれている人がいます。
20年前、50代でアセンブラでプログラム組まれている方がおみえでした。

今、60代でのプログラムをお勧めしています。

６５歳からのプログラミング入門
https://qiita.com/kaizen_nagoya/items/1561f910c275b22d7c9f

どういう問題を解決したいか、プログラムが解決に役立つか、その点に関するやる気が鍵です。

昨年、３人の３０代で初めてプログラミングする技術者の方の教育を担当させていただきました。
３人とも音楽が趣味または仕事でした。
３週間で、pythonで音楽のプログラムが組めるようになられました。

下記は、３人の方に音楽用の題材をさがしてもらうために書いた記事。

プログラムは音楽だ (A program is a music.)
https://qiita.com/kaizen_nagoya/items/33c9f33581e6886f8ad8

仮説5 飛び抜けているかどうか分からない

普段仕事をしていると制約条件が多すぎて、飛び抜けた仕事がしづらい環境が多いかもしれません。

良いのは、自分の仕事の道具を作ることです。
自分が利用者ですから、内容や出来について文句を言われることはありません。

短時間で、自分が便利になる道具が作れることが、飛び抜ける一つの段階かもしれません。

国立研究開発法人宇宙航空研究開発機構（JAXA）と独立行政法人情報処理推進機構（IPA）共催、第１４回クリティカルソフトウェアワークショップ（WOCS2: Workshop on Critical Software System）
https://www.ipa.go.jp/sec/events/20161212.html

データセンターにおけるITオペレーションの業務品質向上を達成した改善事例
NSSLCサービス株式会社 鈴木　貴広
https://www.ipa.go.jp/files/000055796.pdf

自分の道具が整備されているときには、外部のコンテスト、ハッカソンに参加するのも手かも。

TOPPERSまとめ　#名古屋のIoTは名古屋のOSで
https://qiita.com/kaizen_nagoya/items/9026c049cb0309b9d451

TOPPERS活用アイデア・アプリケーション開発コンテスト受賞作品紹介(1) 第一回(2011)アプリケーション開発部門銀賞『Natural Tiny Shell Task』中村晋一郎
https://qiita.com/kaizen_nagoya/items/763209c213e3c0daee10

第四回(2014)アプリケーション開発部門 金賞Toppers_ASPカーネルとScilab による組込みメカトロニクス制御シミュレーション 塩出武 (個人)
https://qiita.com/kaizen_nagoya/items/fe398eb623889f587bba

第四回(2014)アプリケーション開発部門 銅賞 組込みソフトウェア学習用教材ボードNCES TRAINING BOARDと教材テキスト，サンプルプログラム一式 松浦 光洋(個人) / 本田晋也（名古屋大学）
https://qiita.com/kaizen_nagoya/items/aa318576dffb857893eb

第五回(2015)アプリケーション開発部門 銅賞シュリンク版TOPPERS/SSPとそれを利用した タミヤラジコン改造RaspberryPiスマホリモコンカー アライブビジョンソフトウェア株式会社（代表：髙橋和浩）
https://qiita.com/kaizen_nagoya/items/c79a812ee6163e16342a

第八回(2018)アプリケーション開発部門金賞 TOPPERS/ATK2 カーネル向け実機レス開発環境（athrill2） 森崇（(株)永和システムマネジメント）
https://qiita.com/kaizen_nagoya/items/92faa2220d63588afa9d

仮説６　飛び抜けた人を育てるのは難しい

飛び抜けた人を育てるのは難しいって、本当でしょうか。
仕事で道具を作ったり、仕事時間でコンテスト・ハッカソンに出るのもよいでしょう。

仕事の１割の時間でも、将来や教育のために使う制度があれば容易です。
そうでないと、仕事時間以外に、仕事のための勉強を強いるブラック企業になってしまうかもしれません。

お客さんにプログラムを収めるのに、その分野の世界一のプログラマであるとよい。
お客さんにしてみれば、世界一でもない人に、なぜお金を払わなければいけないのだろうと思っているかもしれません。
飛び抜けた人じゃない人に、仕事をしてもらってもお客さんを喜ばせるのは難しいと思ったことはありませんか？

飛び抜けるためには、次の３項目がうまく均衡しているとよい。本人の意思が一番大事。邪魔をする人がいてもその分助けてくださる人がいれば、なんとかなる。

1 本人の意思(will)

何か解決したい、何か作りたい、何か人と違うことがしたいという意思。

2 邪魔をしない環境(environment)

足をひっぱる人のいない空間、
自分がやりたいと思ったことを実行する１日１時間、
やりたいことをやれる空間（例えばgithub, dockerhub）

3 もう一歩先に行ってもいいよという助言(advice)

やったことをいいよと行ってくれる先生、先輩、知人
代替案候補を提案してくれる顧客
参考にするとよい資料をしめしてくれる専門家

ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

顧客指向のプログラミング(customer oriented programming)
https://qiita.com/kaizen_nagoya/items/6f3bc42253486b4b4818

まとめ(summary)

小説家の仕事の仕方は、パッケージソフトウェアのプログラマのような場合が多い。
どのお客さん向けに書くかは、書く側の選択で、当たるところを狙わないといけない。

それに対して、お客さんから頼まれてプログラムを書く仕事は、
ソフトウェアのマニュアルを書いたり、その会社の規則を作ったりする仕事に似ているかもしれない。

飛び抜けた人でなければ、前者の仕事で成功しないかもしれないし、
５年後、１０年後しか売れないかもしれない。

日銭をかせぐには、言われたものを書く、単価の安い仕事をこなすしかないかも。
飛び抜けていかなければ、長期的には仕事を競争で取られてしまうかもしれない。

とんなに小さな領域でも、飛び抜けているのでなければ、仕事でプログラムを書く価値はない。
飛び抜けた人が、自動生成してしまうかもしれない。

飛び抜けることができるためには、才能と努力と環境の３つのうちのなんらかの組み合わせがいいかも。

小説家が６５歳を超えても書き続けるように、プログラマも６５歳を過ぎても書き続けてもいいというのをまとめにしてみます。

仕事上、設計が３割、試験が３割、教育が３割、その他１割です。
一緒に仕事をしている方は、設計が８割、試験が１割、その他１割という感じの方が多い感じです。
立場の違いによって、見えていることが違うため、ここに書いていることがピンとこないこともあると思います。

飛び抜けた人が、自動生成作っても、お金にならないからと捨てられたのを目撃したことがあります。
実情としては、飛び抜けた人の半分くらいは、傷心して業界を去っている感じです。
官庁の飛び抜けたプログラマも半分くらいは、官庁を辞めています。

IT企業、製造業、官庁から去る、飛び抜けたプログラマの比率は同じくらいというのが経験則です。
逆に、伸びている企業は、飛び抜けた人の仕事をうまく生かしているように感じています。

DataRobotという機械学習のシステムに、ソフトウェアを追加して業績をあげているある会社は、
マスコミへの情報開示を禁じていて、詳しく書けないのが残念です。

マスメディアの情報に振り回されないことも、飛び抜けた人を育てる土壌の一つかもしれません。

参考資料(reference)

ぼくのかんがえた さいきょうの新人研修
https://qiita.com/aosho235/items/23625cdb340eaaeb5b94

新人教育の際に気をつけたこと
https://qiita.com/yu-croco/items/c41aa79a87fdbcf418fb

自己参照(self reference)

Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる５つの道
https://qiita.com/kaizen_nagoya/items/c72fa39e3191ea0290df

プログラミング言語教育のXYZ
https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4

プログラミング言語の勉強の仕方と水準
https://qiita.com/kaizen_nagoya/items/ba2651035339ef45b3aa

プログラム初心者が知らなくてもいいこと
https://qiita.com/kaizen_nagoya/items/3eaeb88e583898b8aae7

disること仮説・補題・例題
https://qiita.com/kaizen_nagoya/items/e4f486edf00598945598

機敏(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

確率・統計(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

課題(issue)

open な issue がどんどん溜まる現象を解決するために
https://qiita.com/kaizen_nagoya/items/efe22d9a23ad2e9934d6
プログラマが英語で報告・質問する時のいくつかの事例・方法
https://qiita.com/kaizen_nagoya/items/9cf2ba858e52e9795b67

見直し(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
ペアプロの３つの種類
https://qiita.com/kaizen_nagoya/items/5c80663799d99b807870
ITシステムの見積もりの見積もり
https://qiita.com/kaizen_nagoya/items/93a7d3ba13da0a7a9c15
作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
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

読書(reading)

amazon殿堂入りNo1レビュアー(2011)
https://www.amazon.co.jp/review/hall-of-fame
https://www.amazon.co.jp/gp/profile/amzn1.account.AEZYBP27E36GZCMSST2PPBAVS3LQ/ref=cm_cr_tr_tbl_hof_name

booklog 改善本棚
https://booklog.jp/users/kaizen

読書メーター kaizen
https://bookmeter.com/users/121023

文書履歴(document history)

ver. 0.01 初稿 20190222 午後３時
ver. 0.02 仮説４若いうちしかプログラムは書けない。追記 20190222 午後４時
ver. 0.03 参考文献追記 20190222 午後９時
ver. 0.04 プログラムは音楽だ　追記　20190223 午前
ver. 0.05 まとめ　追記 20190223 昼
ver. 0.06 表現補足 20190223 夕方
ver. 0.07 まとめに小説家を追記 20190223 夜
ver. 0.08 誤記、表現調整 20190323 深夜
ver. 0.09 仮説5 飛び抜けているかどうか分からない 追記 20190223 真夜中
ver. 0.10 第八回(2018)アプリケーション開発部門金賞 TOPPERS/ATK2 カーネル向け実機レス開発環境（athrill2） 森崇（(株)永和システムマネジメント）追記 20190223 23:55
ver. 0.11 参考資料追記 20190224 朝
ver. 0.12 邪魔と助けの均衡 追記 20190224 昼
ver. 0.13 表題に「」追加 20190224 午後４時
ver. 0.14 仮説６　飛び抜けた人を育てるのは難しい　追記　20190224 夕食前
ver. 0.15 マスメディアに振り回されない 20190224 夕食中
ver. 0.16 読書、官庁　追記 20190224 夕食後
ver. 0.17 表現訂正、URL追記 20190225 午前3時
ver. 0.18 Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる５つの道 20190225 朝
ver. 0.19 編集リクエストに基づき「量を多く書いて来た人」と「量が多くなるように書く人」を区分 20190225 午前
ver. 0.20 参考資料編集 20190225 もうすぐ昼
ver. 0.21 表現加筆 20190225 昼
ver. 0.22 見出し追記 20190419
ver. 0.23 見出し変更 20190512

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

4月といえば人事考課の時期なので『プログラマのためのサバイバルマニュアル』の一節である「人事考課を勝ち抜く」を再読しました。
人事考課を勝ち抜きたいみなさんのためにもまとめておきます。

新入社員のみなさんもいずれ通る道なので頭の隅にでもおいておくといいかも。

対象読者

人事考課を受ける人全般(ただし管理職を除く)。
あくまで管理職から評価を受ける人向けの内容です。

『プログラマのためのサバイバルマニュアル』って？

プログラマとして働き始めた人向けの、プログラマとして生き残るための指南書です。
プログラマとしての心構えや働き方全般、更には簡単な社内営業に至るまで書かれた良書です。

Amazon プログラマのためのサバイバルマニュアル

以下、該当箇所のまとめです。

人事考課のメカニズム

管理職にとって年1回の部下全員の評価をどう書くのは悩みの種である。
プログラマの能力を定量的に評価するのは難しい。
それは基本的に上司の問題だが、評価を受ける私たちができることは、そんな哀れな上司に可能な限り最高の情報を提供して、可能な限りよい評価を受けることである。

人事考課の目的は、誰が頑張って誰がそうでないかを把握することである。
企業は頑張った人に褒美を与え、そうでない人にはそれなりの対応をしなければならない。
あなたの上司には、誰が成績上位者で誰が下位かを記録する、という仕事が課せられている。

自己評価

まず人事考課のアプローチとして、フォーマルな感じで「あなたが最近会社のためにしたことは何ですか？」と書かれたフォームが渡される。
ここに記入した内容は正式な評価書にコピペされる可能性が十分にあるので真剣に取り組んだ方がよい。

書くべきことは以下の5つ。
- 作業の質
- 作業量
- 適時性
- コスト削減
- チームへの貢献

以下に簡単にまとめる。

作業の質

しっかりしたコードを書いていることを証明できる情報。
コード行あたりのエラー率、フィックスしたバグの数、書いたテストケースなど。
定量的なことでなくても、同僚からの好意的なコメントや改善したことなどでも可。

作業量

どれだけ仕事をしたか。
完成させた機能の数、出荷された製品、ソースコードのコミット回数など。
バージョン管理システムの機能を活用しよう。

適時生

納期を守れたか。
守れていたなら自己評価の中で報告する。

コスト削減

コスト削減、省力化につながる成果。
管理職は常にコスト削減の方法を探しているので、それらのことで成果があれば報告する。

チームへの貢献

チームや上司の評価につながる成果。
自分の成果だけでなく、自分の働きがチームや上司の評判につながったものがあれば報告する。

なお、これらはどれくらい具体的に書けばよいかを管理職に確認すること。
また、複数成果があればより良いものを書き、逆に書くネタがない場合はメールやバージョン管理システムの履歴を漁ってネタを集めよう。

360度評価

同僚に評価を丸投げする方法もある。
いっしょに仕事をした別部門の同僚数人に、あなたの評価を尋ねる。
ヒアリングする先の候補を管理職から尋ねられるかも知れないので、自分の味方になってくれる人たちをあらかじめ把握しておくこと（普段からいろんなところに顔を出して味方をつくっておくこと）。

管理職の評価

自己評価、360度評価など、他の人々が書いた評価をできる限り集めた後、最後に管理職が最終的な評価を書く。
だいたいは本人の自己評価に管理職のコメント、360度評価のコメントをつけたものになる。
なお、管理職はここですばらしい文章を書いたところで給料があがるわけではない。

ランキング

人事部門は各チームのメンバーの成績は少数のスター、少数の落伍者、多数の普通の人、最悪のグループの4つから構成されていると決めつけているので、管理職はそれに合わせて部下をランク付けしなければならない。

評価の結果はあなたが4ランクのどこに属しているかで（直接的あるいは間接的に）表される。

実はすべての管理職は部下のランク付けを嫌がっている。
彼らはすばらしいチームを作るために多大な努力をしているのに、人事部門から「落伍者がいるはずだ」と言われたら嫌になるのは当たり前である。

昇進

誰を昇進させるかについては、最近の人事考課の結果は間違いなく考慮される。
また、昇進したい役割を獲得する前からその役割に求められる行動をしているかも考慮される。
具体的には、テクニカルリーダーの候補を探す際は、あなたがすでにテクニカルリーダーと同じような仕事をしていれば、候補の筆頭になりやすい。
これについてはあなたの努力を反映させられる。

課題（宿題）

• 自分の成果を記録し、自己評価を書く際に掘り出す
• 人事考課の時期が近付いたら、360度評価のヒアリング先になってくれる人を考えておき、引き受けてもらえるようにしておく
• 人事考課の1か月ほど前になったら管理職に雑談として、自分の仕事ぶりと改善点について尋ねておく

以上、まとめでした。

これら以外に個人的にしておくといいと思うのは、出世している先輩や上司に、評価される自己評価の書き方のレクチャーを受けることです。
出世している人たちに自己評価の書き方が下手な人は（権力による働きかけがない限り）基本的にいないので、参考になります。

私自身、人事考課を勝ち抜けているかは疑問ですが、一人でも多くの頑張ったエンジニアが勝ち抜くための参考になれば幸いです。

事業会社でデータアナリストをしているsouと申します。
今の会社に未経験の立場から雇っていただき、約1年が経過しました。

1年間働いてみて、この会社のことは大好きになりました。
しかし、私はあまり期待された成果を出すことができませんでした。

自分への戒めと、今後未経験でエンジニアとして働く方々に私の失敗を見て頂いて
同じ失敗をしないで済むようにすごしてほしいと思い書きました。

また、あくまで私の失敗と自分がこうした方がいいんじゃないかと思っていることを書いているので
自分で考えて、ここに記載している方法と違う手法を行うというのも有りだと思います。

失敗から学んだ3つのこと

• コミュニケーションを恐れない
• 自分のことを真剣に考える
• 自分を責めない

コミュニケーションを恐れない

人の目が気になる人は多いと思います。
私も「こんなこと聞いても大丈夫かな」「slackでこの発言すると変なやつだと思われるんじゃないか」といった考えをずっと持っていました。
そのため積極的に発言を行わず、受動的な行動ばかりとっていました。
その結果、後から入ってきた積極的に発言する人達に立場的にも評価的にも追い抜かれていきました。

そういったこともあり最近その考えを捨て、積極的に発言するようになりました。
何かをslackに投げると、誰かしらリアクションを返してくれます。
私が恐れていた、皆から無視されることは1度もありませんでした。

思っているよりもあなたの周囲の人は優しいです。
分からないことは聞いたら教えてくれますし、悩みをぶつけたら真剣に考えてくれます。
特に新人は自分から積極的に周囲とコミュニケーションをとるべきです。
例えば、話してみたい人をランチに誘うのはとても良いことだと思います。
周囲を怖がらず、積極的にコミュニケーションを行いましょう。

自分のことを真剣に考える

今まで20年以上、『なんとなく』で生きてきました。
必死に努力した体験もなく、 『なんとなく』その場を切り抜けるの連続でした。
しかし、その『なんとなく』はもう通用しなくなってきました。

自分の将来を良くするためには、自分が動くしかありません。
自分の特性を理解して、自分のことを真剣に考えて、それを行動に移してほしいです。

よく上司から当事者意識が不足しているというフィードバックを受けていました。
未経験という立場でも、あなたはプロとして雇われています。
その道のプロとして活躍していくため、自分に対しても業務に対しても当事者意識を持って取り組んでほしいです。

自分を責めない

これはメンタリストのDaigoさんが書かれていて、なるほどと思ったことです。
https://daigoblog.jp/notprocrastinate-myself/

失敗して怒られると、いつも「なんて自分はダメなやつなんだろう」と思っていました。
自分はダメなやつだからできないんだ、もう無理だ、といった感じにですね。
ただ、ブログにもあるように自分を責めることでその原因を考えなくなってしまいます。

そのため、まずは失敗した自分を許しましょう。
失敗した自分を肯定して、失敗を活かしてどのように自分を変えていくかが大事です。

失敗は直視しましょう。辛いけどね。私も失敗したことは考えたくありません。
でも、その原因を考えなければまた同じ失敗をしてしまいます。

最後に

何度でも何度でも立ち上がれ 諦めなければ終わりは始まりへ変わる

という歌詞がとても好きです。(ゾンビランドサガを見てね！)

辛いことも嫌なことも沢山ありますが、本当に努力した人だけが生き残れる世界です。
一緒に頑張りましょう。

■はじめに

とあるセミナーで「事実と解釈」というテーマを扱っていました。

その考え方がとてもためになったので、事実とはなにか？また解釈とは何か？を見極めることが物事の整理の手助けとなるよ、ということを伝えらればと思います。
余談ですが、エンジニアになりましたーという人の中にも「今研修中」という人や、「OJTで実業務やってまーす」という人もいると思います。
おそらくOJTが多いとは思いますが、業務が忙しいよーという人がこの記事を読んでる人の中にはいると思います。

上長から「これお願いね」と言われてよくわからん状況になって不安しかない人。
先輩の教え方が下手。
何をすればいいの？

いろいろ感じると思います。
そんな方はもしかしたら現在の状況整理ができていない可能性があります。

■事実と解釈とは？

事実とは実際に起こったことです。
当たり前ではありますが、事実とはそれ以上でもそれ以外のことでもありません。
プログラミングを例に挙げてみます。

例）コードを追記したら、システムが止まってしまいとてもあせっている。

上記の文章の「コードを追記したら、システムが止まってしまい」だけが事実にあたります。
では「とてもあせっている。」は何か？
これは事実ではなくその人の解釈になります。
では解釈とは何か？
解釈とは事実をもとに意味を、受け手の側から理解することです。
要するに「事実を受け、どう感じた」ということが解釈に当たります。

■おわりに

以上のことから、事実と解釈とはなにか？がわかってもらえたと思います。
人間なので、解釈に翻弄されがちですが、解釈はあくまで事実を受けてのリアクション、反応です。
そのため、いったん落ち着いて「事実はなんだ？」に注目してみると、問題解決がスムーズにいくと思います。

初めてはわからないことばかりです。
わからないことは質問をする。
質問を遠慮なくしていく。
でないと、わからないことだらけという問題がたまってしまいます。
一人でできないことは事実をうまくみつけて、先輩にその事実を伝えて問題解決を手伝ってもらうようにしましょう。

それでは、良いエンジニアライフを！

ハリーポッター「ダンブルドア軍団」に習うプログラマの組織化
https://qiita.com/kaizen_nagoya/items/85122fb88a294b81b9e8

ハリーポッターは11歳の誕生日に自分が魔法使いであることを知る。

経験則では１０歳で職業を自覚するとよい中央値だと理解している。
バイオリニスト、ピアニストは３歳から始める人たちがいる。歌舞伎でも３歳が初舞台の方々がいる。

家業を手伝っている人たちは、農業であろうが、商業であろうが、町工場であろうが、５歳から１０歳くらいから手伝っている。

音響、無線などで親に習って半田付けをする人たちは８歳から１０歳くらいから始めている。

プログラマだけ遅くていいという理由はない。

初就職が22歳、24歳では職業人としての自覚が必要な時に仕事をしていないかもしれない。

10歳が中央値であるとよい背景

言語は、何か一つ体系的にみについてから、次の言語をやるとよいと言われている。
その年齢が、８歳なのか、１０歳なのかは、社会的な環境によるかもしれない。

スマフォ、ゲーム、インタネットが発達してきた現在、母語の上達を、８歳から１０歳くらいで確保したら、英語をやるか、プログラミング言語をやるか、選択するとよい。

絶対に１０歳までに決断しなくてはいけない根拠はない。

プロのプログラマの要件

自分以外の人が使うプログラムを作る

当初は、自分のためのプログラムであっても、作ったプログラムを自分以外の人が使い、そのプログラムの使われる時間が自分以外が多ければ、自分以外の人た使うプログラムを作ったことになる

経済的な見返りがある

直接お金を対価としてもらう場合と、直接お金を対価としてもらわなくても、機材提供、場所提供、資料提供など、経済的に換算可能な見返りがある場合も含む。

社会的な評価が記録に残る

他人が使い、経済的な見返りがあるだけでは、不十分な点は、社会的な評価が記録に残るかどうかである。

他人が使い、経済的な見返りがあったとしても、その見返りの根拠が、自分が書いたプログラムなのか、自分が作ったものではないライブラリが使いたかったからなのかは、社会的評価が記録に残らないとわかりにくいことがある。

請負開発などで、営業の方がよいと、作ったプログラムがよくなくても、高額なお金を引っ張ってくることができ、結果として大儲けして、自分のやっていることの価値を見失うことがある。

社会的な評価が、記録に残ることの大切さである。

参考資料(reference)

小学生だった僕がプログラミングを覚えるまでにやったこと
https://qiita.com/hota1024/items/0fb623e7ce36758f48db

小学生から始めるBluemix始めの一歩（第一回）
https://qiita.com/mxm/items/63b33215900e3f49d04d

プログラミングとはなに？小学生に説明してみようと思う
https://qiita.com/ryoichiro001/items/09e6e0b7b50f0efc9b53

夏休みの自由研究、プログラム言語の歴史　(小学生向けプログラミング講談下書き、C言語:=仮面ライダー１号の場合)
https://qiita.com/Nimimal/items/29e8088c745e26ad7e05

小学校にプログラミング授業をお届けする
https://qiita.com/cocoakamen/items/4380d8151c7c44033907

小学生でも簡単⁉RaspberryPiとScratchを使ったラジコン
https://qiita.com/shion21/items/714576ee10a1fe6dacdd

私の研究者・Makerとしての半生　akita11
https://note.mu/akita11/n/n6f6857f54d17?fbclid=IwAR34In9UGsj2d1dYCKuxj-YocIT4DwiPBOsPHzsCX0YQ0FktyvUlTooozL0

個人的な記録(my record)

実家は印刷屋で、５歳には、家業を手伝い、活字の返却、紙を折る仕事、文章の校正などを行ってきた。
文章の校正が５歳でなぜできるかというと、当時は活字といって、１文字づつが鉛でできた文字を並べていた。活字が、横を向いていても、文章がわかる大人が読むと、横を向いていることに気がつかずに、意味をとってしまうことがある。５歳くらいの文章がわからない状態で読むと、横を向いている活字にすぐに気がつく。「の」の字は、横を向いていても「の」と読める代表格かもしれない。

プログラミングでは勝てないが、表示・言語処理では５歳からの知見で勝負できるかもと思い、表示・言語・通信関係を専門にするようにしている。

プログラマが知っているとよい色使い(安全色)
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

プログラミング言語教育のXYZ
https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4

言語処理100本ノックをdockerで。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2

文書履歴(document history)

ver. 0.01 初稿 20190409
ver. 0.02 個人的な記録追記 20190410
ver. 0.03 はてなブックマーク追加 20190415
ver. 0.04 参考資料追記 20190419
ver. 0.05 標題追記 20190422
ver. 0.06 参考資料追記 20190518

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

Twitter

https://twitter.com/CodeWisdom

Code

ここらへん
https://github.com/YumaInaura/YumaInaura/tree/master/api/lib

exe

./timeline.py CodeWisdom | FROM=en TO=ja TRANSLATE_JSON_KEY=full_text ../google-translate/translate-json.sh > log/codewisdom.js
cat log/codewisdom.js | JSON_TEXT_KEY=ja_translated_full_text PERIOD=」 ./markdown.py | p

作業時間

既に自作ライブラリなどが揃っていたので、30分ぐらい

Step

• Twitter のユーザータイムラインを json で得る
• json のまま google 翻訳する
• json を markdown 形式に変換する

以上。

それまでにやっていたこと

• Twitetr で自分の timeline から json を得る仕組みを用意していたので、あとは対象ユーザーを切り替えられるようにしただけで済んだ
• Google 翻訳で json を保ったままテキスト翻訳する仕組みを用意しておいて、環境変数で翻訳元言語と翻訳先原語を切り替えられるようにしておいていた
• json を markdown に変換する仕組みを用意していた
• それぞれのスクリプト等を役割の粒度毎に分離していたので、やりたいことがうまく出来た
• アイディアを形にするスピード感を今までで一番感じた瞬間だった

きっかけ

Twitterのかきぴさんと話していて。

名言レベルなら勝手に翻訳しても問題ないはず。(たぶん)
元のツイートも他所から引っ張ってきているであろうはずぐらいですし。

「コンピューターを操作するのはクールなことです。彼らは主張しません。彼らはすべてを覚えていて、ビールをすべて飲んでいるわけではありません。」

• ポール・リーリー

2018-07-27 13:34:01 UTC

"ソフトウェア開発者として、私は作家、音楽家、そして映画製作者たちを嫉妬しています。ソフトウェアとは異なり、彼らが何かを創り出すとき、それは永遠に行われます、" - Moxie Marlinspike

2018-07-28 12:37:01 UTC

「日曜日の朝のようにプログラミングは簡単ではありません。静かな詩です。」

• ワセム・ラティフ

2018-07-29 12:37:00 UTC

「実際にそれらを必要としているときには、常にものを実装し、あなたがそれらを必要としていると予見しているときには決して実装しないでください。」

• ロンジェフリーズ

2018-07-29 16:29:01 UTC

「誰かにプログラムを与えなさい、あなたは一日それらをいらいらさせます；彼らにプログラムする方法を彼らに教えなさい、あなたは一生の間彼らを不満にさせます。」

• David Leinweber

2018-07-30 13:34:01 UTC

「穏やかに、親切に、そしてあなたの仲間を寛容にしなさい。あなたが尊重する人々からの尊敬は本当に固執する唯一の報酬です」

• ラスティラッセル

2018-07-30 17:00:22 UTC

「1.簡単に始めましょう。

それを働かせる。
それから、複雑さを加えなさい。」
- @TomBredemeier

2018-07-31 12:37:00 UTC

"勤勉であれば、何かをゆっくり動かすことが可能です。" - Tom Duff

2018-07-31 13:34:00 UTC

「プログラミングはアルゴリズム設計の技術であり、誤ったコードをデバッグする技術です。」

• エレンウルマン

2018-07-31 17:00:28 UTC

「彼らはもうバニーのようなバグを作りません。」

• Olav Mjelde

2018-08-01 12:37:00 UTC

「プログラミング：アイデアが現実のものに変わるとき」

• Maciej Kaczmarek

2018-08-01 13:34:01 UTC

「コード行でプログラミングの進捗状況を測定することは、航空機の建物の進捗状況を重量で測定することに似ています。」

• ビルゲイツ

2018-08-01 17:00:14 UTC

「日常生活はプログラミングのようです。あなたが何かを好きなら、あなたはそれに美しさを入れることができます。」

• ドナルド・クヌース

2018-08-02 12:37:02 UTC

「テストは失敗につながり、失敗は理解につながります。」

• バートルタン

2018-08-02 13:34:00 UTC

「プログラムを単純に見せる言語ではありません。言語をシンプルに見せるのはプログラマーです！ - - Uncle Bob

2018-08-02 17:19:16 UTC

「優れた仕様は、どのプログラミングツールやテクニックよりもはるかに優れたプログラマの生産性を常に向上させます。」

• ミルトブライス

2018-08-03 12:37:00 UTC

「6ヶ月以上見ていない自分自身のコードは、他の誰かによって書かれているかもしれません。イーグソンの法則

2018-08-03 13:34:02 UTC

人々のようなプログラムは年をとる。老化を防ぐことはできませんが、その原因を理解し、その影響を限定し、そして一部のダメージを元に戻すことはできます。 - マリオフスコ

2018-08-03 17:00:14 UTC

「今日の仕事を今日終わらせることができても、明日の仕事を明日に終わらせることができないようなやり方でそれを行うのであれば、負けとなります」

• Martin Fowler

2018-08-04 12:37:00 UTC

「サーバーレスは、JavaScriptがJavaに対応するのと同じようにサーバーに対応します。」

• デイブ・チェイニー

2018-08-04 16:29:01 UTC

「時に問題は、問題が何であるかを発見することです。」

• ゴードングレッグ

2018-08-05 16:29:01 UTC

「あなたのコードをコメントすることはあなたの浴室を掃除することに似ています - あなたはそれをしたくないです、しかしそれは本当にあなたとあなたのゲストのためにより快適な経験を作り出します。」

• ライアンキャンベル

2018-08-06 12:37:01 UTC

「単純なことは愚かなことではありません。そうだと思っているのです」

• Paul Krugman

2018-08-06 13:34:01 UTC

「カプセル化は重要ですが、それが重要な理由はより重要です。カプセル化は、私たちのコードを推論するのに役立ちます。」

• Michael Feathers

2018-08-06 17:00:04 UTC

「何かがうまくいかないときに感じる驚きの量は、実行されているコードに対する信頼と信仰の量に正比例します。」

• 実用的なプログラマー

2018-08-07 12:37:00 UTC

「すべてのプログラムには2つの目的があります。それが書かれた目的とそうでない目的です。」

• アランJ.ペルリス

2018-08-07 13:34:01 UTC

「ドライバーを持っているプログラマーやプログラムを持っているハードウェアエンジニアよりも恐ろしいのは、1組のワイヤーカッターとrootパスワードを持っているユーザーだけだ」

。 - エリザベスズウィッキー

2018-08-07 17:00:29 UTC

「コンピューターを操作するのはクールなことです。彼らは主張しません。彼らはすべてを覚えていて、ビールをすべて飲んでいるわけではありません。」

• ポール・リーリー

2018-08-08 12:37:00 UTC

「もしあなたが積極的にリスクを攻撃しなければ、そのリスクはあなたを積極的に攻撃するでしょう。」

• トムギルブ

2018-08-08 13:34:00 UTC

"良いソフトウェアの機能は、複雑なものを単純に見せることです。" - Grady Booch

2018-08-08 17:00:35 UTC

「コンピュータに関する良い知らせは、彼らがあなたに彼らに指示することをするということです。悪い知らせは彼らがあなたに彼らにそう言うように言うということです。」

• テッドネルソン

2018-08-09 12:37:01 UTC

「作成できないもの、理解できない」

• リチャードファインマン

2018-08-09 13:34:00 UTC

"コードと恋に落ちることは、問題解決と恋に落ちることと永遠に進行中の会話の一部であることを意味します。" - Kathryn Barrett

2018-08-09 17:00:33 UTC

「ときどき何かを放置して一時停止した方が良い場合があります。これはプログラミングに非常に当てはまります。」

• ジョイスウィーラー

2018-08-10 12:37:00 UTC

「時に問題は、問題が何であるかを発見することです。」

• ゴードングレッグ

2018-08-10 13:34:01 UTC

「人々は変化に抵抗する大きな傾向を持っています。彼らは、「私たちはいつもこれをやり遂げました」

と言うのが好きです。グレースホッパー

2018-08-10 17:00:02 UTC

「プログラム構築の本質の大部分は、実際には仕様のデバッグです。」

• Fred Brooks

2018-08-11 12:37:01 UTC

「時には、エレガントな実装は単なる機能です。方法ではありません。クラスではありません。フレームワークではありません。単なる機能です。」

• John Carmack

2018-08-11 16:29:02 UTC

「コーディングを早くすればするほど、プログラムの実行時間は長くなります。」

• ロイ・カールソン

2018-08-12 12:37:01 UTC

「だれでもコンピュータが理解できるコードを書くことができます。優れたプログラマは人間が理解できるコードを書くのです」

。 - マーティンファウラー

2018-08-12 16:29:01 UTC

「世界で最も安全なコードは書かれていないコードです。」

• コリンパーシバル

2018-08-13 12:37:01 UTC

「最初にそれをし、次にそれを正しくし、そしてそれをより良くする。」

• アディ・オスマニ

2018-08-13 13:34:01 UTC

「唯一の真の方法で。「スパゲッティコード」

のオブジェクト指向バージョンは、もちろん「ラザニアコード」です（レイヤーが多すぎます）。 - ロベルトウォルトマン

2018-08-13 17:00:18 UTC

「あたかも私たちがこれまで理解しなければならない唯一の人物であるかのようにソフトウェアを書くことは、起こりうる最大の過ちであり誤った仮定の1つです。」

• カロリーナ・シュチュール

2018-08-14 12:37:00 UTC

科学で聞くべき最もエキサイティングなフレーズ、新しい発見を告げるものは「ユーリカ」

ではありません。しかし、それは面白いです... - Isaac Asimov

2018-08-14 13:34:01 UTC

「大工では2回測定して1回切断します。ソフトウェア開発では、時間がなくなるまで測定したり切断したりすることはありません。」

• アダムモース

2018-08-14 17:00:27 UTC

「進化するシステムは、それを減らすための作業が行われない限り、その複雑さを増します。」

• メイル・リーマン

2018-08-15 12:37:00 UTC

「単純さとは、自明性を減じて意味のあるものを追加することです。」

• ジョン前田

2018-08-15 13:34:01 UTC

「イーグルソンの法則：あなたが6ヶ月以上見ていないあなた自身のどんなコードも同様に他の誰かによって書かれたかもしれません。」

• Alan Eagleson

2018-08-15 17:00:30 UTC

「恥ずかしがり屋のコード - 他のモジュールに不要なものを明らかにしない、そして他のモジュールの実装に依存しないモジュールを書く」

。 - デイブトーマス

2018-08-16 12:37:00 UTC

「プログラマーの問題は、遅すぎるまでプログラマーの行動を見分けることができないことです。」

• Seymour Cray

2018-08-16 13:34:01 UTC

「1人のプログラマが1か月でできること、2人のプログラマが2か月でできること」

• フレッドブルックス

2018-08-16 17:00:00 UTC

Javaは、CarがCarpetに対してJavaScriptとするものです。 - - クリスハイルマン

2018-08-17 12:37:00 UTC

「平均的なユーザーは、（1）正常に動作し、（2）高速である限り、何が起こるかについて気にする必要はありません。」

• ダニエルJ.バーンスタイン

2018-08-17 13:34:00 UTC

「あなたが知っているすべての素晴らしい開発者は、実際に解決するまでは解決できなかった問題を解決することによってそこにたどり着きました。」

• パトリック・マッケンジー

2018-08-17 17:00:06 UTC

「複雑さの主な原因は、ソフトウェアベンダがユーザーが望むほとんどすべての機能を無差別に採用していることです。」

• Niklaus Wirth

2018-08-18 12:37:00 UTC

"ブール値についての最も良いことはあなたが間違っている場合でも、あなたは少しだけオフになっています。" - 匿名

2018-08-18 16:29:01 UTC

「コーディングの数週間で、計画の時間を節約できます。」

• 道の

2018-08-19 12:37:00 UTC

「新技術があなたの上にロールオーバーしたら、あなたがsteamrollerの一部ではないならあなたは道の一部です。」

• Stewartブランド

2018-08-19 16:29:00 UTC

「月曜日のコードのデバッグに残りの週を費やすのではなく、月曜日にベッドにいるほうがよい場合があります」

• クリストファー・トンプソン

2018-08-20 12:37:00 UTC

「そして、コンピュータのプログラミングはとても魅力的でした。あなたはあなた自身の小さな宇宙を作り、そしてそれはあなたがそれにそうするようにあなたが言うのを行います。」

• ヴィントサーフ

2018-08-20 17:00:21 UTC

「貧弱なテストの効率を向上させるよりも、テストの有効性を最初に向上させる方がはるかに優れています。カオスを自動化することで、より速いカオスが得られます。」

• マーク・フュースター

2018-08-21 13:34:01 UTC

「コンピュータ言語のデザインは公園を散歩するようなものです。ジュラシックパーク、それです。」

• ラリーウォール

2018-08-22 12:37:00 UTC

「良いプログラマーは、一方通行の道を渡る前に常に両方向を見ている人です。」

• ダグリンダー

2018-08-22 13:34:00 UTC

「文書化されていないフレームワークは、ガイドなしの迂回路のようなものです。」

• @gpottepalem

2018-08-23 12:37:00 UTC

「あなたはプロジェクトを持つことができます：

time予定通りに完了
budget予算で完了
✅正しく完了

2つ選んでください。」
- 不明

2018-08-23 13:34:00 UTC

「削除されたコードはデバッグされたコードです。」

• ジェフ・シッケル

2018-08-23 17:00:32 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻💌

2018-08-24 12:37:01 UTC

「単純さとは、自明性を減じて意味のあるものを追加することです。」

• ジョン前田

2018-08-24 17:00:06 UTC

配列インデックスは0と1のどちらから始めるべきですか。私の0.5の妥協案は、適切な考慮なしには拒絶されました。」

• Stan Kelly-Bootle

2018-08-25 12:37:00 UTC

「効率的な開発の鍵は、「おもしろい新たな過ちを犯す」

ことです。」 - トムラブ

2018-08-25 16:29:01 UTC

「ドキュメンテーションはあなたがあなたの将来の自己に書くラブレターです。」

• ダミアンコンウェイ💌

2018-08-26 12:37:00 UTC

「水の上を歩くことと仕様からソフトウェアを開発することは、両方が凍結されていれば簡単です。」

• エドワードVベラード

2018-08-26 16:29:01 UTC

「準備ができている、発射する、狙う：ソフトウェア開発への素早いアプローチ。準備ができて、狙う、狙う、目的、狙い：ソフトウェア開発への遅いアプローチ。」

• 匿名

2018-08-27 12:37:01 UTC

「プログラミングはあなたが知っていることではありません。それはあなたが理解できることについてです。」

• クリスパイン

2018-08-27 13:34:03 UTC

プログラマーは芸術家だとは思わないかもしれませんが、プログラミングは非常に創造的な職業です。それは論理に基づいた創造性です。」

• John Romero

2018-08-28 13:34:01 UTC

「トリックは、あなたが望む問題ではなく、あなたが持つ問題を解決することです。」

• ブラム・コーエン

2018-08-28 17:00:53 UTC

「他の誰かがあなたのコードを読むことを意図していなくても、誰かがあなたのコードを見つめてそれが何をするのか理解しなければならない可能性はまだ非常にあります。 " - Raymond Chen

2018-08-29 12:37:00 UTC

「プログラミングはタイプすることではなく、考えることです。」

• リッチヒッキー

2018-08-29 13:34:00 UTC

「バグが表面化するまでの時間が長いほど、見つけるのは難しくなります。」

• Roedy Green

2018-08-30 12:37:01 UTC

「ピザのようなプログラミング言語は、大きすぎる、小さすぎるという2つのサイズしかありません。」

• リチャード・パティス

2018-08-30 13:34:01 UTC

「一般的にプログラムは、何か言いたいことがある場合を除き、何も言わないでください。」

• Kernighan and Plauger

2018-08-30 17:00:06 UTC

「分析エンジンは、ジャカード織機が花と葉を織るように、代数パターンを織ります。」

• Ada Lovelace

2018-08-31 13:34:00 UTC

「アマチュアソフトウェアエンジニアは常に魔法を求めています。」

• Grady Booch

2018-09-01 16:29:00 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻

2018-09-03 12:37:01 UTC

「あなたの問題は他人の解決策です。あなたの解決策は彼らの問題になるでしょう。」

• 道の

2018-09-03 13:34:01 UTC

「複雑さの主な原因は、ソフトウェアベンダがユーザーが望むほとんどすべての機能を無差別に採用していることです。」

• Niklaus Wirth

2018-09-03 17:00:24 UTC

「プログラムがよりきれいでより良いものであればあるほど、それはより速く走るでしょう。そうでない場合は、早くするのは簡単でしょう。」

• Joshua Bloch

2018-09-04 12:37:01 UTC

"騒音に気を取られないでください。" - 匿名

2018-09-05 12:37:00 UTC

「人間は変化に対してアレルギーがあります。私たちはいつもそれをやり遂げようとしています。壁には反時計回りに走る時計があるのです」

• グレースホッパー

2018-09-05 13:34:01 UTC

「プログラミングはピンボールのようなものです。それをすることへの報酬はそれをまたやる機会です。」

• 道の

2018-09-06 12:37:01 UTC

「解決すると問題は単純になります」

• @RahuIRavindran

2018-09-07 12:37:01 UTC

「ただし、他の人のモジュールで作業している場合は、その規則を使用したほうがよいでしょう。それは他人と働くことを学ぶことの一部です。」

• Ray Ozzie

2018-09-07 17:00:21 UTC

「質問を定式化するのに役立つ場合は、他のアクティビティと比較すると便利です。回答を正当化するために使用すると危険です。」

• マーティンファウラー

2018-09-08 16:29:01 UTC

「最も安く、最も速く、そして最も信頼できるコンポーネントは、そこにはないものです。」

• ゴードンベル

2018-09-09 12:37:00 UTC

「入港船は安全ですが、それは船の目的ではありません。海に出港して新しいことをする」

• Grace Hopper

2018-09-09 16:29:00 UTC

「自分がテストするコードと同じくらい自分がコーディングするテストに自信がある必要があります。」

• @xgouchet

2018-09-10 17:00:12 UTC

「[コードの再利用]はかなりの量のコーディングを節約しますが、もっと重要なのは一貫性です。」

• KernighanとPlauger

2018-09-11 13:34:00 UTC

「新しいプログラミング言語を学ぶ唯一の方法は、その中にプログラムを書くことです。」

• デニス・リッチー

2018-09-11 17:00:40 UTC

「デバッグは、あなたが殺人者でもある犯罪映画の探偵のようなものです。」

• Filipe Fortes

2018-09-12 12:37:00 UTC

「それで、あなたが速く行きたいのなら、あなたがすぐにやりたいのなら、あなたがあなたのコードを書きやすくしたいのなら、それを読みやすくしてください。」

• Robert C. Martin

2018-09-12 13:34:00 UTC

私が問題に取り組んでいるとき、私は美について決して考えません。私は問題を解決する方法だけを考えます。しかし、私が終わったとき、もし解決策が美しくなければ、それは間違っていることを私は知っています。」

• R. Buckminster Fuller

2018-09-13 12:37:01 UTC

「ハムはハムであるのと同様に、JavaはJavaScriptである」

• 弾力のあるWebデザイン、Jeremy Keith

2018-09-13 13:34:00 UTC

幸せProgrammersDayみんな！ 🎉💻📚

2018-09-13 16:01:59 UTC

「あなたが知っているすべての素晴らしい開発者は、実際に解決するまでは解決できなかった問題を解決することによってそこにたどり着きました。」

• パトリック・マッケンジー

2018-09-13 17:01:09 UTC

「プログラム構築の本質の大部分は、実際には仕様のデバッグです。」

• Fred Brooks

2018-09-14 12:37:01 UTC

Bram Cohen（@bramcohen） - BitTorrentのコンピュータープログラマー兼発明者。

2018-09-14 17:00:05 UTC

配列インデックスは0と1のどちらから始めるべきですか。私の0.5の妥協案は、適切な考慮なしには拒絶されました。」

• Stan Kelly-Bootle

2018-09-15 12:37:00 UTC

「正しい答えを得るための最善の方法は、質問をすることではなく、間違った答えを投稿することです。」

• カニンガムの法則

2018-09-16 16:29:01 UTC

「プロトタイプの価値は、コード自体ではなく、あなたに与える教育にあります。」

• アランクーパー

2018-09-17 12:37:00 UTC

「2度目にコードのリファクタリングを延期するのは延期になりました。レガシーになりました。あなたのCraftに立ち向かおう！」

• @victorrentea

2018-09-18 13:34:00 UTC

「コンピュータサイエンスには、他のレベルの間接参照を使用しても解決できない問題はありません。しかし、それは通常別の問題を引き起こします。」

• David Wheeler

2018-09-18 17:01:09 UTC

「機械の表面の下で、プログラムは動きます。努力がなければ、それは拡大して収縮します。非常に調和して、電子は散乱して再編成します。モニターの形は水面の波紋にすぎません。エッセンスは目に見えないように下にとどまっています。」

• プログラミングの本、マスター元 - 馬。

2018-09-19 12:37:01 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻

2018-09-19 17:00:02 UTC

「私は締め切りが大好きです。私は飛んでいくうちに、彼らが作る素晴らしいサウンドが好きです。」

• ダグラス・アダムス

2018-09-20 12:37:00 UTC

「各プログラムに1つのことをうまくやらせる。新しい仕事をするには、新しい機能を追加して古いプログラムを複雑にするのではなく、新しく作成してください。」

• Eric S. Raymond

2018-09-20 17:00:08 UTC

「プログラマーの問題は、遅すぎるまでプログラマーの行動を見分けることができないことです。」

• Seymour Cray

2018-09-21 12:37:01 UTC

「80％のコンピュータサイエンスは探偵の仕事です。何が起こったのか、起きなかったのか、またその理由を調べるために調査する必要があります。」

• @TomBredemeier

2018-09-21 17:00:32 UTC

「学ぶ方法を知っています。それから、学びたいです。」

• キャサリン・ジョンソン

2018-09-22 12:37:00 UTC

「6ヶ月以上見ていない自分自身のコードは、他の誰かによって書かれた可能性があります。」

• イーグソンの法則

2018-09-22 16:29:00 UTC

「コードはパズルです。他のゲームと同じように、ゲームです。」

• アランチューリング

2018-09-23 12:37:00 UTC

「ソフトウェアの複雑さは、1つのことに2つのことをさせようとすることに起因します。」

• ライアンシンガー

2018-09-23 16:29:00 UTC

「あなたが持つことができる最高のプログラミングスキルの1つは、しばらくの間立ち去るべき時を知ることです。」

• オスカーゴッドソン

2018-09-24 12:37:00 UTC

「だれでも、コンピュータが理解できるコードを書くことができます。優れたプログラマーは、人間が理解できるコードを作成します。」

• Martin Fowler

2018-09-24 13:34:02 UTC

「ソフトウェア開発者として、あなたはあなた自身の最悪の敵です。すぐに気づくほど、あなたはより良い恩恵を受けることになります。」

• Jeff Atwood

2018-09-24 17:00:42 UTC

「殺人の謎を解明しても大丈夫ですが、コードを解明する必要はありません。それを読むことができるはずです。」

• Steve McConnell

2018-09-25 12:37:00 UTC

「プログラミング：アイデアが現実のものに変わるとき」

• Maciej Kaczmarek

2018-09-25 17:00:46 UTC

「あたかも私たちがこれまで理解しなければならない唯一の人物であるかのようにソフトウェアを書くことは、起こりうる最大の過ちであり誤った仮定の1つです。」

• カロリーナ・シュチュール

2018-09-26 12:37:01 UTC

「誰かにプログラムを与えなさい、あなたは一日それらをいらいらさせます；彼らにプログラムする方法を彼らに教えなさい、あなたは一生の間彼らを不満にさせます。」

• David Leinweber

2018-09-26 13:34:00 UTC

「何かを単純化することができるという潜在的な疑念は、やりがいのある課題の世界で最も豊富な原因です。」

• Edsger Dijkstra

2018-09-26 17:00:36 UTC

「まず、問題を解決してから、コードを書いてください。」

• ジョンジョンソン

2018-09-27 12:37:01 UTC

「恥ずかしがり屋のコード - 他のモジュールに不要なものを明らかにしない、そして他のモジュールの実装に依存しないモジュールを書く」

。 - デイブトーマス

2018-09-27 13:34:01 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻💌

2018-09-28 12:37:01 UTC

「ユーザーインターフェースは非常に単純でなければならないので、緊急事態の初心者は10秒以内にそれを理解することができます。」

• テッドネルソン

2018-09-28 13:34:00 UTC

「プログラムの最も重要な特性は、プログラムがそのユーザーの意図を達成するかどうかです。」

• C.A.R.ホアレ

2018-09-28 17:00:42 UTC

「今日の仕事を今日終わらせることができても、明日の仕事を明日に終わらせることができないようなやり方でそれを行うのであれば、あなたは失うことになります。」

• Martin Fowler氏、リファクタリング：既存コードの設計の改善

2018-09-29 12:37:00 UTC

「複雑さは目標ではありません。複雑なシステムのエンジニアとして記憶されたくないのです。」

• デビッドパルナス

2018-09-30 12:37:01 UTC

「プログラムの完成度が90％を下回ることはなく、95％を超えることはありません。」

• Terry Baker

2018-09-30 16:29:00 UTC

「すべてのプログラムには2つの目的があります。それが書かれた目的とそうでない目的です。」

• アランJ.ペルリス

2018-10-01 12:37:00 UTC

「[プログラミングは]夕食を計画するのと同じです。必要なときに準備が整うように、事前に計画を立て、すべてのスケジュールを設定する必要があります。コンピュータプログラミングでは女性は当然のことです。」

• Grace Hopper

2018-10-01 13:34:01 UTC

"賢明な試行錯誤は完璧な知性の計画よりも優れています。" - David Kelley

2018-10-01 17:00:49 UTC

コンピュータサイエンスは、抽象化の科学であり、問題に対する正しいモデルを作成し、それを解決するための適切な機械化可能な技法を考案します。 - アルフレッド・アホ

2018-10-02 12:37:01 UTC

「未来を予測する最良の方法はそれを実行することです。」

• アランケイ

2018-10-02 13:34:00 UTC

「コードはユーモアのようなものです。説明しなければならない場合、それは悪いことです。」

• Cory House

2018-10-03 12:37:01 UTC

「関数は1つのことをするべきです。それらはそれをうまくやるべきです。彼らはそれをするべきです」

• ロバートC.マーティン

2018-10-03 13:34:00 UTC

「エラーのないプログラムを書くには2つの方法があります。3つ目だけが動作します。」

• Alan Perlis

2018-10-03 17:00:17 UTC

「何かがうまくいかないときに感じる驚きの量は、実行されているコードに対する信頼と信仰の量に直接比例します。」

• The Pragmatic Programmer

2018-10-04 12:37:01 UTC

「現在提供されている機能の90％は、提供されていない100％より優れています。」

• Brian W. Kernighan＆amp; A P. J.プラウガー

2018-10-05 12:37:01 UTC

「プログラマの観点から見ると、ユーザーは読み取り要求を発行したときに入力する周辺機器です。」

• P. Williams

2018-10-05 13:34:01 UTC

「それは私のマシン上で動作します。」

• 匿名

2018-10-05 17:00:22 UTC

「私はまだ問題を見ていませんが、正しい方法で見ても、それ以上複雑になることはありませんでした。」

• Poul Anderson

2018-10-06 12:37:00 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💌

2018-10-07 12:37:00 UTC

「プログラミングは他の種類の問題解決のようなものです。正しい質問をしてください。解決策は簡単です。コードが非常に複雑な場合は、間違った質問をする可能性があります。」

• @jadenkore

2018-10-08 12:37:01 UTC

「オブジェクトは処理の抽象化です。スレッドはスケジュールの抽象化です。」

• ジェームズ・O・コプリエン

2018-10-09 12:37:00 UTC

「プログラミングは芸術であり、他の芸術と同様に、繰り返し練習することで習得できます。」

• @kapitanjakc

2018-10-09 13:34:00 UTC

ハッピーAdaLovelaceDay womeninSTEM＃ALD18 WomenInTech

「私が理解できるように、私の理解はほんのごくわずかなほんのごく一部に過ぎません。」

2018-10-09 13:51:18 UTC

「コンピュータサイエンスのほとんどの論文は、著者が他の誰かがすでに知っていることをどのように学んだかを説明しています。」

• ピーターランディン

2018-10-10 12:37:01 UTC

「コンピュータサイエンスのほとんどの論文は、著者が他の誰かがすでに知っていることをどのように学んだかを説明しています。」

• ピーターランディン

2018-10-10 12:37:01 UTC

「規格があなたの目の前に崖を提供しているからといって、必ずしもそれから飛び出す必要はありません。」

• ノーマンダイヤモンド

2018-10-10 17:00:41 UTC

「新しいプログラミング言語を学ぶ唯一の方法は、その中にプログラムを書くことです。」

• デニス・リッチー

2018-10-11 12:37:00 UTC

「うまくいかなければ、どれだけ速く動かなくてもかまいません」

• ミックラベラ

2018-10-11 17:00:27 UTC

「アマチュアソフトウェアエンジニアは常に魔法を求めています。」

• Grady Booch

2018-10-12 12:37:01 UTC

「興味があります。広く読んでください。新しいことを試す。私は人々が知性と呼ぶものの多くが好奇心に帰着すると思う」

• Aaron Swartz

2018-10-12 17:00:02 UTC

「プログラミングは、最小で最小のものも同様に重要であることを世界に教えるための別の方法です。コードがセミコロンなしで実行されないときのように」

• @gunnnpowder

2018-10-13 12:37:00 UTC

「言語は、私たちの考えを変えるか、しないかを決定します。」

• エリック・ナグム

2018-10-13 16:29:01 UTC

「トリックは、あなたが望む問題ではなく、あなたが持つ問題を解決することです。」

• ブラム・コーエン

2018-10-14 12:37:00 UTC

「プログラミングでは、難しい部分は問題を解決するのではなく、どの問題を解決するかを決定することです。」

• ポール・グラハム

2018-10-15 13:34:00 UTC

プログラマーは芸術家だとは思わないかもしれませんが、プログラミングは非常に創造的な職業です。それは論理に基づいた創造性です。」

• John Romero

2018-10-16 12:37:00 UTC

「プログラムは詩のようなものです。書かないと詩を書くことはできません。」

• E. W.ダイクストラ

2018-10-16 13:34:01 UTC

「6ヶ月以上見ていない自分自身のコードは、他の誰かによって書かれた可能性があります。」

• イーグソンの法則

2018-10-17 13:34:01 UTC

「コードが実行されるまで、すべて話題になります」

• ワードカニンガム

2018-10-17 17:01:29 UTC

「コーディングを早くすればするほど、プログラムの実行時間は長くなります。」

• ロイ・カールソン

2018-10-18 12:37:01 UTC

「コード行でプログラミングの進捗状況を測定することは、航空機の建物の進捗状況を重量で測定することに似ています。」

• ビルゲイツ

2018-10-18 17:01:07 UTC

「まったく構築されるべきではない何かを効率的に構築することよりも非生産的なものはありません。」

• ミルトブライス

2018-10-19 12:37:01 UTC

「世界で最も安全なコードは書かれていないコードです。」

• コリンパーシバル

2018-10-19 13:34:00 UTC

「プログラミングはタイプすることではなく、考えることです。」

• リッチヒッキー

2018-10-21 12:37:00 UTC

プログラミングはあなたが知っていることではありません。それはあなたが理解できることについてのものです。」

• クリスパイン

2018-10-22 12:37:01 UTC

「進化するシステムは、それを減らすための作業が行われない限り、その複雑さを増します。」

• メイル・リーマン

2018-10-22 13:34:00 UTC

「プログラミングの技術は共感から始まり、フォーマットや言語、ツール、アルゴリズム、データ構造ではありません。」

• ケントベック

2018-10-22 17:00:01 UTC

「JavaScriptの強みはあなたが何でもできることです。弱みはあなたがすることです。」

• レッグブレイスウェイト

2018-10-23 12:37:00 UTC

「それがソフトウェアのデザインに関する本ではないことを確認するために、定期的に表紙をちらっと見ずに魔法の原則に関する本を読むのは難しいです。」

• Bruce Tognazzini

2018-10-23 17:00:49 UTC

「プログラミングを学ぶことは、タッチタイプを学ぶことが詩を書くことと関係があることよりも、対話型ソフトウェアを設計することと関係がありません」

• Ted Nelson

2018-10-24 12:37:01 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻

2018-10-24 13:34:02 UTC

「それで、あなたが速く行きたいのなら、あなたがすぐにやりたいのなら、あなたがあなたのコードを書きやすくしたいのなら、それを読みやすくしてください。」

• Robert C. Martin

2018-10-25 12:37:01 UTC

「良いアイデアを持つための次善の策は、ユーザーからの良いアイデアを認識することです。時には後者のほうが良いのです。」

• エリック・レイモンド

2018-10-25 13:34:00 UTC

「デバッグがソフトウェアのバグを取り除くプロセスであるならば、プログラミングはそれらを入れるプロセスでなければなりません。」

• Edsger Dijkstra

2018-10-25 17:00:46 UTC

「最も安く、最も速く、そして最も信頼できるコンポーネントは、そこにはないものです。」

• ゴードンベル

2018-10-26 12:37:00 UTC

"コンピューターは指示に従うのは得意ですが、頭を読むのは得意ではありません。" - Donald Knuth

2018-10-26 17:00:07 UTC

「プログラマーにXを実行するためのライブラリがすでにあることを伝えることは、ソングライターにすでに愛についての曲があることを伝えることと同じです。」

• ピートコーデル

2018-10-27 12:37:00 UTC

「世界で最も安全なコードは書かれていないコードです。」

• コリンパーシバル

2018-10-27 16:29:00 UTC

「効率的な開発の鍵は、興味深い新たな間違いを犯すことです。」

• トムラブ

2018-10-28 13:37:00 UTC

「あなたのコードを詩のように扱い、それを最低限のものにする。」

• ILYO

2018-10-29 13:37:01 UTC

「私にとってプログラミングは重要な実践的な芸術以上のものです。知識の基盤における巨大な仕事でもあります。」

• グレースホッパー

2018-10-29 14:34:00 UTC

「あなたの仕事は未来を予見することではなく、それを可能にすることです。」

• アントワーヌドサンテグジュペリ

2018-10-29 18:00:37 UTC

「最初にそれをし、次にそれを正しくし、そしてそれをより良くする。」

• アディ・オスマニ

2018-10-30 13:37:00 UTC

"問題を文書化しないで、それを修正してください。" - AtliBjörgvinOddsson

2018-10-30 14:34:01 UTC

「プログラミングはピンボールのようなものです。それをすることへの報酬はそれをまたやる機会です。」

• 道の

2018-10-31 13:37:00 UTC

「単純さは信頼性のための必要条件です」

• Edsger W. Dijkstra

2018-10-31 14:34:03 UTC

「理想主義的であることは本当にあなたがあなたの進路に置かれた多くの障害のいくつかを克服するのを助けます。」

• アンディ・ハーツフェルト

2018-11-01 13:37:02 UTC

「時間が示すように、私の頭脳は単なる致命的なものではありません。」

• アダラブレース

2018-11-01 18:00:14 UTC

「唯一の真の方法で。「スパゲッティコード」

のオブジェクト指向バージョンは、もちろん「ラザニアコード」です（レイヤーが多すぎます）。 - ロベルトウォルトマン

2018-11-02 13:37:02 UTC

「時に問題は、問題が何であるかを発見することです。」

• ゴードングレッグ

2018-11-02 18:00:17 UTC

「今日の仕事を今日終わらせることができても、明日の仕事を明日に終わらせることができないようなやり方でそれを行うのであれば、負けとなります」

• Martin Fowler

2018-11-04 13:37:00 UTC

「月曜日のコードのデバッグに残りの週を費やすのではなく、月曜日にベッドにいるほうがよい場合があります」

• クリストファー・トンプソン

2018-11-05 13:37:00 UTC

「バグを修正せずに書き直してください。」

• 匿名

2018-11-05 18:01:02 UTC

「あたかも私たちがこれまで理解しなければならない唯一の人物であるかのようにソフトウェアを書くことは、起こりうる最大の過ちであり誤った仮定の1つです。」

• カロリーナ・シュチュール

2018-11-06 13:37:02 UTC

「効率的な開発の鍵は、「おもしろい新たな過ちを犯すこと」

です。 - トムラブ

2018-11-06 18:00:21 UTC

"あなたはプロジェクトを持つことができます。時間通りに完了。予算通りに完了。正しく完了 - 2つ選んでください。" - 道の

2018-11-07 13:37:00 UTC

「コンピュータの歴史の中で誰も完璧なソフトウェアを書いたことはありません。あなたが最初になることはまずありません」

。 - アンディハント

2018-11-07 14:34:02 UTC

「私の最も生産的な日の1つは、1000行のコードを捨てることでした。」

• ケントンプソン

2018-11-08 13:37:01 UTC

「プログラムの最も重要な特性は、プログラムがそのユーザーの意図を達成するかどうかです。」

• C.A.R.ホアレ

2018-11-08 14:34:01 UTC

"シンプルさは信頼性のための前提条件です。" - Edsger W. Dijkstra

2018-11-09 13:37:01 UTC

「あなたが知っているすべての素晴らしい開発者は、実際に解決するまでは解決できなかった問題を解決することによってそこにたどり着きました。」

• パトリック・マッケンジー

2018-11-09 14:34:00 UTC

「プログラミングは一度に一つのことをすることの芸術です」

• Michael Feathers

2018-11-10 13:37:00 UTC

「だれでも、コンピュータが理解できるコードを書くことができます。優れたプログラマーは、人間が理解できるコードを作成します。」

• Martin Fowler

2018-11-11 13:37:01 UTC

「結局、開発階層のどこにいても、コーディングを続けてください。それがあなたにとって最も価値のある場所です。」

• 開発者コード

2018-11-11 17:29:00 UTC

「ソフトウェアの複雑さは、1つのことに2つのことをさせようとすることに起因します。」

• ライアンシンガー

2018-11-12 13:37:01 UTC

「プログラミング：アイデアが現実のものに変わるとき」

• Maciej Kaczmarek

2018-11-12 18:00:18 UTC

「コンピュータに関する良い知らせは、彼らがあなたに彼らに指示することをするということです。悪い知らせは彼らがあなたに彼らにそう言うように言うということです。」

• テッドネルソン

2018-11-13 13:37:01 UTC

「誰かにプログラムを与えなさい、あなたは一日それらをいらいらさせます；彼らにプログラムする方法を彼らに教えなさい、あなたは一生の間彼らを不満にさせます。」

• David Leinweber

2018-11-13 14:34:00 UTC

「プログラミングはあなたの人生の残りの部分のために行われることから10分離れています。」

• Jon Maddox（@maddox）

2018-11-13 18:00:33 UTC

「ときどき何かを放置して一時停止した方が良い場合があります。これはプログラミングに非常に当てはまります。」

• ジョイスウィーラー

2018-11-14 13:37:02 UTC

"コードと恋に落ちることは、問題解決と恋に落ちることと永遠に進行中の会話の一部であることを意味します。" - Kathryn Barrett

2018-11-14 18:00:40 UTC

「決して窓を開けられないようなコンピュータを信用しないでください。」

• Steve Wozniak💻

2018-11-15 14:34:01 UTC

「あなたの問題は他人の解決策です。あなたの解決策は彼らの問題になるでしょう。」

• 道の

2018-11-15 18:00:31 UTC

「分析エンジンは、ジャカード織機が花と葉を織るように、代数パターンを織ります。」

• Ada Lovelace

2018-11-16 13:37:01 UTC

「それは書面で問題になるのと同じ理由でプログラミングでスタイルが重要であることが判明しました。それはより良い読書になります」

• ダグラス・クロックフォード

2018-11-16 18:00:12 UTC

「あなたのコードをコメントすることはあなたの浴室を掃除することに似ています - あなたはそれをしたくないです、しかしそれは本当にあなたとあなたのゲストのためにより快適な経験を作り出します。」

• ライアンキャンベル

2018-11-17 13:37:00 UTC

「プログラミングはピンボールのようなものです。それをすることへの報酬はそれをまたやる機会です。」

• 道の

2018-11-18 13:37:01 UTC

「コーディングの数週間で、計画の時間を節約できます。」

• 道の

2018-11-19 13:37:01 UTC

「もしあなたが積極的にリスクを攻撃しなければ、そのリスクはあなたを積極的に攻撃するでしょう。」

• トムギルブ

2018-11-19 18:01:03 UTC

「単純なことは愚かなことではありません。そうだと思っているのです」

• Paul Krugman

2018-11-20 13:37:01 UTC

「ワインのような優れたソフトウェアは時間がかかります。」

• ジョエル・スポルスキー🍷

2018-11-20 18:00:27 UTC

「水の上を歩き、仕様からソフトウェアを開発することは、両方が凍結されていれば簡単です。」

• Edward V. Berard

2018-11-21 13:37:01 UTC

「プログラムの最も重要な特性は、プログラムがそのユーザーの意図を達成するかどうかです。」

• C.A.R.ホアレ

2018-11-21 14:34:00 UTC

「最初は成功しなかった場合は、バージョン1.0と呼びます。」

• 道の

2018-11-22 13:37:01 UTC

「コンピューターを操作するのはクールなことです。彼らは主張しません。彼らはすべてを覚えていて、ビールをすべて飲んでいるわけではありません。」

• ポール・リーリー

2018-11-22 18:00:10 UTC

「新技術があなたの上にロールオーバーしたら、あなたがsteamrollerの一部ではないならあなたは道の一部です。」

• Stewartブランド

2018-11-23 13:37:00 UTC

「プログラムは詩のようなものです。書かないと詩を書くことはできません。」

• E. W.ダイクストラ

2018-11-23 14:34:02 UTC

「あなたは、ある方法であなた自身の迷路を構築しています、そしてあなたはそれに迷子になるかもしれません。」

• Marijn Haverbeke、Eloquent JavaScript：プログラミングへの現代的な紹介

2018-11-24 17:29:00 UTC

"問題を文書化しないで、それを修正してください。" - AtliBjörgvinOddsson

2018-11-25 13:37:00 UTC

「エラーのないプログラムを書くには2つの方法があります。3つ目だけが動作します。」

• アランJ.ペルリス

2018-11-25 17:29:00 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻💌

2018-11-26 14:34:01 UTC

「アマチュアソフトウェアエンジニアは常に魔法を求めています。」

• Grady Booch

2018-11-26 18:01:20 UTC

「すぐにあまり多くの機能を追加しないようにし、中核となるアイデアを構築してテストする。 - リアカルバー

2018-11-27 13:37:00 UTC

「コンピュータ言語のデザインは公園を散歩するようなものです。ジュラシックパーク、それです。」

• ラリーウォール

2018-11-27 18:00:10 UTC

「コードはパズルです。他のゲームと同じように、ゲームです。」

• アランチューリング

2018-11-28 13:37:01 UTC

「新しいシステムの新しいユーザーはそれぞれ、新しいクラスのバグを発見します。」

• ブライアン・W・カーニガン

2018-11-28 14:34:00 UTC

「シンプルな商品を作ることと、製品をシンプルにすること。」

• Des Traynor

2018-11-29 13:37:00 UTC

「書き留められなければ、存在しません。」

• Philippe Kruchten

2018-11-29 14:34:04 UTC

「ハムはハムであるのと同様に、JavaはJavaScriptである」

• 弾力のあるWebデザイン、Jeremy Keith

2018-11-29 18:00:46 UTC

「トリックは、あなたが望む問題ではなく、あなたが持つ問題を解決することです。」

• ブラム・コーエン

2018-11-30 14:34:01 UTC

「最高のエラーメッセージは表示されないメッセージです。」

• トーマスフックス

2018-11-30 18:00:17 UTC

「単純さは信頼性のための必要条件です」

• E. W.ダイクストラ

2018-12-01 13:37:00 UTC

「あなたの問題は他人の解決策です。あなたの解決策は彼らの問題になるでしょう。」

• 道の

2018-12-02 13:37:00 UTC

"コードと恋に落ちることは、問題解決と恋に落ちることと永遠に進行中の会話の一部であることを意味します。" - Kathryn Barrett

2018-12-03 13:37:01 UTC

「貧弱なテストの効率を向上させるよりも、テストの有効性を最初に向上させる方がはるかに優れています。カオスを自動化することで、より速いカオスが得られます。」

• マーク・フュースター

2018-12-03 18:00:37 UTC

「毎日コードを書いてください。」

• ジョン・レジッグ

2018-12-04 13:37:01 UTC

「大工では2回測定して1回切断します。ソフトウェア開発では、時間がなくなるまで測定したり切断したりすることはありません。」

• アダムモース

2018-12-04 18:00:12 UTC

"ソフトウェアを構築する前に重要な情報の収集を決して過小評価しないでください" - @ LeoBono1

2018-12-05 13:37:00 UTC

「まず、問題を解決してから、コードを書いてください。」

• ジョンジョンソン

2018-12-05 14:34:01 UTC

「決して窓を開けられないようなコンピュータを信用しないでください。」

• Steve Wozniak💻

2018-12-06 13:37:00 UTC

"騒音に気を取られないでください。" - 匿名

2018-12-06 18:00:04 UTC

「そして、コンピュータのプログラミングはとても魅力的でした。あなたはあなた自身の小さな宇宙を作り、そしてそれはあなたがそれにそうするようにあなたが言うのを行います。」

• ヴィントサーフ

2018-12-07 13:37:01 UTC

「プログラムは、人々が読むことができるように、そして偶然にもマシンが実行するように書かれている必要があります。」

• Harold Abelson

2018-12-07 18:00:32 UTC

「貧弱なテストの効率を向上させるよりも、テストの有効性を最初に向上させる方がはるかに優れています。カオスを自動化することで、より速いカオスが得られます。」

• マーク・フュースター

2018-12-08 17:29:02 UTC

「時には、エレガントな実装は単なる機能です。方法ではありません。クラスではありません。フレームワークではありません。単なる機能です。」

• John Carmack

2018-12-09 17:29:00 UTC

「月曜日のコードのデバッグに残りの週を費やすのではなく、月曜日にベッドにいるほうがよい場合があります」

• クリストファー・トンプソン

2018-12-10 13:37:00 UTC

「すべてのシステムには、2つの規則があります。意図されている、または一般的に認識されている規則と、実際の規則（「現実」

）です。」 - Paul Buchheit

2018-12-10 18:00:16 UTC

「イーグルソンの法則：あなたが6ヶ月以上見ていないあなた自身のどんなコードも同様に他の誰かによって書かれたかもしれません。」

• Alan Eagleson

2018-12-11 14:34:01 UTC

「コメントは匂いと見なされるべきだということを、私はここ数年で学びました」

• Ron Lisle

2018-12-12 13:37:00 UTC

プログラミングはあなたが知っていることではありません。それはあなたが理解できることについてのものです。」

• クリスパイン

2018-12-12 18:00:22 UTC

「不可能なことはただ時間がかかる」

• イアン・ヒクソン

2018-12-13 13:37:00 UTC

「うまくいかなくても心配しないでください。すべてがうまくいったなら、あなたは仕事を辞めるでしょう。」

• モッシャーのソフトウェア工学の法則

2018-12-13 14:34:01 UTC

「デバッグがソフトウェアのバグを取り除くプロセスであるならば、プログラミングはそれらを入れるプロセスでなければなりません。」

• E. W.ダイクストラ

2018-12-14 13:37:01 UTC

「プログラミングは、1つの大きな不可能なタスクをいくつかの非常に小さな可能なタスクに分割することです。」

• Jazzwant

2018-12-14 18:00:30 UTC

「ソフトウェア開発の最も重要な側面は、構築しようとしているものについて明確にすることです。」

• Bjarne Stroustrup

2018-12-15 17:29:00 UTC

「進化するシステムは、それを減らすための作業が行われない限り、その複雑さを増します。」

• メイル・リーマン

2018-12-16 13:37:02 UTC

「月曜日のコードのデバッグに残りの週を費やすのではなく、月曜日にベッドにいるほうがよい場合があります」

• クリストファー・トンプソン

2018-12-17 13:37:00 UTC

「1人のプログラマが1か月でできること、2人のプログラマが2か月でできること」

• フレッドブルックス

2018-12-17 18:00:16 UTC

「プログラムがよりきれいでより良いものであればあるほど、それはより速く実行されるでしょう。そして、そうでなければ、速くするのは簡単でしょう。」

• ジョシュアブロッホ

2018-12-18 13:37:01 UTC

「デバッグ時に、初心者は修正コードを挿入します。専門家は欠陥のあるコードを削除します。」

• リチャード・パティス

2018-12-18 18:00:21 UTC

「後になることは決してない」

• ルブランの法則

2018-12-19 13:37:00 UTC

「時には、エレガントな実装は単なる機能です。方法ではありません。クラスではありません。フレームワークではありません。単なる機能です。」

• John Carmack

2018-12-19 18:01:22 UTC

「最高のエラーメッセージは表示されないメッセージです。」

• トーマスフックス

2018-12-20 13:37:01 UTC

「正しい答えを得るための最善の方法は、質問をすることではなく、間違った答えを投稿することです。」

• カニンガムの法則

2018-12-20 18:00:16 UTC

「ハムはハムであるのと同様に、JavaはJavaScriptである」

• 弾力のあるWebデザイン、Jeremy Keith

2018-12-21 18:00:33 UTC

「コードはユーモアのようなものです。あなたがそれを説明しなければならないとき、それは悪いことです。」

• コーリーハウス

2018-12-22 13:37:00 UTC

「だれでもコンピュータが理解できるコードを書くことができます。優れたプログラマは人間が理解できるコードを書くのです」

。 - マーティンファウラー

2018-12-22 17:29:01 UTC

「プログラマーの問題は、遅すぎるまでプログラマーの行動を見分けることができないことです。」

• Seymour Cray

2018-12-23 13:37:00 UTC

「コード行でプログラミングの進捗状況を測定することは、航空機の建物の進捗状況を重量で測定することに似ています。」

• ビルゲイツ

2018-12-24 18:00:32 UTC

「トリックは、あなたが望む問題ではなく、あなたが持つ問題を解決することです。」

• ブラム・コーエン

2018-12-26 13:37:00 UTC

「プログラムを単純に見せる言語ではありません。言語をシンプルに見せるのはプログラマーです！ - - Uncle Bob

2018-12-26 18:00:06 UTC

「あなたのコードを詩のように扱い、それを最低限のものにする。」

• ILYO

2018-12-27 13:37:00 UTC

「効率的な開発の鍵は、「おもしろい新たな過ちを犯す」

ことです。」 - トムラブ

2018-12-27 18:00:13 UTC

「古くなっている引用文が「深く見えるように水を濁らせるように」

というのは、「あなたのエンジニアリングスタイルやコードベースを記述していないことを確認する」ことです。 - サラ・ドラスナー

2018-12-28 13:37:00 UTC

プログラマーは芸術家だとは思わないかもしれませんが、プログラミングは非常に創造的な職業です。それは論理に基づいた創造性です。」

• John Romero

2018-12-28 18:00:30 UTC

「結局、開発階層のどこにいても、コーディングを続けてください。それがあなたにとって最も価値のある場所です。」

• 開発者コード

2018-12-29 13:37:01 UTC

「一般的にプログラムは、何か言いたいことがある場合を除き、何も言わないでください。」

• Kernighan and Plauger

2018-12-29 17:29:00 UTC

「プログラムの最も重要な特性は、プログラムがそのユーザーの意図を達成するかどうかです。」

• C.A.R.ホアレ

2018-12-30 17:29:00 UTC

「分析エンジンは、ジャカード織機が花や葉を織るように、代数パターンを織ります。」

• Ada Lovelace🌸🍃

2018-12-31 13:37:01 UTC

配列インデックスは0と1のどちらから始めるべきですか。私の0.5の妥協案は、適切な考慮なしには拒絶されました。」

• Stan Kelly-Bootle

2018-12-31 18:00:01 UTC

「何かがうまくいかないときに感じる驚きの量は、実行されているコードに対する信頼と信仰の量に正比例します。」

• 実用的なプログラマー

2019-01-02 13:37:00 UTC

「プログラマーを驚くべきものにするのは、コードの行数ではなく、問題に対する彼の解決策の創造性です」

• @MNC_Aubin

2019-01-02 18:01:03 UTC

「新しいプログラミング言語を学ぶ唯一の方法は、その中にプログラムを書くことです。」

• デニス・リッチー

2019-01-03 13:37:00 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💌

2019-01-04 13:37:01 UTC

「6ヶ月以上見ていない自分自身のコードは、他の誰かによって書かれた可能性があります。」

• イーグソンの法則

2019-01-04 18:00:12 UTC

「関数は1つのことをするべきです。それらはそれをうまくやるべきです。彼らはそれをするべきです」

• ロバートC.マーティン

2019-01-05 13:37:01 UTC

「プログラミングは芸術であり、他の芸術と同様に、繰り返し練習することで習得できます。」

• @kapitanjakc

2019-01-05 17:29:01 UTC

「コーディングを早くすればするほど、プログラムの実行時間は長くなります。」

• ロイ・カールソン

2019-01-07 13:37:00 UTC

「人々は変化に抵抗する大きな傾向を持っています。彼らは、「私たちはいつもこれをやり遂げました」

と言うのが好きです。グレースホッパー

2019-01-07 18:00:11 UTC

「興味があります。広く読んでください。新しいことを試す。私は人々が知性と呼ぶものの多くが好奇心に帰着すると思う」

• Aaron Swartz

2019-01-08 13:37:01 UTC

「バグを修正せずに書き直してください。」

• 匿名

2019-01-08 18:00:39 UTC

「バグを修正せずに書き直してください。」

• 匿名

2019-01-08 18:00:39 UTC

「誰かにプログラムを与えなさい、あなたは一日それらをいらいらさせます；彼らにプログラムする方法を彼らに教えなさい、あなたは一生の間彼らを不満にさせます。」

• David Leinweber

2019-01-09 13:37:01 UTC

"賢明な試行錯誤は完璧な知性の計画よりも優れています。" - David Kelley

2019-01-09 18:00:38 UTC

「ソフトウェアを再利用できるようにするには、まずソフトウェアを使用可能にする必要があります。」

• ラルフジョンソン

2019-01-10 13:37:01 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻💌

2019-01-10 18:00:36 UTC

「あたかも私たちがこれまで理解しなければならない唯一の人物であるかのようにソフトウェアを書くことは、起こりうる最大の過ちであり誤った仮定の1つです。」

• カロリーナ・シュチュール

2019-01-11 13:37:01 UTC

「人々のようなプログラムは古くなります。私たちは老化を防ぐことはできませんが、その原因を理解し、その影響を限定し、損傷の一部を元に戻すことができます。」

• マリオフスコ

2019-01-13 13:37:01 UTC

「ブール値についての最も良いことは、たとえあなたが間違っていても、少しだけずれていることです。」

• 匿名

2019-01-14 13:37:01 UTC

「うまくいかなくても心配しないでください。すべてうまくいけば、あなたは失業するでしょう」

。 - モッシャーのソフトウェア工学の法則

2019-01-14 18:00:50 UTC

「プログラミングはあなたが知っていることではありません。それはあなたが理解できることについてです。」

• クリスパイン

2019-01-15 13:37:00 UTC

「理論的には、理論と実践との間に違いはありません。しかし実際には、そうです。」

• 1月L. A. van de Snepscheut

2019-01-15 18:00:48 UTC

「あなたのコードを詩のように扱い、それを最低限のものにする。」

• ILYO

2019-01-16 13:37:00 UTC

「理論はあなたが何かを知っているとき、それはうまくいかない。実務は何かがうまくいくとき、あなたはなぜかわからない。プログラマーは理論と実践を組み合わせている。 - 道の

2019-01-17 13:37:01 UTC

「新技術があなたの上にロールオーバーしたら、あなたがsteamrollerの一部ではないならあなたは道の一部です。」

• Stewartブランド

2019-01-17 18:00:52 UTC

「デバッガはバグを削除しません。スローモーションでそれらを表示するだけです。」

• 道の

2019-01-18 13:37:01 UTC

「すべてのプログラムには2つの目的があります。それが書かれた目的とそうでない目的です。」

• アランJ.ペルリス

2019-01-18 18:00:18 UTC

「あなたが持つことができる最高のプログラミングスキルの1つは、しばらくの間立ち去るべき時を知ることです。」

• オスカーゴッドソン

2019-01-19 13:37:00 UTC

「決して窓を開けられないようなコンピュータを信用しないでください。」

• Steve Wozniak💻

2019-01-20 13:37:01 UTC

「私たちは自分たちの都市を構築する方法で私たちのコンピューター（システム）を構築します。 - エレンウルマン

2019-01-21 13:37:00 UTC

「ときどき何かを放置して一時停止した方が良い場合があります。これはプログラミングに非常に当てはまります。」

• ジョイスウィーラー

2019-01-21 18:00:44 UTC

「削除されたコードはデバッグされたコードです。」

• ジェフ・シッケル

2019-01-22 13:37:00 UTC

「最も効果的なデバッグツールは、慎重に配置されたprintステートメントと相まって、依然として慎重な検討です。」

• Brian W. Kernighan、初心者のためのUnix（1979）

2019-01-23 13:37:01 UTC

「オブジェクト指向バージョンのスパゲッティコードは、もちろん、「ラザニアコード」

です。層が多すぎます。」 - ロベルトウォルトマン

2019-01-23 18:00:43 UTC

「だれでも、コンピュータが理解できるコードを書くことができます。優れたプログラマーは、人間が理解できるコードを作成します。」

• Martin Fowler

2019-01-24 13:37:01 UTC

「実際にそれらを必要としているときには、常にものを実装し、あなたがそれらを必要としていると予見しているときには決して実装しないでください。」

• ロンジェフリーズ

2019-01-24 18:00:50 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💌

2019-01-25 13:37:00 UTC

「コード行でプログラミングの進捗状況を測定することは、航空機の建物の進捗状況を重量で測定することに似ています。」

• ビルゲイツ

2019-01-25 18:00:40 UTC

「DRY - 自分自身を繰り返してはいけません - すべての知識には、システム内で明確で信頼できる単一の表現が必要です。」

• Andy Hunt＆amp; Aデイブトーマス

2019-01-26 13:37:00 UTC

「削除されたコードはデバッグされたコードです。」

• ジェフ・シッケル

2019-01-26 17:29:00 UTC

「1人のプログラマが1か月でできること、2人のプログラマが2か月でできること」

• フレッドブルックス

2019-01-27 17:29:00 UTC

「6ヶ月以上見ていない自分自身のコードは、他の誰かによって書かれた可能性があります。」

• イーグソンの法則

2019-01-28 13:37:00 UTC

「良いプログラミングは良い文章です。」

• ジョンショア

2019-01-28 18:00:38 UTC

「私の最も生産的な日の1つは、1000行のコードを捨てることでした。」

• ケントンプソン

2019-01-29 13:37:01 UTC

「良いコードはそれ自身の最高のドキュメンテーションです。コメントを追加しようとしているので、「このコメントが不要になるようにコードを改善するにはどうすればよいですか」

と自問してください。コードを改善し、それをさらに明確にするためにそれを文書化してください。」 - Steve McConnell

2019-01-29 18:00:03 UTC

「良いアイデアを持つための次善の策は、ユーザーからの良いアイデアを認識することです。時には後者のほうが良いのです。」

• エリック・レイモンド

2019-01-30 13:37:01 UTC

「進化するシステムは、それを減らすための作業が行われない限り、その複雑さを増します。」

• メイル・リーマン

2019-01-31 13:37:01 UTC

"すべてのプログラマーは作家です。" - Sercan Leylek

2019-01-31 18:00:45 UTC

「最高のエラーメッセージは表示されないメッセージです。」

• トーマスフックス

2019-02-01 13:37:01 UTC

「プログラムは詩のようなものです。書かないと詩を書くことはできません。」

• E.Wダイクストラ

2019-02-01 18:00:25 UTC

「今日の仕事を今日終わらせることができても、明日の仕事を明日に終わらせることができないようなやり方でそれを行うのであれば、負けとなります」

• Martin Fowler

2019-02-03 17:29:00 UTC

「プログラミングは一度に一つのことをすることの芸術です」

• Michael Feathers

2019-02-04 13:37:00 UTC

「良いコードはそれ自身の最高のドキュメンテーションです。コメントを追加しようとしているので、「このコメントが不要になるようにコードを改善するにはどうすればよいですか」

と自問してください。コードを改善し、それをさらに明確にするためにそれを文書化してください。」 - Steve McConnell

2019-02-04 18:00:14 UTC

「興味があります。広く読んでください。新しいことを試す。私は人々が知性と呼ぶものの多くが好奇心に帰着すると思う」

• Aaron Swartz

2019-02-05 13:37:00 UTC

メモリリークは水漏れのようなものです。予想外の場合に起こります。貴重品の保護に時間をかけて欲しいものにするには数時間かかります - Fred Heath

2019-02-05 18:00:03 UTC

ある意味では、プログラミングは絵画のようなものです。あなたは空白のキャンバスと特定の基本的な原料から始めます。科学、芸術、工芸を組み合わせて、それらをどう処理するかを決めます。」

• 実用的なプログラマー

2019-02-06 13:37:01 UTC

「シンプルな商品を作ることと、製品をシンプルにすること。」

• Des Traynor

2019-02-06 18:00:25 UTC

「最初にコンピュータサイエンスとすべての理論を学びます。次にプログラミングスタイルを開発します。それからそれをすべて忘れて、ただハックしてください。」

• ジョージ・キャレット

2019-02-07 13:37:01 UTC

「学ぶ方法を知っています。それから、学びたいです。」

• キャサリン・ジョンソン

2019-02-07 18:00:29 UTC

「それで、あなたが速く行きたいのなら、あなたがすぐにやりたいのなら、あなたがあなたのコードを書きやすくしたいのなら、それを読みやすくしてください。」

• Robert C. Martin

2019-02-08 13:37:01 UTC

「唯一の本当の方法で。オブジェクト指向バージョンの 'Spaghetti code'は、もちろん 'Lasagna code'です。 （多すぎる層） " - Roberto Walkman

2019-02-09 13:37:00 UTC

「すべてのプログラムには2つの目的があります。それが書かれた目的とそうでない目的です。」

• アランJ.ペルリス

2019-02-10 13:37:01 UTC

「他の誰かがやろうとしていることについて心配しないでください。未来を予測する最善の方法はそれを発明することです。」

• アランケイ

2019-02-11 13:37:01 UTC

「それが良い考えであれば、先に進んでそれを実行してください。許可を得るよりも謝罪する方がはるかに簡単です。」

• グレースホッパーWomenInSTEM girlsinstem

2019-02-11 14:37:00 UTC

「私の頭脳は単なる致命的なものではありません。 - Ada Lovelace WomeninSTEM

2019-02-11 17:00:09 UTC

「最適化は、常に最新のエンジンから最後の数オンスの馬力を引き出すことではなく、足を踏み入れる前にハンドブレーキを放すことだけです」

• Brian McConnell @xbmccx

2019-02-12 13:37:00 UTC

「これはバグではありません。文書化されていない機能です。」

• 作者不明

2019-02-12 18:00:29 UTC

「コードはユーモアのようなものです。あなたがそれを説明しなければならないとき、それは悪いことです。」

• コーリーハウス

2019-02-13 13:37:00 UTC

「すべての大きなプログラムの中には、外に出ようとしている小さなプログラムがあります。」

• C. A. R. Hoare

2019-02-13 18:00:41 UTC

「ドキュメンテーションはあなたがあなたの将来の自己に書くラブレターです。」

• ダミアンコンウェイ💌

2019-02-14 13:37:00 UTC

「プログラミングはゴルフのゲームに似ています。重要なのは、ボールを穴に入れるのではなく、何ストロークかかるのかということです。」

• ハーランミルズ

2019-02-15 13:37:00 UTC

「コードはパズルです。他のゲームと同じように、ゲームです。」

• アランチューリング

2019-02-15 18:00:13 UTC

「複雑さを制御することは、コンピュータプログラミングの本質です。」

• ブライアン・ケルニガン

2019-02-16 17:29:01 UTC

「毎日コードを書いてください。」

• ジョン・レジッグ

2019-02-17 17:29:00 UTC

「配列のインデックスは0と1のどちらから始めるべきですか？私の0.5の妥協は、適切な考慮なしに却下されました。」

• スタン・ケリーブートル

2019-02-18 13:37:01 UTC

「完璧なソフトウェアは存在しません。簡単なコンピューティングの歴史の中で誰も完璧なソフトウェアを書いたことはありません。」

• 実用的なプログラマー

2019-02-19 13:37:00 UTC

「私の最も生産的な日の1つは、1000行のコードを捨てることでした。」

• ケントンプソン

2019-02-19 18:00:14 UTC

「結局、開発階層のどこにいても、コーディングを続けてください。それがあなたにとって最も価値のある場所です。」

• 開発者コード

2019-02-20 13:37:00 UTC

「焦点は、あなたがしないことをやらないことを決めることです。」

• ジョンカーマック

2019-02-20 18:00:20 UTC

"未来を予測するための最善の方法はそれを実装することです。" - David Heinemeier Hansson

2019-02-21 13:37:01 UTC

「プログラムの完成度が90％を下回ることはなく、95％を超えることはありません。」

• Terry Baker

2019-02-22 13:37:00 UTC

"後では決して等しくない。" - ルブランの法則

2019-02-23 13:37:00 UTC

「2週間以上前に書いたコードを見るのは、初めて見たコードを見るのと同じです。」

• Dan Hurvitz

2019-02-25 13:37:00 UTC

「プログラムがよりきれいでより良いものであればあるほど、それはより速く走るでしょう。そうでない場合は、早くするのは簡単でしょう。」

• Joshua Bloch

2019-02-25 18:00:33 UTC

「ソフトウェアの複雑さは、1つのことに2つのことをさせようとすることに起因します。」

• ライアンシンガー

2019-02-26 13:37:00 UTC

「私にとってプログラミングは重要な実用的なもの以上のものです。」

• グレースホッパー http://art.It

2019-02-26 18:00:52 UTC

「要件や設計がなければ、プログラミングは空のテキストファイルにバグを追加することです。」

• Louis Srygley

2019-02-27 13:37:00 UTC

「うまくいかなくても心配しないでください。モシャーのソフトウェア工学の法則

2019-02-27 18:00:04 UTC

まず、問題を解決してください。次に、コードを書きます。ジョンジョンソン

2019-02-28 13:37:00 UTC

「コードの最初の90％が開発時間の最初の90％を占めています。残りの10％のコードが開発時間の残りの90％を占めています。」

• トムカーギル

2019-03-01 13:37:00 UTC

「正しい答えを得るための最善の方法は、質問をすることではなく、間違った答えを投稿することです。」

• カニンガムの法則

2019-03-02 17:29:01 UTC

「構築できないもの、理解できない」

• リチャードファインマン

2019-03-03 17:29:00 UTC

「プログラミング：アイデアが現実のものに変わるとき」

• Maciej Kaczmarek

2019-03-04 13:37:00 UTC

「6ヶ月以上見ていない自分自身のコードは、他の誰かによって書かれた可能性があります。」

• イーグソンの法則

2019-03-04 18:00:11 UTC

「ユーザーインターフェースは非常に単純でなければならないので、緊急事態の初心者は10秒以内にそれを理解することができます。」

• テッドネルソン

2019-03-05 13:37:00 UTC

「コーディングの数週間で、計画の時間を節約できます。」

• 道の

2019-03-06 13:37:00 UTC

「プログラマーが悪いプログラムを作成するのを妨げるようなプログラミング言語は、たとえどんなに構造化されていても、ありません。」

• Larry Flon

2019-03-06 18:00:34 UTC

「プログラミングは一度に一つのことをすることの芸術です」

• Michael Feathers

2019-03-07 13:37:01 UTC

"私が今までに感じた最も幸せな瞬間は、私が私の創造する能力を発見した瞬間でした。" - Hazem Ali博士

2019-03-07 18:00:20 UTC

@codingsansが（無償で）State of Software Development 2019の調査を手伝っているので、過去の報告が洞察に満ちたものであるようにあなたが参加することを願っています！ここに向かって - - 10分もかからず、あなたは無料で最終的な完全な報告書を受け取るでしょう。

http://bit.ly/2WX5aPS

2019-03-08 13:01:22 UTC

「私の頭脳は単なる致命的なものではない。時間が示すように」

• エイダラブレースInternationalWomensDay＃IWD2019

2019-03-08 14:19:33 UTC

「あなたのスキルに少し不快を感じることは学習のしるしであり、継続的な学習はハイテク業界が成功するものです！」

• ヴァネッサハースト＃InternationalWomensDay2019＃IWD2019

2019-03-08 18:00:27 UTC

「入港船は安全ですが、それは船の目的ではありません。 - Grace Hopper＃InternationalWomensDay2019＃IWD2019

2019-03-08 19:37:00 UTC

「私がまったく覚えていたら、私は私の家族の語り手として覚えておきたいです。 - ケイ・マクナルティーMauchly Antonelli＃InternationalWomensDay2019＃IWD2019

2019-03-08 20:37:01 UTC

「あたかも私たちがこれまで理解しなければならない唯一の人物であるかのようにソフトウェアを書くことは、起こりうる最大の過ちであり誤った仮定の1つです。」

• カロリーナ・シュチュール

2019-03-09 13:37:00 UTC

究極の結論は「コードを書くとき、あなたはかなりの量のパワーを持っていることがわかった」

であるので、ここに含まれているきちんとした話。

Here’s a silly Google Maps origin story about how “Satellite” was almost named “Bird Mode” https://t.co/wj7CRJUEyxhttps://twitter.com/btaylor/status/1099370126678253569

2019-03-09 17:29:00 UTC

「ドライバーを持っているプログラマーやプログラムを持っているハードウェアエンジニアよりも恐ろしいのは、1組のワイヤーカッターとrootパスワードを持っているユーザーだけだ」

。 - エリザベスズウィッキー

2019-03-10 13:37:00 UTC

「月曜日のコードのデバッグに残りの週を費やすのではなく、月曜日にベッドにいるほうがよい場合があります」

• クリストファー・トンプソン

2019-03-11 13:37:00 UTC

「唯一の真の方法で。「スパゲッティコード」

のオブジェクト指向バージョンは、もちろん「ラザニアコード」です（レイヤーが多すぎます）。 - ロベルトウォルトマン

2019-03-12 13:37:02 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻💌

2019-03-12 18:00:28 UTC

「あなたのコードをコメントすることはあなたの浴室を掃除することに似ています - あなたはそれをしたくないです、しかしそれは本当にあなたとあなたのゲストのためにより快適な経験を作り出します。」

• ライアンキャンベル

2019-03-13 18:00:09 UTC

「コード行でプログラミングの進捗状況を測定することは、航空機の建物の進捗状況を重量で測定することに似ています。」

• ビルゲイツ

2019-03-14 13:37:00 UTC

「ブール値についての最も良いことは、たとえあなたが間違っていても、少しだけずれていることです。」

• 匿名

2019-03-15 13:37:00 UTC

あなたが私たちとあなたの知恵の言葉を共有したいのなら、恥ずかしがらないで、私たちにDMを落としてください。 💻

2019-03-16 13:37:00 UTC

「日曜日の朝のようにプログラミングは簡単ではありません。静かな詩です。」

• ワセム・ラティフ

2019-03-17 13:37:00 UTC

「デバッガはバグを削除しません。スローモーションでそれらを表示するだけです。」

• 道の

2019-03-18 13:37:00 UTC

「コーディングを早くすればするほど、プログラムの実行時間は長くなります。」

• ロイ・カールソン

2019-03-18 18:00:24 UTC

「バグを修正せずに書き直してください。」

• 匿名

2019-03-19 13:37:00 UTC

「興味があります。広く読んでください。新しいことを試す。私は人々が知性と呼ぶものの多くが好奇心に帰着すると思う」

• Aaron Swartz

2019-03-19 18:00:40 UTC

「時には、エレガントな実装は単なる機能です。方法ではありません。クラスではありません。フレームワークではありません。単なる機能です。」

• John Carmack

2019-03-20 13:37:00 UTC

コーディングの手間を省くことで、計画時間を節約できます。」

• 不明

2019-03-20 18:00:16 UTC

「プログラム構築の本質の大部分は、実際には仕様のデバッグです。」

• Fred Brooks

2019-03-21 13:37:00 UTC

「コードはパズルです。他のゲームと同じように、ゲームです。」

• アランチューリング

2019-03-21 14:22:14 UTC

「あなたがすることができる最も貴重なことは間違いです - あなたは完璧であることから何かを学ぶことはできません。」

• アダムオズボーン

2019-03-21 18:00:37 UTC

「新技術があなたの上にロールオーバーしたら、あなたがsteamrollerの一部ではないならあなたは道の一部です。」

• Stewartブランド

2019-03-22 13:37:01 UTC

"これらの時間の練習、そして失敗は、学習プロセスの必要な部分です。" - Gina Sipley

2019-03-22 18:00:37 UTC

"私が今までに感じた最も幸せな瞬間は、私が私の創造する能力を発見した瞬間でした。" - Hazem Ali博士

2019-03-23 17:29:00 UTC

「ブール値についての最も良いことは、たとえあなたが間違っていても、少しだけずれていることです。」

• 匿名

2019-03-24 13:37:01 UTC

「ソフトウェアが「完了」

であることは、芝生が「刈られる」ことに似ています。」 - ジム・ベンソン

2019-03-25 13:37:01 UTC

「プログラマーにXを実行するためのライブラリがすでにあることを伝えることは、ソングライターにすでに愛についての曲があることを伝えることと同じです。」

• ピートコーデル

2019-03-25 18:00:10 UTC

「ソフトウェア開発の最も重要な側面は、構築しようとしているものについて明確にすることです。」

• Bjarne Stroustrup

2019-03-26 18:00:42 UTC

「ソフトウェア開発者として、あなたはあなた自身の最悪の敵です。すぐに気づくほど、あなたはより良い恩恵を受けることになります。」

• Jeff Atwood

2019-03-27 13:37:00 UTC

「アマチュアソフトウェアエンジニアは常に魔法を求めています。」

• Grady Booch

2019-03-27 18:00:46 UTC

「あなたのコードを詩のように扱い、それを最低限のものにする。」

• ILYO

2019-03-28 13:37:00 UTC

「古いAPIやコードを後悔することは絶対にありません。年齢にはそれぞれ独自の状況や理由があるため、自分のせいにして刷新を楽しんではいけません。」

• @elshaarawy_____

2019-03-28 18:00:30 UTC

「不可能なことはただ時間がかかる」

• イアン・ヒクソン

2019-03-29 13:37:01 UTC

「単純というのは愚かなことではありません。そうだと思っても意味があります」

• ポール・クルーグマン

2019-03-29 18:00:22 UTC

"あなたがそれを見つけた方法よりもキャンプ場をきれいにしておいてください。" - Robert C. Martin

2019-03-30 17:29:00 UTC

「恥ずかしがり屋のコード - 他のモジュールに不要なものを明らかにしない、そして他のモジュールの実装に依存しないモジュールを書く」

。 - デイブトーマス

2019-03-31 12:37:00 UTC

「言語は、私たちの考えを変えるか、しないかを決定します。」

• エリック・ナグム

2019-03-31 16:29:00 UTC

「ノーコードはノーコードより速いです。」

• メルブモット

2019-04-01 12:37:00 UTC

「プロジェクトの最初のステップは、その複雑さと困難さを著しく過小評価することです。」

• ニコールハント

2019-04-01 17:00:43 UTC

「機能、品質、時間：2つ選んでください。」

• 匿名

2019-04-02 17:00:10 UTC

「不足している要件は、修正するのが最も難しい要件のエラーです。」

• Robert L. Glass

2019-04-03 12:37:00 UTC

「最高のプログラムは、プログラマーが何か他のものに取り組んでいると思われるときに書かれたものです。」

• メリンダバリアン

2019-04-03 17:00:01 UTC

「プログラムの最も重要な特性は、プログラムがそのユーザーの意図を達成するかどうかです。」

• C.A.R.ホアレ

2019-04-04 12:37:00 UTC

「あなたが持つことができる最高のプログラミングスキルの1つは、しばらくの間立ち去るべき時を知ることです。」

• オスカーゴッドソン

2019-04-04 17:00:00 UTC

「最初は成功しなかった場合は、バージョン1.0と呼びます。」

• 道の

2019-04-05 12:37:00 UTC

「効率的な開発の鍵は、「おもしろい新たな過ちを犯すこと」

です。 - トムラブ

2019-04-05 17:00:46 UTC

「エラーのないプログラムを書くには2つの方法があります。3つ目だけが動作します。」

• アランJ.ペルリス

2019-04-06 12:37:00 UTC

「水の上を歩き、仕様からソフトウェアを開発することは、両方が凍結されていれば簡単です。」

• Edward V Berard

2019-04-06 16:29:01 UTC

「テストは失敗につながり、失敗は理解につながります。」

• Burt Rutan

2019-04-07 12:37:00 UTC

「窓から捨てることができないコンピュータは絶対に信用しないでください。」

• Steve Wozniak

2019-04-07 16:29:00 UTC

「コーディングを早くすればするほど、プログラムの実行時間は長くなります。」

• ロイ・カールソン

2019-04-08 12:37:00 UTC

「誰かにプログラムを与えなさい、あなたは一日それらをいらいらさせます；彼らにプログラムする方法を彼らに教えなさい、あなたは一生の間彼らを不満にさせます。」

• David Leinweber

2019-04-08 17:00:10 UTC

「Javaとはカーペットにとっての車とはJavaScriptのことです。」

• Chris Heilmann

2019-04-09 12:37:00 UTC

「JavaScriptの強みはあなたが何でもできることです。弱みはあなたがすることです。」

• レッグブレイスウェイト

2019-04-10 12:37:01 UTC

「私にとってプログラミングは重要な実践的な芸術以上のものです。知識の基盤における巨大な仕事でもあります。」

• グレースホッパー

2019-04-11 12:37:00 UTC

「大規模なアプリケーションを構築するための秘訣は、大規模なアプリケーションを構築することではありません。アプリケーションを小さな部分に分割します。次に、テスト可能で一口サイズの部分を大きなアプリケーションに組み立てます。」

• ジャスティン・マイヤー

2019-04-12 12:37:00 UTC

「これはバグではありません。文書化されていない機能です。」

• 匿名

2019-04-12 17:00:33 UTC

「バグが表面化するまでの時間が長いほど、見つけるのは難しくなります。」

• ロディグリーン

2019-04-13 12:37:00 UTC

「トリックは、あなたが望む問題ではなく、あなたが持つ問題を解決することです。」

• ブラム・コーエン

2019-04-14 12:37:00 UTC

「コードはユーモアのようなものです。説明しなければならない場合、それは悪いことです。」

• Cory House

2019-04-15 12:37:00 UTC

「すべてを可能な限り単純にするが、単純にはしない」

• アルバート・アインシュタイン

2019-04-15 17:00:21 UTC

"プログラミングについて考える方法に影響を与えない言語は知る価値がありません。" - Alan J. Perlis

2019-04-16 12:37:00 UTC

「プロトタイプの価値は、コード自体ではなく、あなたに与える教育にあります。」

• アランクーパー

2019-04-16 17:00:08 UTC

「ソフトウェアを再利用できるようにするには、まずソフトウェアを使用可能にする必要があります。」

• Ralph Johnson

2019-04-17 12:37:01 UTC

「失敗する可能性があるものはすべて失敗します」

• マーフィーの法則

2019-04-17 17:00:34 UTC

「新しいプログラミング言語を学ぶ唯一の方法は、その中にプログラムを書くことです。」

• デニス・リッチー

2019-04-18 17:00:01 UTC

「あなたの問題は他人の解決策です。あなたの解決策は彼らの問題になるでしょう。」

• 道の

2019-04-19 12:37:00 UTC

Original by Github issue

https://github.com/YumaInaura/YumaInaura/issues/1356

自分の状況を簡単に説明します。
自分は未経験からエンジニアになり、業務経験は半年ほどです。
業務ではRubyを書きつつ、
・C言語の技術書を２冊半ほど写経（『苦しんで覚えるC言語』『新・明解C言語 中級編』『C言語で学ぶアルゴリズムとデータ構造（途中）』）
　↓
・swiftの学習
と進んできています

よく話題になるテーマだと思うのですが、自分なりの切り口で書いてみようと思います。
「そんな未熟者が偉そうに…」と思われた方、すみません汗
適当に読み飛ばしてください。

自分の考えは、

「必要でない場合が多いけど、できるならやっておいた方がいい。」

です。

理由は「参照情報が増えるから」です。

参照情報とは簡単にいうと記憶のことです。
例えば、
①今まで行ったことのない店に行く
②何度か通りかかったことがある店に初めて行く
③行きつけの店に行く
の3つを難しい順に並べるとどういう順番になるでしょうか？

いうまでもなく① > ② > ③の順で難しいです。

これらの違いは「道順をどの程度記憶しているか」に起因しています。
同じもしくは似た記憶が少しでもある方がやり易く、またその記憶も鮮明であるほど行うのが容易になっていきます。
自分たちが何かを理解しようとするとき、すでに持っている記憶や経験と照らし合わせて分かろうとします。
その意味で記憶＝参照情報です。
なのでその事柄に関する記憶、もしくは似た体験の記憶があるほど理解と行動が容易になります。

プログラミングに話を戻すと、
C言語には他の言語では考えなくてもいい部分を考える必要があります。
他の言語では自動でやってくれる部分を手動で操作するようにできています。

自動車でいうと、オートマ車でもマニュアル車と同じくギアの切り替えはしていますよね。
ただその部分を自動車がやってくれるので運転手が意識する必要がなくなっているだけです。
それと同じことなんですよね。

逆に言えば、考えることが多いC言語を学習することで、プログラミングに関する豊富な参照情報を得ることができます。
その結果、コードを読んで理解するスピードが速くなったり、新しい言語を習得するのが簡単になったりします。

業務や独学の中で「ああC言語でいうとあれのことね」「これってC言語の構造体と似てるな」と記憶と紐づく場面が何度もあります。

ですので自分の結論は、
「必要でない場合が多いけど、参照情報を増やすためにC言語を学習した方がいい」
です。

参考図書

小沼勢矢『自分の脳に合った勉強法』
https://www.amazon.co.jp/%E8%87%AA%E5%88%86%E3%81%AE%E8%84%B3%E3%81%AB%E5%90%88%E3%81%A3%E3%81%9F%E5%8B%89%E5%BC%B7%E6%B3%95-%E5%B0%8F%E6%B2%BC%E5%8B%A2%E7%9F%A2/dp/4894517906

Ref

Introducing JSX – React

Codepen

• Codepenでコードをしばらく眺める
• さっぱり分からずに固まる
• ドキュメントに戻って読んだりする

A Pen by yumainaura

呼吸とかする

スタバの抹茶のティーラテをゆっくり飲む

熟成

• コードの前で立ち止まるのは良くないというが、僕の場合は立ち止まる。
• こんな簡単そうなコードでも立ち止まるので、自分の頭が相当悪いのだろうと、誰にもせかされていないのに焦ってくる。
• 5分ぐらいゆっくりしていると、問題意識が立ち上がる。「どこがネックなの？」と。

コードの首を捕まえる

elementを

render してるだけじゃん！

elementを

render してるだけじゃん！

elementを

render してるだけじゃん！

このコードの並び順おかしくね？ 分かりづらくない？ と思って並び替える

もっと簡単にできるっしょ？と思って、引数やらなにやらを削っていく

ダウンサイズ！

分かってきた気がするぞ。

ちゃんと動いてるしね！

A Pen by yumainaura

コードが分からなかったら Hello world ぐらいまでダウンサイズ

とか、わりと良い方法かもしれない。

Original by Github issue

https://github.com/YumaInaura/YumaInaura/issues/1391

プログラマに限らず、失敗したり、怒られたり、いやがらせをされたり、果てはいじめられたりしても、めげないようにするにはどうしてきたかを書いてみます。

自分しかできないことをする

ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

中学校の技術の先生に、人がやらないことをやれと言われました。
学校の教室内だけだったら、見回して、人がやらないことをやるのは簡単かもしれません。

世間に出て、人がやらないことをやろうと思うと、
誰が、何をやっているかを知らないと、人がやっていないことをやるのは難しい。

自分の直感を信じればいいという人もいるかもしれません。
演劇の寺山修司とか、音楽の松本隆とか細野晴臣（はっぴいえんど）とか、
自分では到底到達できなさそうなところを進んでいる人を遠目にみると、
自分の直感で人がやらないことができる自信はありませんでした。

何年ももがいてい、懸賞論文とか６年とか、７年とか出し続けて、毎年落ちるとめげていました。
あるところで、二位になったことがあり、ああ、上がいるんだという思いが増してきました。

とにかく、やたらめったら勉強したり、やたらめったら書き散らすしかないと思っていました。
あるソフトウェアで、ソースコードがあり、知人がマクロを作ったとき、
自分もなにかやらねばと思い、ソースコードを持ち歩き、すべての行をコメントにして振る舞いを確認していったら、思いがけない成果がありました。

失敗の記録は後の人に役立つ

人が育つのに、成功が必要だという説には同意する。
成功した事例をどれだけ書いてあっても、そこには成功の本当の要因が記載されているとは限らない。

時代、環境、人の能力、性格、周りの人々など、書ききれてないことが山のようにある。

失敗の記録でも、失敗の要因も書ききれない程度は同じかもしれない。
ただ、経験則として、本人が失敗の要因だと思って書いた事項の50%くらいは妥当だと思う。

成功の要因は5%くらいしか妥当だと感じたことはない。
成功の要因は本人の見えないところにいっぱいあって、成功している限りみえない場合がある。

失敗の要因は、成功している限り見えないものが見えてしまうかもしれない。

その割合は約１０倍。
失敗したことを、公開できることなら公開の場に記録しよう。

先日、ある実験の報告を拝見した。
大事なのは成功したデータではなく、成功したデータが出るまでに、実験に失敗したデータの記録だと。

学生の電気実験で、前年の報告をもらって、実験をしても、同程度のデータが最初から取れることは半分もなかった。
報告には、失敗した実験の記録がなく、工業高校の頃から実験が得意だった同級生の経験に頼るしかなかった。

できれば、自分たちの報告は、失敗も記録しておけば、翌年からの実験の際に役立つかもしれないと思った。

失敗がいっぱい記録してあれば、経験の蓄積に厚みができ、もっと違う失敗をしてみる勇気がわくかもしれない。

仮説検証

失敗する前に、今からやることの制約条件を知っているかどうか。
経験があるかどうか。経験がなければ、経験のある人の記録をみておくかどうか。

学生実験の場合では、前年の実験の報告をみておくこと。
数年前だと、実験装置、実験環境、材料、道具の違いがあるかもしれない。
細かい制約条件が報告に書いてないと、古い報告は、制約条件が違う可能性を想定しておくとよい。

制約条件は無限にあり、書ききれない。
いつ、だれにとって、どういう状況かで、大事な制約条件は違う。

立てた仮説を検証してみる過程で、制約条件の抜け漏れなどで失敗することは、
時間の変化の中でありうることだろう。

一つでも仮説についての新たな知見があれば、プログラミング実験そのものが失敗でも、
報告としては有用な情報が一つつけ加わることになる。

仮説の失敗

「失敗してもめげないプログラマになるには」という仮説そのものが間違い。
失敗は、失敗を記録するためのものであり、着実に成長するための記録でしかない。

問題は、過去に類似の失敗の記録があるのに、その記録を読まずに、同じ失敗を繰り返すこと。
これは、失敗ではなく、怠惰。

怠惰と、失敗を一緒にしてはいけない。

参考資料

初めての　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

文書履歴(document history)

ver. 0.01 初稿 20190501
ver. 0.02 表現修正 20190503

各会社の技術ブログをまとめてみました。
使ってみたい技術や知見は、実際に使われている
現場の声を聞くのがベストかと思います。

ぐるなびのブランチ運用にはお世話になりました！
参考：GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ

ファッション

ZOZO Technologies TECH BLOG（ZOZOTOWN、WEAR）
https://techblog.zozo.com/

Enigmo Engineers & Designers blog（BUYMA）
http://www.enigmo.co.jp/blog/tech/

グルメ

ぐるなびをちょっと良くするエンジニアブログ
https://developers.gnavi.co.jp/

Retty Tech Blog（Retty）
https://engineer.retty.me/

トレタ開発者ブログ
http://tech.toreta.in/

食べチョク開発者ブログ
https://tech.tabechoku.com/

ライフ

クックパッド開発者ブログ
https://techlife.cookpad.com

株式会社エブリー（DELISH KITCHEN）
https://www.wantedly.com/feed/s/every_techblog

dely engineering blog（クラシル）
https://tech.dely.jp/

お部屋

LIFULL Creators Blog（LIFULL HOME'S）
https://www.lifull.blog/

athome-developer’s blog（at home）
http://dblog.athome.co.jp/

家計簿

マネーフォワード エンジニアブログ（マネーフォーワード）
https://moneyforward.com/engineers_blog/

フリマ

Mercari Engineering Blog（メルカリ）
https://tech.mercari.com

BASE開発チームブログ
https://devblog.thebase.in/

ワーク

wantedly エンジニアブログ
https://www.wantedly.com/feed/s/wantedly_engineers

ランサーズ（Lancers）エンジニアブログ
https://engineer.blog.lancers.jp/

ココナラよもやまブログ（ココナラ）
https://yomoyamablog.coconala.co.jp/

レンタルオフィス

スペースマーケットブログ（SPACEMARKET）
https://blog.spacemarket.com/category/code/

ビジネス

Chatwork Creator's Note（チャットワーク）
https://creators-note.chatwork.com/

Cybozu Inside Out | サイボウズエンジニアのブログ
https://blog.cybozu.io/

ペパボテックブログ（GMOペパボ）
https://tech.pepabo.com/

GMO MEDIA CREATOR BLOG（GMOメディア）
https://blog.gmo.media/

GMOアドパートナーズグループ TECH BLOG byGMO（GMOアドパートナーズ）
https://techblog.gmo-ap.jp/

Sansan Builders Box（Sansan株式会社）
https://buildersbox.corp-sansan.com/

RakSul Tech Blog（ラクスル）
https://tech.raksul.com/

SmartHR Tech Blog
https://tech.smarthr.jp/

ベーシック エンジニアブログ（ferret）
https://tech.basicinc.jp/

キュレーションサイト

Gunosy Tech Blog
https://tech.gunosy.io/

SmartNews Engineering Blog
https://developer.smartnews.com/blog/

UZABASE Tech Blog（NewsPicks）
https://tech.uzabase.com/

ミュージック

レコチョクのエンジニアブログ
https://techblog.recochoku.jp/

GAME

エンジニア｜XFLAG （エックスフラッグ）
https://xflag.com/blog/engineer/index.html

GameWith Developer Blog
https://tech.gamewith.co.jp/

クリエイティブ

pixivエンジニアブログ
https://inside.pixiv.blog/

とらのあな開発ブログ
http://toranoana-lab.hatenablog.com

SHOWROOM Tech Blog
https://tech.showroom.co.jp/

マッチングアプリ

Eureka Engineering – Medium（Pairs）
https://medium.com/eureka-engineering

Tech系

Qiita Blog
https://blog.qiita.com/

paiza開発日誌
https://paiza.hatenablog.com/

メディア

Google Developers Japan
https://developers-jp.googleblog.com/

LINE ENGINEERING（LINE）
https://engineering.linecorp.com/ja/blog/

Yahoo! JAPAN Tech Blog
https://techblog.yahoo.co.jp/

サイバーエージェント デベロッパーズブログ（Ameba）
https://developers.cyberagent.co.jp/blog/

mixi developers
https://medium.com/mixi-developers

DMM inside
https://inside.dmm.com/

GREE Engineering
https://labs.gree.jp/blog/

DeNA Engineers' Blog
https://engineer.dena.jp/

リクルート
https://recruit-tech.co.jp/blog/

Hatena Developer Blog
https://developer.hatenastaff.com/

dwango on GitHub（ドワンゴ）
https://dwango.github.io/

KAYAC engineers' blog（面白法人カヤック）
https://techblog.kayac.com/

Media Do Tech Do Blog
https://techdo.mediado.jp/

その他

技術書展は最近有名ですね
アプリマーケティングはフォローしてみると面白いかも...!?

技術書典ブログ
https://blog.techbookfest.org/

アプリマーケティング 研究所
https://note.mu/marketing
https://mobile.twitter.com/appmarkelabo

「プログラマにとって、何か知っている必要なことは何もない」という仮説を立て、検証する過程の記録。

2019年5月10日 先週の 金曜日に、
仮説・検証（34）心理学の本を読むよりはコンパイラ書いた方がよくね
https://qiita.com/kaizen_nagoya/items/fa715732cc148e48880e

という話が出た次の会話。

何かを知らなくても、作れればよい。

門前の小僧とか、写経とか、知ることではなく、反復して慣れることで、作れるようになる道もあるかもしれない。

プログラミング言語教育のXYZ
https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4

で紹介している母語方式。

知っていることと、作れることは方向性が違う。

「知っていて、人の作ったものに文句ばっかり言って、自分で作らない人が組織の中に、３割以上いると腐敗する」ということを語っていた先輩がいる。

知っていることと、作れることと、作ることは別の次元。
作るのは、試行錯誤でできる。

試行錯誤で作ったものが、品質が悪いかどうかは感性(sense)の問題。

知っていることと、作れることと、感性がいいことに、
順序関係が存在することを証明したという報告は聞いたことがない。

作っていくうちに感性がよくなるひともいれば、
知っていると感性をよくできる人もいる。

知っていることが邪魔して感性が悪くなる人もいれば、
作れちゃうので感性がよくならないひともいるかもしれない。

３つの事象は、直交するかどうかは確かめてないが、少なくとも二次元空間は貼るし、
ひょっとしたら三次元空間で考えるのがよいように感じている。

中学校の時の技術の先生は、人と違うことをしろと教えてくれた。
何かを知ることが技術ではなく、人と違うものを作ろうとすれば、技術が身につくと。

仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

これも感性。

自分のまわりの一つや二つ、よくて１０や２０の例で、一般化していないだろうか
少数の例を一般化することは技術者としての感性がないことの証明になるかもしれない。
知っていることと同様で、どっちでもいいことかもしれない。

これくらいのものを作っていると、これくらいのことを知っている確率が高いというのは、
１００人、２００人と接すると、確率の中央値は収束することは経験則だと思う。

分布が正規分布にはなる経験はないし、１０００人、２０００人でも分散が小さくなる経験もない。

社会的事象は、自分に都合のいい論法を、自分に都合よく展開することはできる。社会的事象は根拠のデータは作ろうと思えば作れるし、逆のデータも作れる。

統計を取って、確率分布を想定するという作業をしても、
プログラマにとってという、多数の人間を扱うときに、そんなに有効な理論があるかどうか。

あれば、銀の弾丸になっている。
一般的な銀の弾丸はないということに合意している人が、
別の視点の議論では、一般的な銀の弾丸の仮説を検証せずにお題目にする。

ある行動をとった人が、次にどういう行動をとるかというのは、
WEBのデータなどから、商売に役立つ指針は作れるかもしれない。

あることを知っている人が、次にどういう行動をとるかは、
役に立ったという経験の分散が小さいという話は聞いたことがない。

何かを知っていることが、プログラムがかけることの根拠にはならないというのが経験則。

＜この項はかきかけです。＞

名古屋Reject会議　2011
https://www.youtube.com/watch?v=He1_tg4px-w&t=489s
この時の十数人の発表で、ニコ動での人気度は３位だった。
自分以外はほとんど十代、二十代、三十代の人たちの集まりで。

参考資料(reference)

仮説・検証（38）プログラマで「飛び抜けた人が少ない」という仮説
https://qiita.com/kaizen_nagoya/items/f0d22e20f6d2c58f2c1b

プログラマだったら当然知ってるよね？という知識一覧
https://anopara.net/2019/05/11/basics-for-programmers/
この記事へ何か加算しようと思ったら、減算しかなくて、結論はこの記事です。

文書履歴(document history)

ver. 0.01 初稿 20190513 昼
ver. 0.02 みだし修正 20190513 午後
ver. 0.03 日付補足 20190514 夕
ver. 0.04 見出し追記 20190514 夜
ver. 0.05 僕の先生　追記 20190516
ver. 0.06 プログラマだったら 20190517

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

プログラマ35歳定年説

35歳プログラマ定年説というのがあった。今でも言われてるのかな？35歳くらいになったらプログラマとしてやっていけない。チームを管理して行かないとダメ！ってやつ。
キャリアパスとして早くプログラマを離れてシステムエンジニアやプロジェクトマネージャーになることがIT技術者として一人前というのは、IT後進国:日本に顕著に表れてる悪い風潮だと思う。そもそもプログラマを3年くらいやれば自然に管理する仕事もやるわけで、そういう意味で管理職になれない人なんていないはずでしょ？

45歳以上の管理職リストラブーム

でも最近は少しずつというか一気に変わってきたのかもしれない。
企業も気づいてきたわけです。口だけの管理者より、手を動かせるエンジニアが必要だって！
結果、大企業を中心に口だけのフェイクIT技術者が首を切られている。45歳以上の管理職はリストラだって。
今までは管理職になるということで：
- 自分のIT技術者としての技術力の無さを隠せる
- 隠せる上に地位も給料もベター
- 技術的な知識は一般論レベルの抽象的なものでＯＫ
- 基本的に一般論を言ってそれらしく演じていればよし

つまり管理職というのは実力のないフェイクIT技術者にとっては格好の隠れ蓑だったわけです。マネージメントといっても基本進捗管理とその報告だけで、プロジェクトの進捗はプログラマ任せなわけだから。
こうやって技術から逃げて格好だけでいい思いをしていた人たちがどんどんリストラされているんだと思います。ある意味必然ですよ。

これから先

日本におけるIT技術者のキャリアパスを考えると、こういったフェイクIT技術者は35-45歳にはもっといるかもしれない。1,2年プログラマを経験後、マネージメントという名の進捗管理と雑用業務へ・・・って人

今までプログラマがIT土方と理不尽に馬鹿にされていた風潮を破壊すべく、一般論を言うだけで高い給料をもらってるフェイクIT技術者はどんどんいなくなるべき。
リストラが加速して早く本物のエンジニアが地位的にも給料的にも報われる、IT先進国:米国のような社会が日本にもやって来ることを願っています。

[翻訳]あなたがプログラミングに向いていない10のサイン
https://qiita.com/hareku/items/4bfc48e23e83e0d300f3

拝見して、確かにと感じた。

日本語だけだと誤解しているかもしれず心配。
翻訳がいいとか、悪いとかがきになるのではなく、
英語でどういう単語で言っているかで、日本語より英語の方がわかるかもしれず、
英語も読んで、英単語を調べて確認中。

10 Signs You Will Suck at Programming, Jonathan Bluks
https://blog.usejournal.com/10-signs-you-will-suck-at-programming-5497a6a52c5c

1. 好奇心の欠如 (Lack of curiosity)

curiosity
https://eigogen.com/word/curiosity/

cur- : L.curare = to take care of(気をつける, 世話をする

https://dictionary.cambridge.org/dictionary/english/curious

mainly uk strange and unusual:

ハリーポッターで出てくる。
ukの方にこの意味でcurousと言われたことがある気がする。間違いない。

2. 自律性と機知の欠如(Lack of autonomy and resourcefulness)

autonomy
https://eigogen.com/word/autonomy/

nom- : Gk.nomos = 管理

resourcefulness
臨機応変
https://sanabo.com/words/archives/1999/07/post_519.html

resourceful
https://eigogen.com/word/resourceful/

surg-, sur- : L.surgere = to rise(上がる), get up（起き上がる）

機知とは、臨機応変のことで、臨機応変であるためには、資源が豊富でないと駄目なんだろう。

読んだ本の数とか、resourcefulである。間違いない。

3. 問題に直面しても粘り強さが無い(Lack of persistence in the face of a problem)

persistence

persist
https://eigogen.com/word/persist/

sist-, stitus-, st-, struct- : L.sistere = to cause to stand(立てる); L.stare = to stand(立つ)

頑強だと言われる。打たれ強い。間違いない。

人を打って問題を解決したことにする人は、ここで脱落。

4. 問題解決に成功した気持ちはない(No feeling of success in overcoming a problem)

overcoming

http://www.wakaru-english.info/overtakeとovercomeの違い.html

仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

失敗してもいいと言われ、何度失敗しても、人のやらないことをし続けている。

１万回に１回成功することがある。

経験則：１万人か１０万人に１人は同じ意見の人が現れる
https://qiita.com/kaizen_nagoya/items/ebb04e35d408f9d388ad

成功体験が一度もないことは辛い。
20歳代で、懸賞論文投稿など１０年間、落選しつづけた。
30歳頃、初めてあるところで第二席になった。上はいたけど、１０年つづけてそれが無かったら折れていたかも。

今でも、１０年間は評価されなくても続けていけるのはこの時の経験のおかげ。間違いない。

人を打って問題を成功にしたことにする人は、ここで脱落。

5. 学習と理解に焦る(Impatient about learning and understanding)

impatient
https://eigogen.com/word/impatient/

path-, pass- : Gk.pathein = to suffer(苦しむ)

上記に書いた。１０年続けるのが経験則。１年、２年で成果がでなくてめげちゃ駄目。間違いない。

6. 思考に飽きたり疲れたりする(Getting bored/tired from thinking)

bore
https://gogen-ejd.info/bore/

ゲルマン祖語 burona（穴を開ける）

amazon 殿堂入りNo1レビュアーになるまで
https://qiita.com/kaizen_nagoya/items/83259d18921ce75a91f4

3000冊登録あたりまで、北海道立工業試験場の掘武司さんが、書いたものを評価してくれた。それがなかったら、飽きたか、諦めたかもしれない。感謝。間違いない。

7. 自分のことを考えられない(Inability to think for yourself)

think for (oneself)
https://idioms.thefreedictionary.com/think+for+myself

To have opinions or make decisions without letting other people dictate to or influence oneself.

自分のことしか考えられない。他の人の意見は、自分と同じ意見の人を見つけてから。間違いない。

8. 堅く、狭く、そして無秩序な考え(Rigid, narrow and/or disorganized thinking)

rigid
https://eigogen.com/word/rigid/

L.regere = to rule, guide(支配する, 統治する);

disorganized
https://kotobank.jp/ejword/disorganize

柔らかく、広く、体系的な考え方が、汎用的な制御理論のあり方。間違いない。

9. 複数の答えの間の「良い」と「悪い」の連続性に気付かず、「正しい」答えを望んでいる(Needing the “right” answer instead of recognizing a spectrum of “good” and “bad” answers)

仮説・検証(93) 科学四分類と算譜
https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603

正しいか正しくないかを計算するのは論理科学だけ、物理化学、生命科学、社会科学では、正しいという概念は役に立たない。良し悪しが社会科学だが、立場が違えば解は逆転する。間違いない。

10 細部に注意を払っていない(Not paying careful attention to details)

細部から記述してもよい構造を作れるのが設計者。間違いない。

文書履歴(document history)

ver. 0.01 初稿 20190601 午後
ver. 0.02 １０項目記載 20190601 夜
ver. 0.03 見出しにしないと数字が増加しない 20190601 夜中
ver. 0.04 脱落する人を想定。消すかも。20190601 真夜中
ver. 0.05 消す 20190902 朝

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

依存症と言っても悪いことだけとは限らない。

良い依存症も含めて調べ、落ち入ってもよい依存症と、落ち入らない方が良さそうな依存症を列記してみる。

犯罪分析、人間関係分析はこの記事の目的外です。一部の依存症は記述していません。ごめんなさい。

Qiitaに書き続けているのもネット依存症の一つかも。

網(net)

プログラマが陥り易い依存症の３つのうちの一つかも。もう２つは、遊興競技と過食。

プログラム

GitHub, dockerなどに創ったソースコードを上げたり、上がったソースコードやスクリプトを直したりするのは、依存症かもしれない。

プログラマ本来業務であるが、お金にならないことをしている場合には落ち入らない方がよい依存症かもしれない。
お金になったとしても、仕事依存症のように、依存症の一種かもしれない。

SNS

line, twitter, mastodon, facebookなど対話的なやりとりを毎日するだけなら依存症とは言わない。

line, twitter, mastodon, facebook, instagramなどでのやりとりで

1) 何かが前に進んだ
2) 新しいものを創った
3) 誤りや無駄が省けた

のであれば、生産活動であり負ではない。

成果は、書いた時点で評価できる事項もあれば、１日後、１ヶ月後、１年後、１０年後、１００年後でないと評価できない事項もあるかもしれない。

WEB

Youtube, sound cloud, ブログなどで、対話式でなく、ひたすらWEBにデータを上げ続けるのも依存症と呼べるだろう。

掲載している内容によって正負が決まるかもしれない。

遊興競技(game)

時間(time)

もし、１日のうち、ゲームを作ったり、評価したりするのが仕事でないのに、ゲームをしている時間が仕事時間よりも長ければ、ゲーム依存症だろう。

週で集計してゲームしている時間が、仕事時間より長ければ、ゲーム依存症の可能性がある。

ただ、仕事時間よりゲームしている時間が長いプログラマは、ゲームプログラムができるはず。本業または許可を得た副業としてゲームプログラムすればよい。
今なら、働き方改革で、多くのIT企業で副業としてのゲームプログラミングを許可してくれるはず。

PlayStationが発売になったころ、開発キットが10万円くらいで出た時に、ゲームを作ったソフトウェア企業がたくさんあった。今のIT技術を生かしたゲームや、ゲームで使ったキャラの使い回しなど、本業でも役立つことがあって、会社からゲームの一部を買ってもらえるかもしれない。

種類(type)

ネット、パッケージなどの媒体の種類。
スマフォ、ゲーム機、PCなどの機材の種類。
有償、無償などの費用の種類により依存症の状態が違うかもしれない。

ネットでは有償、無償の差が課題かも。

費用(cost)

ゲーム依存症でもお金がかからなければ、負であるとは限らない。
小学生の高学年で、携帯電話を持ち始めて、月に１万円以上使うのが２月以上続いたら、負のゲーム依存症として認定してもいいかもしれない。ただし、プログラミングで月１万円以上かせいでいれば、負とは限らない。

賭け事(gamble)

遊興競技(game)の区分との違いは、お金が中心かどうか。
遊興競技(game)であっても、例えば、パチンコ、トランプ、麻雀などでお金のやりとりが主たる目的である場合には、賭け事(gamble)に分類します。

運転(driving)

自動車(motor car)、二輪(motor cycle)
乗り物を運転する依存症があるかもしれない。

通勤に日に数時間運転し、週末に日に八時間運転するくらいなら依存症じゃないかもしれない。
トラック、バス、タクシーの運転手で、日に１２時間以上運転するのも依存症じゃないかもしれない。

依存症であるかどうかは、医学的な基準に基づくのがいいだろう。

運動(sport)

運動競技の選手などで、運動しないといられない依存症があるかも。
運動が仕事であれば、仕事依存症。

摂取(feeding)

酒(alcohol)

アルコール飲料を、過剰に摂取しつづけ、摂取しない日がないのは依存症かもしれない。

煙草(nicotine)

たばこ依存症。禁煙が厳しくなり、多数派である業種は少なくなりつつある。

薬物(drag)

合法な薬物か違法な薬物かは別にして、食物以外のものを過剰に摂取しつづけるのは依存症かもしれない。

過食(overeating)

暴飲暴食だけでなく、夜８時以降の食事等も含む。

夜、プログラムを組みながら、キャラメルコーンを食べ、コーラを飲んでいたら、
毎年２Kgづつ太った。20歳から10年間で20Kg。
肥満生脂肪肝で入院し、減量に成功。

いろいろな過食の類型は考えられる。

減量(loss weight)

減量に依存する場合もあるらしい。

購買(shopping)

平均月収より購買額が連続して１年以上継続したら依存症かもしれません。
期間が短くても、年収以上の購買をすれば、その時点で依存症と判断してもいいかもしれません。
amazonなどのネット通販依存症は、ネット依存症にも分類できるかも。

ここでは、医学的な依存症ではなく、社会的な依存症を検討しています。

窃盗(stealing)

犯罪依存症の一種。

迷惑行為(harassment)

仕事場（Workplace harassment）などなど。
依存症だと考えると習慣性を断つ方法が検討できるかも。

人関係(human relation)

家庭内暴力(Domestic Violence), 付きまとい(stalking)、恋愛、登場人物(character)など。
詳細は省略します。

定義(definition)

依存症とは？

大石クリニック
http://www.ohishi-clinic.or.jp/izon.html

物質、プロセス、人間関係の３つに分類している。

依存症には主に 2種類あります

依存症についてもっと知りたい方へ　厚生労働省
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000149274.html

「物質への依存」について：
アルコールや薬物といった精神に依存する物質を原因とする依存症状のことを指します。
依存性のある物質の摂取を繰り返すことによって、以前と同じ量や回数では満足できなくなり、次第に使う量や回数が増えていき、使い続けなければ気が済まなくなり、自分でもコントロールできなくなってしまいます（一部の物質依存では使う量が増えないこともあります）。
「プロセスへの依存」について
物質ではなく特定の行為や過程に必要以上に熱中し、のめりこんでしまう症状のことを指します。

社会通念上の分類(classification)

毎日、３時間以上やらないと気が済まないたぐいのことは、依存症の可能性あり。やらない日があれば依存症じゃないと思う。医療上の区分ではなく、社会通念上の区分です。
１時間程度なら気分転換法の一種だと理解。

　依存症と愛好家の境界(borderline)

天文、音響、無線、遊興競技、自動車・二輪車、鉄道など、愛好家の方々の行動が、依存症なのかどうかの医療的な判定は存じ上げない。
社会通念上の区分として、絶対毎日やらなければいけないと思い込んで、実行している場合に、その度合いによるかも。
自動車・二輪車のように、通勤、通学で３時間程度利用していることは生活の必須行為に含む事ができ、依存症とは言わない可能性がある。電車で行った方が便利で、時間も費用も安いのに、わざわざ両側に駐車場を借りて、車に乗っているようだと依存症の可能性があるかもかもかも。

対策(countermeasures)

依存症対策　厚生労働省
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000070789.html

個人的な対策案

遊興競技(game)

1. ゲームをするより作る 作る側に回のが根本対策の一つ。ゲームに関わる時間でお金が稼げればよい。仕事で、ゲームを作り、その試験のためにゲームをするのなら、お金がもらえる。

2.午前中はゲームをしない
プログラマになっても、ついつい試験以外のゲームをしてしまう。そんな時にゲーム依存症にならないようにしていたことに、午前中はゲームをしないという自己規則だ。午前中にゲームをしなければ、１日のうち、ゲームをしている時間が最長になる可能性は低くなる。また、午前中に１日分のプログラムをしようとすると、仕事の密度も高くなる。ついつい午後もプログラムしていることがある。

過食(overeating)

夜はできるだけ８時までに食事をする
よく噛んで食べる（ごはんは３０回噛む）
間食はしない
麺類の汁は全部飲まない（栄養士さんからの指導：ここから上全部）
スポーツドリンクは飲まない（医師からの指導）
毎日体重を計る。

分類(category)

仕事依存症
・プログラミング
・運転
・運動
・仕事場（Workplace harassment）

遊興競技(game)依存症
・賭け事(gamble)

網(net)依存症
・SNS
・Web
・プログラミング
・購買

金銭依存症
・購買
・賭け事(gamble)
・窃盗

摂取依存症
・薬物
・ニコチン
・酒
・過食
・減量

人間関係依存症
・付け回し(stalking)
・家庭内暴力(Domestic Violence
・恋愛
・登場人物(character)

犯罪依存症
・窃盗
・家庭内暴力(Domestic Violence)
・違法賭け事(gamble)
・違法薬品
・仕事場（Workplace harassment）

参考資料(reference)

「GAFA断ち」
https://qiita.com/kaizen_nagoya/items/5fb95a9df523721377f6

プログラマが知っているとよい色使い(安全色)とカラーユニバーサルデザイン
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

文書履歴(document history)

ver. 0.01 初稿 20190623
ver. 0.02 分類追記 20190625 午前
ver. 0.03 社会通念上の分類, 依存症と愛好家の境界　追記　20190625 午後
ver. 0.04 補足 20190813
ver. 0.05 加筆 20191026

「今後プログラムを１行も書かなくなったとしても、あんなプログラマになりたいと思う人が一人でもいる限りプログラマとして生きていると定義する。」という題を決めて文章を書き始める。

この記述は、ある学会の幕間に、あんなプログラマになりたいという人物像に登場したという話を聞いたことを発端として書き始める。

そう人が亡くなっても、人の心に生き続ける限り、その人が生きるという。

プログラマの書いたソースコードが生き続ける限り、そのプログラマが生き続けるという仮説をたてよう。

それだけでは面白くないかもしれない。

あんなプログラマになりたいと思う人が一人でもいる限りプログラマとして生きているという定義も容認するのはどうだろう。

もう１種類くらいあってもいいかもしれない。

また今度。

少し表現が変わった。

やっぱ、ソースコードが生きてりゃいいよね。

今日死ぬとして、何を伝えておきたいか。

本当に大切なこと以外をいくら話しても、何も伝わらない。

しゃべりが上手な人ならともかく。

日本語をしゃべりたくないからプログラマしている。
日本語で何か意思疎通できるつもりは全くない。
講演、学会発表などを行うときだけでなく。
人と話をするときも。

いちごいちえ　という言葉があるらしい。

意味はよく知らない。
漢字もよくわかっていない。
今日会ったから話せることを話す。
そんな意味を含めてもいいかも。

与件分析者(data analyst)

２０代のころ、何度懸賞論文などに出しても入選しなかった。

プログラムを組めるようになって、データ解析はじめたら、すぐに２席に入賞した。
人ができないことをしたことが分かれば、分かってくれる人もいる。
プログラムやデータに語らせれば。

その意味では、自分はデータサイエンティストなのかもしれない。

理工学研究科で、理論家ではなく、実践派だから理学博士でなく工学博士を選択している。

データサイエンティストというより、与件分析者(data analyst)を自称しよう。
プログラム自体よりもデータ解析の方が先に評価されているから。

返事(response)

ときどき日本語でいただくご意見(comment)で、全く返事をしないことがあります。
英語でいただくコメントでも、１割以上は無反応かのように見えるかもしれません。

返事をする言語を持たないからかもしれません。

何かのデータを示していただくか、
プログラミング言語で書いていただければ、
コンパイルしたり、走らせたりして確かめられ、お返事できるかもしれません。

よろしくお願いします。

動画(movie)

自分が同志だと思っている三人を引用する。

最後の講義『みうらじゅん』「もし、今日が最後なら何を伝えたいか！」
https://www.youtube.com/watch?v=oKD-s5PXdYA

YouTubeから消えていました。下記からごらんください。

https://www.nhk-ondemand.jp/goods/G2019095850SA000/

2017/03/15 早野龍五教授 最終講義「CERNと20年福島と6年 - 311号室を去るにあたって」
https://www.youtube.com/watch?v=utje4ctbuAQ

京都大学2016年度退職教員最終講義　阿辻 哲次（人間・環境学研究科 教授）「電子時代の漢字研究」2017年3月15日
https://www.youtube.com/watch?v=A3FOIkyep2I

「今昔文字鏡を使えば」という発言がある。資料はこちら。
文字鏡フォント
https://qiita.com/kaizen_nagoya/items/64c2ff25271ea8ebf2b0

参考資料（reference)

ジャクリーヌ・ベルント先生最終講義② マンガ研究の私～この20年を振り返って～　京都精華大学大学院マンガ研究科

自己参考資料(self reference)

成功体験は語っても、成功体験に頼らないために。清水吉男・田中伸明
https://qiita.com/kaizen_nagoya/items/d32adfaf7b2568bfd9d2

仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

意味の集合論
https://qiita.com/kaizen_nagoya/items/9c87d0d4f0b0b70cf4af

上のみうらじゅんYouTube 動画 の「空あり」の意味も理解できるように。

文書履歴（document history)

ver. 0.01 初稿　20190704　朝飯前
ver. 0.02 データサイエンティスト　追記　20190704 朝食後
ver. 0.03 参考資料、データ追記　20190704 午前
ver. 0.04 みだし追加・文章補足 20190724
ver. 0.05 最後の講義『みうらじゅん』「もし、今日が最後なら何を伝えたいか！」,
早野龍五教授 最終講義「CERNと20年福島と6年 - 311号室を去るにあたって」YouTube追記 20190806
ver. 0.06 京都大学最終講義　阿辻 哲次（人間・環境学研究科 教授）「電子時代の漢字研究」, ジャクリーヌ・ベルント先生最終講義 マンガ研究の私～この20年を振り返って～　京都精華大学大学院マンガ研究科 20190807
ver. 0.07 文字鏡フォント　記事からのリンクなど。20190826
ver. 0.08 ３人に焦点をあてる。 20190927
ver. 0.09 動画URL補正 20191009午前
ver. 0.10 記述補正 20191009 昼

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

プログラマに限らず、違和感を感じた時に、することを記録する。

違和感は、いつも、至るところで感じる。

人

９割くらいの人に会って話をすると違和感を感じる。

【対策案】
解決方法は、人とは話をしない。
自分の考えたこと、思いついたことを、プログラムするか、記録する。

プログラムすれば、わかってもらえることが半分くらいある。

ああ、その人はどうでもいいことを話ししてて、自分で解決する気が無かったことに気がつく。
そういう人と話しをすることが無駄だったとわかる。

プログラム書かない人とはなるべく話しをしないに限る。

プログラム書いている人と話しをしていると、自分がやっていないことにしばしば気がつく。
あとは、それを真似るか、そのたぐいはその人に任せるかの選択。

仮説・検証（47）プログラマはどれくらい人付き合いしないといけないか
https://qiita.com/search?page=3&q=kaizen_nagoya+人

仮説・検証（7）IT業界に説教は必要か
https://qiita.com/kaizen_nagoya/items/2f088f496d8a66132ec6

建物、設備

人の手が触るところにRが取れていなかったり、
車椅子で移動できないような構造になっていると違和感を感じる。
手すりがなかったり、捉まえるものがない空間があったり。

窓が小さかったり、空気の流れがなかったり。
冷えすぎていたり。
座るところがなかったり。

【対策案】
仮説・検証（24) 高齢者・障害者設計指針(1) 点字ブロック・手すり・階段
https://qiita.com/kaizen_nagoya/items/47e0b3a83c2e250fa80c

をもう少し加筆します。今しばらくお待ちください。

配色

なんだこれはという配色のポスタが貼ってあるところがある。
流石に、最近はヌードポスターなどを貼っているところは少ない。

人肌よりも不安感を与えるような配色のポスタは辞めてほしい。

学会発表だったりしたら最悪。
ちゃんと配色教えようよ。

【対策案】
まず、次の記事を読んでもらう。

プログラマが知っているとよい色使い(安全色)とカラーユニバーサルデザイン
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

組織

組織で違和感を感じなかったのは、アメリカのIT企業に行った時と、電総研に行った時くらい。
それ以外のほとんどの組織には違和感を感じる。

仮説・検証(111) アメリカ留学、アメリカ就職の代わりに行ったこと。行なっていること。
https://qiita.com/kaizen_nagoya/items/9f8e791bd6be3bed34bb

その会社の社訓や、歴史を知ると、納得することも半分くらいはある。
その会社にいる人が、社訓を無視していることがあり、違和感を感じる。

習慣には、過去の遺産で、今の仕事なら改めた方がいいことのような気がすることもある。
個別に、昔話をお聞きするとよいかも。

女性に対する扱いが乱雑だったり、女性が半数近く（４割以上）いないと違和感を感じる。

【対策案】
女性の存在確率を４割以上を目標に

言葉

カタカナ語を連発している文書、発言に遭遇すると違和感を感じる。

英単語でなければ意味が通じないと思ったら英語で話せよ。
その方が全く違和感がない。

日本人だけの会合であっても、記録を取って海外の事務所にも配信するなら英語でもいい。
そっちは違和感を感じない。

日本語で大人になるまで生きてきた人には、英語は違和感を感じることがあっても仕方ない。
その人の人生だから。
そういう人には日本語で説明するのは嫌じゃない。

【対策案】
カタカナ語よりも英単語を使うことを推奨。
あるいは、漢字(English)表記を推奨。
略号(abbreviation)はfull spellingなどを。

まぎらわしい、間違えやすい、行き違いの多い略号worst 10(候補24)
https://qiita.com/kaizen_nagoya/items/0bff5dbb72208053489b

仮説・検証(88)用語の衝突(用語・用例募集中)
https://qiita.com/kaizen_nagoya/items/6a8eb7ffaa45eeb16624

自然言語処理で陥る罠
https://qiita.com/kaizen_nagoya/items/71093310ffc5324f15ff

Windows

Windowsでしか仕事をしていない人を見ると違和感を感じる。
あなたが見ている先のサーバはLinuxだったり、
あなたが利用しているクラウドはLinuxだったりする。

End UserならWindowsだけというのもありだと思う。
複数のOSを使う必要はない。

プログラマでWindowsだけってなによ。
Windowsだって、Unixの影響を受けて発展してきたもの。
源流を知らずに、プログラマしているのに違和感。

【対策案】
Windowsにdocker導入することをまず提案。

docker(19) 言語処理100本ノックをdockerで。python覚えるのに最適。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

docker(18) なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2

違和感を感じた時の行動

1) 横になって寝る
寝付けない時は、自分の好きな動画などを見る。映画館や、コンサートを聞きに行って寝ることも。

仮説・検証(108) 音楽映画で英語勉強（目標100作品）
https://qiita.com/kaizen_nagoya/items/7c37e4502f2f785ab104

2)ジャズ喫茶・図書館に籠る
難しい哲学の本を読むか、量子力学のプログラムを組むか。
その時々。

プログラマが国立国会図書館（本館：永田町）利用:16の関門(FD読めない！)
https://qiita.com/kaizen_nagoya/items/09252fdce118ec9e21aa

国会図書館にFDドライブを
https://qiita.com/kaizen_nagoya/items/44de2ba05e8307b29a98

3) 子供と遊ぶ
自分ちの子供が大きくなったら、近所の子供か、科学館などに行って子供たちに説明したり。
展示会に出展して子供ばかりに説明したり、子供預かり處で子守の手助けしたり。
絵本の読み聞かせや、子供向けのプログラミングの企画もお勧め。

ちょけねこ　たんじょうびのおくりもの
https://qiita.com/kaizen_nagoya/items/fc9675686c229f7a155e

効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446

4) ゲームする
ゲーム依存症に要注意。

プログラマが落ち入らない方が良さそうな依存症群調べ
https://qiita.com/kaizen_nagoya/items/4d00b3fc2d9f649e0a18

5) 行動分析をするか、コンパイラ書く。
心理分析は絶対しない。
人の罠にはまっていくだけ。

仮説・検証（34）心理学の本を読むよりはコンパイラ書いた方がよくね
https://qiita.com/kaizen_nagoya/items/fa715732cc148e48880e

番外編

日本にいても、自分を異邦人だと感じる。
アメリカに行った時に、アメリカのIT企業を訪問し、違和感を感じなかった。
就職したいと思った。

日本では、電総研(現在の産総研の一部)に行った時に違和感を感じなかった。

仮説・検証(111) アメリカ留学、アメリカ就職の代わりに行ったこと。行なっていること。
https://qiita.com/kaizen_nagoya/items/9f8e791bd6be3bed34bb

海外に行った時、その国で暮らせるかをまず確認する。

地べたに横になって、その国の土の暖かさを知り、
町を歩いて、道に迷わずに、computer shop, book shop, libraryに行けるかどうか。
そこの品揃えを見て、仕事に必要な機材、書籍が入手できるかどうか。
Wi-Fiなどのネットが繋がるかどうか。

イスラエルと韓国に行った時、町を歩いて、標識、看板がわからずに違和感を感じた。
ちなみに、訪問したことがある国は、韓国、中国、香港、タイ、シンガポール、マレーシア、オーストラリア、インド、イスラエル、南アフリカ、ロシア、フィンランド、スウェーデン、デンマーク、オランダ、ドイツ、フランス、オーストリア、イタリア、スペイン、イギリス、アイスランド、アメリカ、カナダ、メキシコ、ペルー、ブラジルを記憶している。

韓国と日本のIT業界で協力できるかもしれないこと
https://qiita.com/kaizen_nagoya/items/52501f8ee4dc23f595eb

文書履歴(document history)

ver. 0.01 初稿 20190714
ver. 0.02 加筆 20190716　朝
ver. 0.03 docker URL追記 20190716 午前

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

プログラマの意思疎通の方法

ログラマが顔を見合わせて会議をやるか、テレビ会議をするか、コメント・チャットですますか

仮説・検証（48）プログラマが苦手な「人との口頭のやりとり」面談技術(interview technique)７つの要点
https://qiita.com/kaizen_nagoya/items/f322df6978853c708c99

1) GitHub, gitlab, bitbucketなどのissue, wikiなどに追記、注釈(comment)などをする。あるいは、twitter, facebook, slackなどで、chat。追記、注釈(comment)などをする。

2) テレビ会議で、カメラと画面を共有して会議をする。
この場合、一部、音声だけの参加者、chatだけの参加者がいる場合がある。

3) 直接集まって会議をする。
この場合に、一部、遠方でテレビ会議参加者がいる場合がある。

面直無し

ソフトウェアを一緒に作るといっても、部分的な道具に分かれていて、その部分は独立して作ることができる場合、一度も会ったことがなく一緒に仕事をする場合がある。

例えば、VZエディタの移植をした時に、割り込みベクタテーブルを試験する道具は、一度も会ったことがない方から提供を受けて利用した。

VZエディタはソースコードを公開する商用ソフト。
差分は無償で公開してよかった。
ソースコードは、差分も含めて全員で共有できた。
思いのままに変更して、差分を公開すると反応があった。
今のオープンソースでの反応のように。

ソースコードを通じてのやりとりなら、揉めない限り面直はいらない。
いくつもの、制約条件の違いによる分岐(fork)はあったとしても。

仮説・検証(115) VZエディタ移植に当たって実施したことと成果
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949

年に１度から３年に１度

VZエディタの移植が動き始めてからは、利用者への配布を兼ねて、東京で会合を持った。
JUG/CP-Mというフリーソフトの配布団体の東京の会合には、３年に１度くらい出ていた。そのメンバが組織してくれて、東京で会合を持った。２０人以上が集まってもらえた。ほぼ全員がNEC。

ネットでは書きづらい感想などは、恥ずかしいという視点と、間違いがあるといけないという観点と、悪意がないのに相手が誤解するといやだという過去の経験などから、面直の方が言いやすいらしい。たしかに、直接言えば、外していたかどうかは直感的にわかることがある。

VZ倶楽部の発行記念パーティでも初めてお会いする方や、３年に１度くらいしかお会いできない人に会えた。IT業界だと、３年経つと、会社がなくなっていたり、会社を移っていたり、存在確認の役にも立つ。

毎年ある行事には、３年に１度は出るとよいというのが経験則か。

VZエディタのように、開発環境DOSの上にVZエディタを使い、optasmのコンパイルスクリプトまで同じであれば、環境の構築に手間はかからない。

Windows, MacOS, Linuxなどの複数のOSで、複数のコンパイラという環境では、環境の構築が容易ではない。

WindowsでAnaconda構築の Qiita記事が、Views自己最高なのも、道具の導入の困難性を物語っている。

同じ環境で作業しない限り、情報の共有は無理。環境の共有ができていないのだから。
githubでソースコードの共有ができても、それぞれの機材に違うソフトウェアが入っていれば、同じ環境の構築はできない。

docker hubに環境をあげておけば、いつでも、どこでも同じ環境で作業できる。

ソースコードと環境の共有が、情報共有の基礎。githubとdockerを使わずに、情報共有は片腹痛い。

仮説・検証（51）公開算譜は機敏だ(open source is agile)GitHub and docker
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e

docker(19) 言語処理100本ノックをdockerで。python覚えるのに最適。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

docker(18) なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2

月に１度から３月に１度

ある会社とOSの開発をしていた時に、試験プログラムとMISRA Cの検査を担当していた。
MISRA Cの検査のためには、一部プログラムを書き換えて、戻るgotoを、進むgotoに書き換えて試験する必要があった。スクリプトを同僚に書いてもらい、受け取ったら、試験のための処理の一部を自動実行して、１日で完了する体制を取った。

そのために、開発途中のソースコードを毎週もらい、順次試験をして、その時点で変更した方がいいところは報告して、場合によっては書き直す候補を提案した。
これらの作業は、すべてネットのメールなどで実行した。

月に１度か３ヶ月に１度、定例会議で会う。もう一方の作業をしている同僚と相手方とは、もう一つ前のOSの開発の際に、CPUの移植にあたって組んでいたため、そちらは面識が深く、この頻度で問題はなかった。こちらの組みも、面識はあったし、やりとりの中で、特に課題はなかった。そのため特別の面談の機会は設けなかった。

仮説・検証（50）作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab

仮説・検証（47）プログラマはどれくらい人付き合いしないといけないか
https://qiita.com/search?page=3&q=kaizen_nagoya+人

仮説・検証（7）IT業界に説教は必要か
https://qiita.com/kaizen_nagoya/items/2f088f496d8a66132ec6

週に１度から３週に１度

毎日、ネットで日報をあげてもらっている仕事の時に、週報は面直にした。
そうはいっても、出張などで出られない人は、３週に１度くらいになる。

日報は、進捗状況や、課題（個人と組織に分けて）をあげてもらうが、
週報は、自分の得意な技術の紹介や、この１週間で調べたことの報告、この１週間で書いたプログラムの報告をしてもらうことにした。

おかげで、いろいろな作業が進んだ。

１０年くらい前には、週報は、その１週間の間に読んだ本（仕事でも仕事以外でも）の紹介をしていたことがある。amazon.co.jpで１万冊感想を上げる目標をたてていた時。

７人の読んだ本を、その週の間に拝見して、読んだ人とは違う視点を感想に書くようにしていたことがある。amazon.co.jpの感想で偏っている理由の一つかも。

仮説・検証(73)プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69

仮説・検証（40）報連相　再考
https://qiita.com/kaizen_nagoya/items/013f2779bd2beba720b7

仮説・検証（116）今日死ぬとしたら　日本語が不得意なプログラマが話をすること
https://qiita.com/kaizen_nagoya/items/61a03864ac6c011e6164

毎日(daily)

組織によっては、朝会、昼会などをするところがあるらしい。
何か、助け合うことがあるならそれもいいとは思う。

実際に、会わないと聞けないことは多い。
言える雰囲気かどうか。

文書履歴(document history)

ver. 0.01 初稿 20190716
ver. 0.02 毎日追記 20190717

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

LINEオープンチャット

いよいよオープンチャットが利用開始になった(^^)
http://official-blog.line.me/ja/archives/79448193.html

早速開設・・・

折角なのでプログラマやエンジニアのみなさんと
コミュニケーションが取れるルームを・・・と思って作ってみました♪♪

目指せ！楽しくて稼げるプログラマー✨
https://line.me/ti/g2/xN5RGD-_b8b3i5W2g-NN2w
※入り方を最後に書いていますので是非最後までお読みください m(＿＿)m

目的

・楽しく働けるプログラマを増やしたい
・稼げるプログラマを増やしたい（搾取されないという意味も含めて）
・何が必要なのかなど、道筋が分かる場所を提供したい
・単純に聞きたいことを聞きたいｗ
・技術的な質問や動向などについても話したりしてみたい
などなど・・・という感じです！(^^)

なぜ？？

なぜ僕にそういう想いがあるのかというと・・・

元々は現在一部上場企業にまでなっているある会社で
サラリーマンプログラマをやっていたのですが、その時は正直社畜でした・・・💦

通勤途中にぶっ倒れたり、うつ手前まで行きましたし
昇進して結構な立場だったのに給料が手取りで15万円とか
ほんとに最初はかなり苦労しました (^_^;)

何とか転職をして、人生を一変させることができましたが
本当に運が良かっただけで
まだまだ暗黒の時代をお過ごしの方も多いでしょうし
プログラマがどうなっていくとどうなるのかなど
将来のことや今後のことを聞きたかったり・知りたかったりする方もいると思います。

学生さんでこれからプログラマ目指そうとしている方や
目指しているけど「実際のところどうなの？？」とか聞きたい方もいると思います。

何か手助けになれることがあればという想いはずっと持っているので
今回オープンチャットで作ってみた次第です！！✨

あっ・・・もちろん、こちらから聞きたいこととかもあるので
色んなプログラマさん・エンジニアさんが入ってくださると嬉しいです！！

入り方（2019/8/22変更）

オープンチャットを利用するには以下の手順で進める必要があるとのこと・・・
⇒オープンチャットが一般公開されて①～③の手順は要らなくなりました！！
いきなり④からルームにお入りください！！

①LINEアプリを最新バージョンにアップデート

②OpenChatスタートページを開き、[OpenChatをはじめる]ボタンを押す
https://w.line.me/openchatactivate/
​
③ボタンが緑色になったら、LINEアプリを一度終了し、再起動

④こちらからルームに入る
目指せ！楽しくて稼げるプログラマ＆エンジニア✨

最後に

少しでもお役に立てるならと本気で思っているので
興味のある方は是非お待ちしています！(^^)

「自分の経験も役に立てるなら」と思って入ってくださる方も、もちろん大歓迎ですので
どうぞよろしくお願いします！！

IT事務員とは

IT事務員というのは「契約書の確認」「パートナー会社調整」「依頼事の記帳管理」「データ入力」など
エンジニアやプログラマーとは違い、主に単調な事務作業をするお仕事をする人のことをいいます。
扱う仕事もプログラムとは全くの無縁でエクセルを扱うことが多くエンジニアとしての成長は見込めません。給与は300万程度で市場価値も上がりにくいとも言われています。
近年この「ITエンジニア」と類似していることから事務員を確保する為「IT事務員」といった名称で企業が当人の将来成長を保証しない（実質）形で募集をしているので今回はIT事務員にならない為のポイントを厳選してご紹介します。

未経験からIT事務員にならないための3つのこと

①アポイント確認
エンジニア、プログラマーとしての現場で行う仕事なのか、エクセル等事務的な単調的な仕事なのか面接の段階や面接前にきちんとコンタクトをとりましょう。
企業のホームページに行けばお問い合わせフォームやメールアドレスが記載されているので事前に連絡して確認しましょう。
メールなど返信がなければ電話で直接採用担当に聞いてみるのも良いでしょう。

②募集要項のキーワード確認
OS（Linux,Windows）や言語名(Python、Java)など具体的に募集要項に記載されているか確認しよましょう。
サーバーサイドのエンジニアかプログラマー的な職種で変わりますが、きちんと募集要項に記載されている内容が専門的内容か確認しましょう。わからない単語があればその場でググれ！

③やっぱり資格やポートフォリオが安全！
なんといっても資格やポートフォリオは便利です。というのも資格に関しては取得する間に様々な知識を得ているので非常にアピールになりますし、ポートフォリオはある程度のレベル感がわかるのでこちらもお薦めです。
ただし注意してほしいのは中には資格は勉強チックな感じが否めないので途中で挫折する可能性が高いです。なので個人的には仕事しながらでも1週間で作成できる程度のもので構わないのでポートフォリオを作成することをお勧めします。
中には3カ月程度かけて作る人もいるようですが、大作を作るまでにモチベーションが続かないこともあるでしょう。
ポートフォリオはまず1週間程度がよりベストかと思います。

最後に

未経験の人がきちんと市場価値のあるITエンジニアになる為にルートを間違えないような内容を記載させていただきました。
中にはIT事務員になってしまったという方もいるでしょうが、自分がもしIT事務員になってしまったら働きながら1週間程度でポートフォリオを作り転職活動を速攻でします。
IT事務員であった経歴も「用語には大分慣れました」とか「ベンダーとの調整をたくさんしました」とか「障害の際には大きな損害が生じることがわかったので注意して作業したい」など経験を隅から隅までアピールに変換して転職活動をします。
こちらは今経験が浅い案件にしか携わっていない方にも同様です。
参考になりましたでしょうか。
それではみなさんが最高のエンジニアライフを送れることを願っています。