プログラマは曖昧な言葉で理解したつもりにならないほうがいい
C++やC#など、長年使われてきたプログラミング言語には、「どうしてこうなった？」と思うような不自然なデザイン（設計）がままある。こうした不自然なデザインは、「設計した当時はそれが最適解だった」からそうなったことが多い。後方互換性を維持続けなければならない言語は、かつて作ってしまった負の遺産を引き続き使い続けなければならない。
昔作られた、現在から見ると不自然に思えるデザインが生まれた理由を、「歴史的経緯」と呼ぶことがある。不自然なデザインそのもののことを、「技術的負債」などと言うこともある。
プログラマは、「歴史的経緯」とか「技術的負債」のような、漢字が連なる、何かを言っているようで何も言っていない曖昧な言葉に誤魔化されない方が良い。
例えば.NETの System.Text.UTF8Encoding。.NETのクラス命名ルールに従えば、Utf8Encodingとすべきなのに、UTF全てが大文字だ。書籍『.NETのクラスライブラリ設計』 によると、開発者はこの命名が失敗だと認めていて、その後追加したSystem.Buffers.Text.Utf8Formatterは「Utf8」という表記を採用している。（3.1.2 頭字語の大文字と小文字の使い分け）。
「なぜこのクラスだけUTF8と表記しているの？」という疑問に対し、もし「何か歴史的経緯で生まれた技術的負債なのだろう」と簡単に済ませていたら、開発者が失敗をどう受け止め改善したかに気づけない。「歴史的経緯」とか「技術的負債」のような曖昧な言葉の裏には、説明しづらい難しい出来事や、大っぴらには言いにくい失敗が隠れている。
プログラマは、技術用語を使って分かった気にならず、それを平易な言葉で説明できるまで理解を深めるべきだ。逆に言うと、曖昧な言葉の裏にこそ学びのきっかけが眠っているのではないだろうか。曖昧な言葉を自分の言葉でかみ砕いて理解する過程を繰り返していくことで、一流のプログラマになれるのかもしれない。
ようは、「正確な言葉を使え」、「過去の失敗に学べ」という単純な話。
平易な言葉を使うと、専門用語やスローガン、技術用語によって、欠陥を覆い隠せなくなる。嗜好がむき出しになる。曖昧な考えや、生煮えの考え、非論理的な考え、根拠のない考えがあぶり出される。