その分野で最高の人は、常に学ぶべきことがあることを理解している人です。
コーディングは進化する学問です。
最も需要のある言語を使いこなすだけでは十分ではありません。
ファインマン手法を使う
ファインマン手法とは、ノーベル賞を受賞した物理学者 Richard Feynman にちなんで名付けられたメンタルモデルです。
本質的には、教室で簡単な言葉や例えを使って概念を教えなければならないことを想像して、自分の知識のギャップを特定することに集約されます (このサブレディットの精神によく似ています)。
ギャップを見つけたら、本や知識の源に戻り、あまりよく知らない部分を独学します。
そして、繰り返し行うだけで、突然、コードに対するより強い中核的理解が得られ、より自信を持って実行できるようになります。
ソフトスキルを向上させる
ソフトスキルは、プログラミングに対するアンチテーゼのように思えるかもしれませんが (それが魅力の中心である場合もあります)、専門的な開発には欠かせません。
クライアントや上司とわかりやすくコミュニケーションし、自分自身や自分のアイデアを楽しく魅力的に伝えることができれば、職業生活の多くの側面が突然楽になることに気づくでしょう。
「物事を壊すことを恐れるな」
このアドバイスは、Kevlin Henney の優れた 97 Things Every Programmer Should Know に寄稿した多くの開発者やプログラミング専門家の 1 人である Mike Lewis のものです。
「業界での経験がある人なら誰でも、コードベースがせいぜい不安定なプロジェクトに携わったことがあるはずです」と Lewis は説明します。
「モジュールが追加されるたびに、コーダーの目標はできるだけ変更せず、リリースごとに息を止めることです」
変更を加えることが非常に神経質になる理由は、システムが病気であるためです。
「変更を加えることがこれほど神経質になるのは、システムが病気だからであり、医者を必要とし、さもなければ状態は悪化するだけだ」
物を動かしている間に何かを壊すという考えは、プログラマーはもちろん、どんなプロフェッショナルも物事を悪化させることを望まないので、不安に思われるかもしれませんが、もしあなたが物を壊すことに進んでいるなら、最終的に全体的に優れたコードになり、その結果より優れたコーダーになるはずです。
コードを 3 回書く
コードを書くことは小説を書くことと比較されますが、小説を書くのと同じように、最初のドラフトを完成品として自慢してはいけません。
初めてコードを書き終えるまでに、確かにそれは機能するでしょうが、うまく機能するでしょうか?
初めて書くときはコンセプトの証明、2 回目は動作させること、3 回目は正しく動作させることと考えてください。
一般にコードをたくさん書く
「練習、練習、練習」はプログラミング界に限定した格言ではなく、それなりの理由があります。
GitHubを使用してプロジェクトを表示し、他の開発者に作品を批評してもらい、異なるアプローチの方法について指導を受けることができます。
そして、最高のプロジェクトを印象的なポートフォリオにまとめれば、プロフィールの構築に大きく貢献します。
オープンソースのコミュニティに貢献することは、自分の分野でのつながりを築くだけでなく、自分とは異なる問題に人々がアプローチする方法についての洞察を得るための方法として、検討してみてください。
スティーブ サンダーソン氏が指摘するように、プログラマーは、ユニット テストをバグを見つけるための方法としてアプローチすべきではありません。
ユニットテストはテスト駆動設計の重要な要素です。プロセス全体に少し時間がかかるので、締め切りが迫ってパニックになっている場合は火に油を注ぐことになりますが、最終的には細部への注意を実証する、より質の高いコードになります。