使用するプログラミング言語、オペレーティングシステム、またはそれらが開発する環境に関係なく、すべてのプログラマは何を知っておくべきですか？
背景：
できる限り最高のプログラマになることに興味があります。このプロセスの一環として、私はわからないことを理解しようとしています。「[プログラミング言語を挿入]開発者が知っておくべきこと」という行に沿ってたくさんのリストがありますが、特定の言語に限定されない類似したものをまだ見つけていません。
また、この情報は他の人にとっても有益であると期待しています。
使用するプログラミング言語、オペレーティングシステム、またはそれらが開発する環境に関係なく、すべてのプログラマは何を知っておくべきですか？
背景：
できる限り最高のプログラマになることに興味があります。このプロセスの一環として、私はわからないことを理解しようとしています。「[プログラミング言語を挿入]開発者が知っておくべきこと」という行に沿ってたくさんのリストがありますが、特定の言語に限定されない類似したものをまだ見つけていません。
また、この情報は他の人にとっても有益であると期待しています。
回答:
プライドを飲み込み、ミスを個人的に認めずに認める方法。
専門家オタクプログラマーではなく、ユーザーのように考える方法。
いつ助けを求めるか、いつ助けを求めないか。
他の人のコードを読む方法。
これが私の10ビットです。
微妙すぎるかもしれませんが、「どの問題を解決すべきかを知る」と考えています。多くのプログラマー（および通常の人々）は、あまり重要ではないことを解決するために多大な労力を費やしています。または、多くの余分な作業を伴うソリューションを作成しますが、それは必要なものではありません。
リラックスする方法。それは生産性の秘密です。
最終的に、意志力とカフェインは十分ではありません。この絶え間ない収縮は、非常に有害です。
これは大したことです。
基本的なデータ型とアルゴリズム理論。Big O表記、配列、キューなどのようなもの
さて、ここに私の.02 $があります：
私はこれに少し遅れていますが、Edsger Dijkstraによって定められた知識で行きます。
数学的な傾向に加えて、母国語の非常に優れた習熟は、有能なプログラマーの最も重要な資産です。
良い段落を書けないなら、良いコードも書けない可能性があります。
if (BlowUpTheSystem = 1)。確かに、適切な単体テストが行われていれば、時間の節約になりそうです。しかし、時間は非常に重要です。
特定の技術、OS、または言語に過度に感情的になりすぎたり、執着したり、宗教的になったりしないでください。それぞれ異なるものが好きです。
車のように考えてください-あなたは以前に特定の車を運転したことがないかもしれませんが、それらはすべてキー、ステアリングホイール、アクセル、ブレーキを持っています-あなたはどこにあるかを整理したらすぐに乗り込んですぐに運転できるはずです。OSと言語を同様に扱い、特定のインスタンスの詳細に悩まされている場合でも、それらの基礎となる重要な概念の学習に集中してください。
そして、時間の経過とともに、視点を維持するのに役立つさまざまなテクノロジーの祖先、遺産、および共通性を理解し、評価してください。たとえば、進化のツリーは活発に分岐して行き止まりになっていますが、時間の経過とともにテクノロジーは「ベストプラクティス」と「規模の経済」を繰り返し収束する傾向があることを認識してください（例：Macは、最近のフードの下のPC ...）。
最後に、テクノロジーがどれほど楽しいものであっても、テクノロジーは本質的に、あなたの心が思い描くものと実際に作り出すものとの間の不完全なレンズを表していることを忘れないでください。最善を尽くし、学び、順応し続ける...
学習をやめる日は、もはやプログラマーではない日でなければなりません。
誰もソフトウェアを使いたくない。彼らは問題の解決を望んでいます。
コーヒーとIntelliSenseはあなたの親友です。
大きな複雑なオブジェクトを観察し、それを小さな単純なオブジェクトに分解して、再び同じタスクを実行する方法。
優れたUIデザインとコミュニケーション（別名グラフィック）デザインの基本。
デザインや使い勝手が悪いために、非常に多くのアプリやプロジェクトが台無しになっています。基本を学ぶだけで、世界に違いが生まれます。さらに、視覚的な問題解決技術（つまり、概念を視覚的に伝える方法）は刺激的な課題であり、新しい見方に目を向け、コードに影響を与えるはずです。
おすすめの本は、ロビン・ウィリアムズのThe Non-Designer's Design Bookです。
ここでは何ジョエル・スポルスキはそれを言います：
うわー！誰もがグラフィックデザインを行う必要があり、すべてのソフトウェアチームがプロのデザイナーの豪華さを備えているわけではありません。この優れた薄い本は、ページレイアウト、フォントなどの背後にある原理を理解するのに役立ちます。良いニュースは、水が冷える前に風呂で読むことができ、翌日、ダイアログボックスとパワーポイントとWebページの見栄えが良くなります。
私の頭の上から：
加算、減算、乗算、除算以外の数学を必要とするプログラミング問題はほとんどありません。微積分を使用して問題を解決することを考えている場合は、その前に選択肢を徹底的に調査してください。
何かがどのように機能するかについて推測しているときはいつでも、あなたはそれを間違っています。テレパシーになるのはあなたの仕事ではありません。
仕様を提供してくれる人は、あなたがそれをハッシュするまで、彼が望むものをすべて知っていることはめったにありません。
優れたプログラマーの半分以上は人間との関わりから来ています。チームとやり取りし、マネージャーを管理し、エンドユーザーに罰金を科すことは仕事の半分です。
優れたコードは、コンパイラーが読むのと同じくらい人々が読むように書かれています。
ベストプラクティスと実際の現実は、プログラマーが考えるよりも多く対立しますが、マネージャーはそうではありません。彼らが対立しているように見えるとき、対立を描き、理解し、それから実践に屈するのはあなた次第です。微妙で賢い解決策は、長期的に見てより費用対効果が高い場合、onlyくて野bruな解決策よりも優れています。
優れたツールは優れたプログラマーを作ることはできませんが、悪いツールは私たちを同じように恐ろしくさせます。
テクノロジーを軽視することはありませんが、常に最適な代替手段を探してください。
知っている言語が多ければ多いほど、使用している言語が上手くなります。
プログラミング指向の思考があなたの日常生活にゆっくりと忍び寄るのに邪魔されないでください。コンピューターを使用していないときでも、帯域幅の制限に悩まされ、タスクの切り替えによるパフォーマンスの低下が発生し、バックアップストレージからデータを読み込む必要があります。コンピューターは人間の思考を模倣することになっており、類似物はどこにでもあります。
他の人のコードを読むことはあなたの脳を台無しにするつもりはありませんが、むしろあなたがそのようにそれをしなかった理由を理解します（良いかどうかは別の質問です）。
これにより、プログラミングされたgedankenexperimentが得られ、時には誰かがより良い方法を実装している人を見つけることがあります！より良い方法で好きです。
この答えは、当然、独自のコードを読むことに拡張されます。したがって、バージョン管理とDIFFを使用するように拡張され、したがって42に拡張されます。