プログラムは頭で覚えるんじゃない、体で覚えるんだ。

コンピュータは利口ではない。そう思い込んでいるだけだ。

そもそも、デバッギングはコーディングよりも２倍難しい。従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。

我々は、97%もの時間を占めているという、わずかな効果(を得るためだけ)の作業はやめるべきだ。尚早な最適化(作業)は諸悪の根源だ。

「動的型付け：『コンピュータにコードが機能する理由は説明できないが、その動作は何もかも頭の中で追えている』という確信のことである」 chris__martin

ホフスタッターの法則：作業は、いつだって予測以上に時間がかかるものだ。ホフスタッターの法則を計算に入れても。

プログラマを管理することは、猫の群れを牧畜するようなものだ。

コードは開発現場で書くんじゃない！　納品先で書くんだ！ デバグは納期前にするんじゃない！　運用後にするんだ！！

それがあなたのマシンで動くかどうかは気にかけてない! 私たちはあなたのマシンを出荷していないのだ! Ovidiu Platon

複雑なバグと仕様は一体である。

で、それは何に使えるの？

「ダメなプログラマはコードに悩むが、優れたプログラマはデータ構造とその関連性に悩んでいる」 Linus Torvalds

デバッグ作業が、バグを取り除く過程であるならば、プログラミングとは、バグを入れ込む過程でないとおかしい。

水の上を歩くのも、仕様書通りにソフトウェアを開発するのも簡単だ。どちらも固まっていればの話だが。

もしそれがよい考えなら、思い切ってそれをしなさい。 許可をもらうよりも、謝るほうが簡単だから。

まず、他人を疑え、疑われた人が解決してくれるかもしれない。

JavaScriptにとってのJavaは、「カーペット」にとっての「カー」。

開発に終わりはない。リリースがあるだけだ。

私は、ソフトウェア設計には 二つの方法があるという結論に達した。 一つは、欠陥がないことが明らかなほど単純にする方法である。 もう一つは、明らかな欠陥がないほど複雑にする方法である。 　C.A.R.Hoare

人間、自分を磨き続けなければ、アホになってしまいます。