17,959 文字
私は人生で多くの開発者に出会ってきました。最近、最高の開発者になるには何が必要なのか、彼らに共通点は何かと自問しました。これが誰かの励みになることを願って、私たちの職業で最も優れた人々に見られる特性をリストアップしました。この情報を始めたときに持っていたらよかったと思います。この道に従っていれば、多くの時間を節約できたでしょう。
実際、これは非常に良いものになりそうです。人々はいつも近道を尋ねていますが、近道はないことを覚えておいてください。しかし、これはあなたに良い情報を与えてくれるでしょう。
リファレンスを読む。若いプログラマーとして、もしひとつだけやるべきことがあるとすれば、使っているものについてのリファレンスを読むことでした。例えば、Apacheウェブサーバーのドキュメント、Pythonの標準ライブラリ、TOMLの仕様などです。Stack Overflowに行ったり、LLMに質問したり、推測したりしないでください。直接ソースに向かいましょう。多くの場合、それは驚くほどアクセスしやすく、よく書かれています。
個人的には、ソースコードを読むのが好きです。定義にジャンプしてソースコードを見ることで、インターフェースを読むだけよりもはるかに明確に、物事がどのように機能するかについて発見できることがよくあります。そして、良い理解を得ることができます。私はいつもそれが好きでした。
Goライブラリでよくそうしています。gorillaを調べたことがあります。gorillaには文書化されていない機能がありました。それは、相手が送りたくないほど大きなウェブパケットを送信しないようにする方法です。なぜなら、理論的には誰かがウェブソケットサーバーを攻撃したいなら、8バイトのサイズのパケットを送るだけで済みます。「ほら、ギガワットのメモリを送りますよ」と言って、1と0を送り始めるだけで、それが10個あれば空間を埋め尽くし、マシンを破壊できるでしょう。
ウェブソケットでは、ヘッダーに最大サイズを設定していなければ、誰かを簡単にダウンさせることができます。ソースを調べて「あ、これだ、これだ」と見つけました。時間がかかりましたが、後で実際のドキュメントや将来の更新ポイントで見つけました。「これを発見しました」と言いました。コードを見ることでこの機能を発見したのです。とても明らかでした。そして後でドキュメントに追加されました。素晴らしかったです。「良い機能だった」と思いました。素晴らしい機能で、ソースコードを読むことでしか発見できませんでした。
優れた開発者は、使用する技術を根本的なレベルで理解しています。ツールを使えることと、それを本当に理解することは全く別のことです。単なるユーザーは手探りで、簡単に混乱し、間違った持ち方をして、設定を最適化しません。専門家はリファレンスを読んだ後に座り、ツールの設定を書き始め、その設定の各行を理解し、同僚に説明することができます。それは疑問の余地を残しません。
完全に公平を期すと、たとえツールを本当に理解していても、私はいつも疑問を持つでしょう。なぜなら、書いている内容には、理解していないかもしれない影響があるからです。
Grockは彼のお気に入りのプログラマーです。その通りです。その通りです。
ツールをよく知るには、その歴史を知る必要があります。誰が作ったのか、なぜ、どんな問題を解決するために作られたのか。
こう考えてみましょう：それがいつ当てはまらなくなるのか？プロジェクトの現在の状態を理解するために、常に元の意図を理解する必要がありますか？反例を挙げましょう：Linuxは可能かどうか見るためのサイドプロジェクトとして開発されました。ちょっとした趣味で、どこにも行かないと思われていました。それを知る必要はおそらくないでしょう。
Gitは、名前を挙げていない（技術的には名前は出ていますが）メンバーの一人がBitkeepersのプロトコルを弄ったためにライセンスが破られ、それ以上Bitkeepでリポジトリを保存できなくなったために発明されました。そこでLinusは『ミーン・ガールズ』の公開から1年後の数日でGitを作り出しました。Gitが『ミーン・ガールズ』と同じくらいの年齢だということを覚えておいてください。おかしいですね。
誰が維持しているのか、彼らはどこで働いているのか、何に取り組んでいるのかを知ることは興味深いことです。これは良い質問です。彼らはアクティブなメンテナであるか非アクティブか、どこで働いているか知ることは良いことです。これは自問すべき良い質問です：彼らがそれを維持している動機は何か、これは仕事関連の動機なのか、物事を要求したり貢献したりできるのか。
2016年にflatbuffersリポジトリに貢献するためには、Googleの「オープンソースプロジェクトに貢献します」という権利放棄書に署名しなければなりませんでした。これは実際にあったことです。もしオープンソースのものが本当に素晴らしいと思い、貢献しようとすると、その会社で働いていない人からの貢献を許可していないことがわかるかもしれません。それを知っておくことは良いことです。
そのツールの限界、適していないとき、破綻するときなどを知ることも常に良い答えです。そのエコシステム、どんなライブラリが存在するか、誰が使っているか、どんなプラグインがあるか。必ずしもすべてのツールにライブラリが必要なわけではありませんが、彼が言おうとしていることは理解できます。
依存関係を理解し、拡張可能であればどのように拡張されるのか、なぜ拡張されるのか、どのような拡張があるのかなど、これらはすべてツールについて理解すべき良いことです。これらすべてを知る必要があるとは思いません。おそらく決定を下す際の視野によって異なるでしょう。
個人プロジェクトでただ自分のものを作り、OAuth 2ライブラリを使って一部の機能を実装したいとしたら、これらすべての情報を知る必要があるでしょうか？おそらくないでしょう。おそらくGoogleで検索して最初のものを掴んで終わりにするでしょう。ここでコンテキストが重要です。もし会社のためにその決断を下すなら、する前にもう少し知っておいた方がいいかもしれません。
例えば、バックエンドエンジニアとしてCFKAを多用するなら、Redditで読んだことだけでなく、CFKAについて多くを知っていることを期待します。少なくとも、あなたが最高のエンジニアの一人になりたいのであれば、それが私の期待です。
興味深いですが、この発言に完全に同意するかどうかはわかりません。ツールを十分に使う場合は、そのソースコードを読み始め、それがオープンソースである限り、より深いレベルで理解しようとするべきだと思います。それは良い教訓です。しかし、CFKAを誰が作ったかを知る必要があるとは思いません。偉大なエンジニアであるためには、そのようなことは重要ではありません。
プロジェクトを誰が維持しているかを知る必要もないと思います。その限界を知る必要はあると思いますし、そのエコシステム、どれくらい早く貢献されているかを理解することは重要だと思います。あまりにも具体的に感じます。少しばかり具体的に感じます。
エラーメッセージを読む。本当にエラーメッセージを読んで書かれていることを理解しようとしてください。エラーメッセージについて座って瞑想すると、それが話し始めることがわかります。最高のエンジニアは非常に少ないコンテキストから多くの情報を推測できます。エラーメッセージを読むだけで、ほとんどの問題を修正できます。
このスキルを持っていない人を助けると、超能力のように感じます。カップから読むというのはよく分かりませんが、カップから飲むことしか理解していません。古いインターネットネタですね、カップから飲むとか。
エラーを読む技術はありますが、プロジェクトのコンテキストを持つ技術もあります。完全に新しいプロジェクトで完全に新しいエラーを与えられたら、いくつかのことを推測して、おそらくそれなりの仕事ができるでしょう。しかし、プロジェクトのコンテキストがあれば、そのエラーのほんの少しの情報でもずっと理解が進むでしょう。
エラーメッセージの読み方を学ぶべきだということには同意します。C++テンプレートメッセージ以外は全て。そこでは目を閉じてLLMに渡しましょう。見たくありません。
問題を分解する。誰もが時々行き詰まります。最高の人々は行き詰まりから抜け出す方法を知っています。彼らは問題を消化できるまで単純化します。それは学ぶのが難しいスキルで、多くの経験が必要です。あるいは、素晴らしい問題解決スキルがあれば、つまり頭がいいということです。
そうでなければ、それを訓練することができます。しかし、難しい問題を分解する方法を回避する方法はありません。この世界には、誰にとっても一度に解くには難しすぎる問題があります。そのとおりです。
私たちがデッキとのインタラクションに関して作っているゲームでは、UIを良く感じさせながら状態遷移とアニメーションを維持する方法という問題があり、これは本当に難しかったです。そこで、私は実際に問題を分解し、Xcalirawで貧弱なシーケンス図を作成し、「これはどのように見えるか、この問題をどのように進めるか、それはどのように見えるか」と考えました。そして今、私ははるかに良いアイデアを持っています。
私には問題を解決する元の方法がありました。そして、問題を完全に異なる方法で解決できることに気づきました。私はすでに一度問題を書き、解決しようとしましたが、その進め方が好きではありませんでした。良い感じがしないし、物事も本当に機能しません。
常にこのようにソフトウェアを設計できるとは思っていません。これはまれなことです。私は問題空間を知っており、すでに一度解決しましたが、今度はより良い方法で解決しようとしています。いくつかのことは、問題を分解する時間をかければより良くなります。これは非常にまれなことで、めったにしません。かなり複雑な問題である必要があります。
通常、プロフェッショナルな開発者として働いている場合、それがあなたが報酬を得る仕事の大部分です。問題を分解することです。それを正しく行えば、ズルのように感じるでしょう。
単純な問題を解決し続けるだけで終わりです。プロフェッショナルな開発者と言うのは少し馬鹿げています。ソフトウェアで働くなら、あなたの仕事全体は大きな問題を小さな問題にすることです。それがソフトウェアのすべてです。
どうやってゲームを作りますか？ゲームはさまざまなものに分けられます。デッキについて考えたいです。デッキはどのように機能しますか？ゲーム状態とUIデッキの間の相互作用が必要です。ズームインしましょう。アニメーションとタイミングはどうやりますか？ズームインしましょう。
状態がどこにあるかを正確に知り、それが再現可能であるように、JSONにシリアル化して再水和できる方法でどのように通信するか、次々と解決していきます。「これを解決し、次のことを解決し、次のことを解決する」とどんどん進み、完成です。
レンダリングはどうやりましたか？非常に複雑なメニューがあり、DOMに似たものを構築しました。DOMはどのように機能しますか？それはツリーのようなものです。レンダリングはどのように機能しますか？下方向にレンダリングします。更新はどうなりますか？そして、この複雑なものをゆっくりと構築し続け、フレックスを持つレイアウトライブラリ、中央揃え、境界、アニメーションを持つところまで到達しました。そこから始めたのではなく、そこに終わりました。
手を汚すことを恐れないでください。私が知る最高の開発者たちは多くのコードを読み、それに触れることを恐れません。彼らは「それは私のものではない」とか「ここであなたを助けられない」とか「そこであなたを助けられない」とは決して言いません。代わりに、彼らはただ始めて学びます。コードはただのコードです。彼らは時間と努力をかければ、必要なスキルを身につけることができます。
これは良い発言です。時間と努力をかければ何でも身につけることができます。正直に言って、許可を求める開発者に人生で何人も会ったことがあります。彼らは、インターネット上で「学ぶためには大学に行かなければならない」と言う人々を聞いて「では学べないんだ」と思う人たちと同じです。「兄弟よ、なぜゲートキーピングされているのか」というだけです。
黙って、ただ物事を始めましょう。あなたが聞くすべてのことを終わりとして聞くのをやめてください。いつも許可を求める必要はありません。ただスキルを身につけて学ぶことができます。それは許可されているのです。
知らないうちに、彼らはチームでの中心人物になります。主に、彼らがそれに触れることを恐れなかった唯一の人だったからです。
私は何度かGroovyの話をしましたが、Netflixでの私の最初の成功はすべてそこから来ています。誰もGroovyに触れたくなかったのです。誰もNetflix UIの中間部分をやりたくありませんでした。そこで私は何に志願したのでしょうか？もちろん、それに志願しました。誰もやらなかったからです。だからあなたがそれをやるのです。難しくありません。「解決できる、解決できる」と思うのです。
常に他者を助ける。関連する点として、優れたエンジニアは需要が高く、常に忙しいですが、常に助けようとします。それは彼らが自然に好奇心が強く、支援的な心を持っているからです。彼らを優れたエンジニアにしたのはその支援的な心です。
それが本当かどうかはわかりません。Linusを非常に支援的なエンジニアと呼ぶでしょうか？それは議論の余地があります。彼を優れたエンジニアと呼ぶでしょうか？絶対にそうです。他人を助けたいという欲求が優れたエンジニアの印だとは言えないと思います。
彼は非常に積極的にサポートします。彼が誰と関わっているかを考慮する必要があります。宇宙で最も賢い人々の一部とRust開発者です。誰かからメールが来るでしょう。「ファリーを再び馬鹿にするな。それはとても無礼だった」と。
私はこれにポイントがあると思います。企業環境で非常に成功する方法は「最も助けになる人になろうとする」ということです。これが私の読み方です。また、ただ良い方針として嫌な人にならないことです。これはより個人的なノートです。私は嫌な人として人々に対応しないようにしています。
インターネット上の人間として、私は1日に1〜15のヘイトメッセージを受け取ります。どうするか知っていますか？ミュートするだけです。それだけです。ただミュートして気にしないだけです。
最も素晴らしいエンジニアは話がうまく、知識を共有することを喜びます。最高の人たちは自分の考えのはけ口を持っています。ブログ、講演、オープンソース、またはそれらの組み合わせです。
私はこれに完全に同意しません。優れたエンジニアになるためにこれらのことをする必要はないと思います。実際、これはTwitterのウイルスのようなもので、広がっているような気がします。Reactが登場し、大きなカンファレンストークがあり、みんながカンファレンスに夢中になった2014年、2015年頃の企業のウイルスのようなものです。そして「カンファレンストークをしなければならない」というものになりました。
公共での話し方はあなたの魂にとって良いと思います。そしてそれをするべきです。公共での話し方をするべきです。それはあなたを優れた人にするからではなく、不快な状況に置き、実際にはそれがそれほど悪くないことを学ぶからです。それだけです。とても単純です。
非常に異なる動機です。このようなことをすることはあなたにとって良いと思いますし、書き方を学ぶことは良いと思います。なぜなら、あなたの考えを考え、それらをどう伝えるかを理解することが良いからです。非常に異なる動機です。
しかし、これのどれもする必要はないと思います。優れたエンジニアになるためにはどれも必要ありません。それをすることには利点がありますが、それだけです。
あなたは自分自身のために書くことができます。その通りです。
書く能力とプログラミングの間に強い相関関係があると思います。私は全くそう思いません。なぜなら、私の書く能力はひどいですが、自分が平均以上のプログラマーだと思いたいからです。それだけです。自分は平均以上だと思います。
私が知る最高のエンジニアたちは、少なくとも一つの人間の言語に対する良い指揮権を持っています。
実際、私はLinkedInで英語を「かろうじて熟練している」、主要言語をJavaScriptとしています。おもしろいと思ったからです。今振り返ると、それが仕事の機会を妨げたかもしれませんが、誰が知っていますか。
あなたが書く方法をマスターすることは、あなたが考える方法をマスターすることであり、その逆も同様です。
それが本当かどうか疑問です。これはある種の…私は、あなたが伝えたい媒体でうまくコミュニケーションする方法を学ぶことは非常に良いことだと思います。しかし、書くこととプログラミングの間に何らかの強い相関関係があるとは思いません。それらは非常に異なるスキルであり、非常に異なる思考方法を用います。
今私がしていることのように話すことも同様です。私はそれがまあまあできると思います。思考を保持し、十分なコンテキストウィンドウを持ち、あらゆることをナビゲートし、時々ある種のポイントに戻ることができると思います。しかし、それは私のプログラミングスキルとは全く関係がないと思います。
おそらく、長いコンテキストウィンドウを持っていると主張することもできるでしょう。脳内で何が起こるのかわかりません。もしそれが私をユニークにしているなら、それも私がプログラミングが得意な理由かもしれません。しかし、それらは必ずしも関連しているわけではありません。それらは私をユニークにしているものの偶然の一致かもしれません。あるいはそれはユニークでなく、誰もがそれを持っており、私は単に愚かなだけかもしれません。わかりません。
これらのことについてあまり規範的にならないようにしています。それらについて記述的であることがより良いと思います。つまり、書くことでうまくコミュニケーションできれば、論理的な思考を形成する良い能力を持っているでしょう。それだけです。しかし、それだけが唯一の方法ではありません。もっと記述的です。
考えを考えるのが得意なら、おそらくよく考えられた考えを持っています。はい、その通り。ハイファイブ。素晴らしい。
優れたプログラマーは言葉を弄ぶことに喜びを見出します。
全くそう思いません。私は言葉を弄ぶのが好きではありません。何も望みません。
この文脈で自分が優れたプログラマーであると仮定しています。実際、本音を言うと、自分の屁を嗅いだり、自分のクールエイドを飲んだり、何と呼ぶにせよ、私はプログラミングにかなり優れていると思います。それにもかかわらず、私は言葉が嫌いです。
自己を賞賛しています。男、私はそれをしています。なぜなら、私が今まで見た中で最高のプログラマーと一度働いたことがあり、彼は決して多くのことを書き留めませんでした。彼を優れた作家のカテゴリーに分類しませんが、彼はプログラミングがとても上手でした。
学ぶことを止めない。これが好きになると既に予感しています。
私が知る最高の開発者の何人かは60歳以上です。彼らは私の周りを走り回ることができます。その理由の一部は、彼らが学び続けることです。もし彼らが試していない新しいツールや気に入った言語があれば、彼らはそれを学びます。このように、彼らは多くの努力なしに常に最前線にいることができます。
アンクル・ボブはある意味でこの良い例だと思います。私が彼や「クリーンアーキテクチャ」を全面的に賞賛しているわけではありません。そのようなものの大ファンではありません。それにもかかわらず、彼はサイドクエストでclojureに取り組み、lisp方言を愛しています。そこには何か涼しいものがあると思います。
「私はJavaの人間だ。Javaのことをやる。デザインパターンを使う。また、完全に型のない言語や、完全に違うスタイルで純粋に関数型のものも使う。なぜなら、それを調査するからだ」と。それはかなりクールだと思います。それは良いメンタリティだと思います。
それは当然とは言えません。多くの人々は大学卒業後や最初の仕事を始めた後、非常に早く学ぶことをやめます。
同意します。一部の人々には、頭の中に目的地があり、「大学を終えたら、専門の開発者になり、準備しなければならず、準備が終わったら、今はただプログラミングするだけ」という考えがあります。そうではないのです。
学ぶことを掛け合わせる仕事をなぜ持つのか、もっと全体的に考えるべきです。学ぶ意欲がないのなら、なぜそのような仕事をするのですか？プログラマーであることの最も素晴らしい側面の一つは、毎日何かを学ぶチャンスがあることです。あなたのスキルを掛け合わせるチャンスがあります。これは仕事に関しては一般的ではありません。ほとんどの人の仕事はそのようなものではありません。
彼らは学校で教えられたことが物事を行う正しい方法だと考えています。私もそうでした。もちろん、誰もが間違っていることを学ぶまでそうします。
大きな空のソフトウェア。私たちは業界の最新トレンドを見つけ、その反対のものを構築します。さあ、これが友達、これがソフトウェアです。ちなみに、それはHTMXです。
精神的に引退している25歳と、まだ心が新鮮な68歳がいます。私はいつか後者のグループに属することを目指しています。
ここには逆の問題もあります。これが悪いことなら、良いことは「新しいものはすべて良く、時間を費やす価値がある」ということになりますよね？その文を反転させると、それは良いカテゴリーに入るでしょう。しかし、私はそれも信じているとは思いません。新しいものも良いとは思いません。
プログラマーとして持つべき適切な考え方は「すべてはくだらない」ということです。すべては不便です。あなたに与えられたものに対処するか、自分で書いてそれに対処するか、それだけです。
関連して、最高のエンジニアはトレンドに従わず、常に新しい技術の利点を慎重に評価します。それを却下する場合、なぜそうするのか、その技術がいつ良い選択肢になるのか、どのような代替案があるのかを正確に説明できます。
私にとっては非常に簡単です。「それはTypeScriptか？」と見て、「そうだ」と言えば、簡単です。
最高の開発者は主任エンジニアもジュニアにも同じように話します。階層はありません。彼らはすべての人から学ぼうとします。若い人も年配の人も。新参者はまだオフィスの政治に巻き込まれておらず、まだ新鮮な心を持っています。彼らは物事が難しい理由を知らないので、創造的な解決策を提案します。過去の障害がもう存在しない可能性もあり、これらの人々はインスピレーションの素晴らしい源になります。
ここで興味深い例を挙げましょう。人々は常にこれをしており、地位は実際に重要です。今、反対意見を述べますが、例を出します。
あなたが非常に忙しく、締め切りが迫っているとします。例えば、Schmetflix（Netflixのもじり）という会社で働いているとして、トイレから机に向かって歩いているとき、新入社員がやってきて「ちょっと、20分ほど話を聞いてもらえますか？」と言ったとします。あなたは「喜んで聞きたいけど、今は何かをしないといけないので、明日か将来の予定に入れてもらえますか」と言うでしょう。
まったく理にかなっていますね。では、Schmetflixの CEO である Shmeed Schmastings（Reed Hastingsのもじり）があなたに近づいてきて「ちょっと、20分ほど話を聞かせてもらえないか」と言ったらどうでしょう。あなたは Schmastings 氏にスケジュールを入れるように言いますか、それとも「今20分ありますよ」と言いますか？
現実には、人々は地位を重要視することがあり、時にはそれが良いことかもしれません。
彼が言おうとしていることは、純粋に問題を解決するためには、それぞれが独自のコンテキストを持っているため、誰にでも独自に対応できるのが良いということです。しかし、すべてを新しいビルドシステムで書き直すことを提案するインターンと、「それはやめよう」と言う主任エンジニアがいたら、私はおそらく一方をより高く評価するでしょう。両方の話は聞きますが、一方の地位は実際にもう一方よりも重要です。
地位が重要である理由は、誰もが平等な投票権を持っていたら、純粋な混乱になるからです。優先順位があり、階層があります。それはOKです。それが期待することです。良い会社であれば、意思決定が上手な人を上位に置くことを期待します。それが常にそうではないことは皆理解できますが、それが機能する方法です。
私はタイトルに聞き入りすぎることがあります。そして、時にはタイトルに耳を傾けることが良いこともあれば、悪いこともありますが、それらは重要であり、いつそうするかを知るべきだと思います。
評判を築く。地位が重要でないなら、なぜ評判を築くのでしょうか？良い仕事をすれば堅実なエンジニアになれますが、より大きなグループや組織内で少なくとも良い仕事で知られていなければ、最高の一人にはなれません。
これには何か不幸なことがあります。良いエンジニアリングをただやるだけで、報われない優れたエンジニアがたくさんいます。ここで良いマネージャーが本当に役立ちます。あなたのために戦ってくれる人がいて、心配する必要がないなら、それは健全な組織です。
自分の評判を築くには多くの方法があります。大きな組織のために重要なサービスを構築して出荷した。有名なツールを書いた。Brewを書いた人のことを考えてください。そしてGoogleに二分木を反転できなかったために拒否されました。人気のあるオープンソースツールに貢献した。本当であり、そうでもあります。よく言及される本を書いた。
彼は一度も「Twitchで馬鹿なことを言ってYouTubeビデオを作る」とは言いませんでした。この記事は何についてのものなんですか？なぜ他の形態のメディアに言及しないのでしょうか？誰が本を書きたいと思いますか？なぜあなたの仕事で知られることが重要だと思うのですか？
上記のすべては、コミュニティでの影響範囲を拡大する方法です。有名な開発者は有名でない開発者よりもはるかに影響力があります。
でも、それは必ずしも良いことではありません。影響を与える必要があるとは思いませんし、それが目標であるべきだとも思いません。現実には、インターネット上で有名でバカなことをする人がいます。名前は挙げませんが…
これはフォロワーが多いからといって、インターネットで聞くすべてのことを聞くべきだということを意味するのでしょうか？それはアイデアをフィルタリングする良い方法ではありません。
ちなみに、TJのことを言っていました。
あなたが書くことができるコードには限りがあります。影響力を拡大したいなら、思想的リーダーにならなければなりません。
その必要はないと思います。影響力を拡大することの意味とあなたの目標が何であるかを評価する必要があると思います。これは物事を行う一つの方法にすぎません。
いわゆる「思想的リーダー」になることが常に素晴らしいわけではないことも理解する必要があります。意見を持ち、100人以上があなたの意見を好きになった瞬間、人々はあなたをナチスと呼ぶこともあります。それも対処しなければなりません。
ただそれが人生の一部だからという理由で、職場であなたを嫌う人々に対処しなければならないでしょう。「思想的リーダー」であるということの一部として、積極的にあなたに反対する人々に対処しなければなりません。
これは自由なトレードオフではありません。「思想的リーダーになりました。すべてが素晴らしい」というわけではありません。そんなに素晴らしくないかもしれません。あなたがすることすべてが顕微鏡の下に置かれます。
もし冷静さを失ったら… 匿名である素晴らしさの一つは、時々冷静さを失っても誰も気にしないことです。あなたがTikTokでウイルス性になり、職を失う不運なカレンがいるかもしれません。それは起こりますが、多くの人々は毎日冷静さを失っていて、誰も気にしません。それは持つべき素晴らしい特権です。
公共の場で精神崩壊したら… それは素晴らしいでしょう。
評判を築くことは長期的な目標です。一晩で起こるものではなく、またそうである必要もありませんし、偶然に起こるものでもありません。毎日現れて仕事をすれば、時間とともに仕事が自分自身を語るようになります。より多くの人があなたとあなたの仕事を信頼し、あなたと一緒に仕事をしたいと思うでしょう。
面白いことに、たとえすべての仕事をしても、あなたの評判は「コネ入り」だという非難を受けることがあります。何かの成功を手に入れたと非難されます。すべての仕事をしても、依然として完全に批判されることがあります。
これは必ずしも素晴らしい提案ではないかもしれません…
より多くの人があなたとあなたの仕事を信頼し、あなたと一緒に仕事をしたいと思うでしょう。あなたはより名声のあるプロジェクトに取り組み、あなたのサークルは成長するでしょう。
以前に行ったことすべてを最新の仕事が上回るべきだという考えについて聞いたことがあります。それはあなたが正しい道を歩んでいる良い兆候です。
それは古い「部屋で最も賢い人になるな」というフレーズを思い出させます。その文の問題は何でしょうか？誰かその問題を教えてくれますか？簡単にします。
部屋があるとします。その部屋の中に人々を入れました。やった！彼らはそこにいて、チャットしています。すべて素晴らしいです。この人は部屋で最も賢い人です。彼は部屋で最も賢い人になりたくありません。だから彼は何をするのでしょうか？彼は去ります。今、残っているのは2人だけです。残念ながら、ビルも部屋で最も賢い人になりたくありません。だから彼は何をするのでしょうか？彼は去ります。
次に何が起こるでしょうか？この人が部屋に残された唯一の人であり、数学的基準では部屋で最も賢い人でもあり、最も愚かな人でもあります。だから彼も去ります。
人々が部屋で最も賢い人になりたくないなら、最終的にはすべての部屋が空になるでしょう。
あなたは私に再帰を説明しました。私は再帰を説明しました。また、愚かな原則も説明しました。あなたは人々が自分が最も賢いことを知っていると仮定しています。その通りです。しかし、それがあなたの目標なら、それが起こることです。
部屋のゲーム理論的な見方です。その通りです。私はゲーム理論をしています。そのような文句が好きではありません。そして、この文句はおそらくその下に入ります。
最も初級のタスクが、しばしば最も上級の人々によって完了する必要があります。なぜなら、スキルを20年以上磨いた人には何か特別なものがあり、彼らは初級者によって面倒で軌道を外れる可能性があるとみなされるものを我慢して解決できるからです。
あなたがする次のことが、前にしたすべてのプロジェクトを上回る必要があるでしょうか？そうは思いません。
100％従うことができる唯一の格言は「黄色い雪を食べるな」です。その通りです。絶対に。人生の事実です。
忍耐力を持ちましょう。これが好きです。これが進む方向が好きです。
コンピュータと人間、特に自分自身に対して忍耐力が必要です。すべてがすぐに機能するわけではなく、人々は学ぶのに時間がかかります。あなたの周りの人々が愚かなわけではありません。彼らはただ不完全な情報を持っているだけです。
一部は愚かです。あなた自身が愚かかもしれません。あなたが会う人々の半分は、知能曲線の後半に位置している可能性があり、あなた自身もその後半に位置している可能性があることを覚えておいてください。
忍耐力がなければ、世界があなたに対抗しているようで、あなたの周囲の誰もが無能だと感じるでしょう。それは悲惨な場所です。あなたは自分自身のためには頭がよすぎます。
最高の一人になるためには、信じられないほどの忍耐力、集中力、献身が必要です。簡単に気が散るわけにはいきません。難しい問題を解決したいなら、それを乗り越えるためにキーボードに戻らなければなりません。仕事をして、プロジェクトを完成させる必要があります。そして、傲慢な嫌な奴にならずにそれができれば、それはさらに良いことです。それが最高の人々と他の人々を区別するものです。
プロジェクトを完成させることは難しいです。これには皆同意できるでしょう。開発者の好きな暇つぶしは、後で放棄するプロジェクトを作ることです。
ここで彼が言ったことはとても素晴らしいです。プロジェクトを完成させることは本当に難しいことです。「完了」をどう定義し、それを実際に完了した状態に持っていくにはどうすればよいでしょうか？
決してコンピュータを責めないでください。ほとんどの開発者は、不安定で一見ランダムなバグに対して、ソフトウェア、他の人々、彼らの犬、または天気を責めます。最高の開発者はそうしません。コンピュータの振る舞いがどれほど不規則または悪意に満ちているように見えても、常に論理的な説明があります。あなたはまだそれを見つけていないだけです。
最高の開発者は、理由を見つけるまで掘り続けます。彼らはすぐに理由を見つけられないかもしれません。彼らは決して見つけられないかもしれませんが、彼らは決して外部の状況を責めません。この態度で、彼らは信じられない進歩を遂げ、他の人々が失敗することを学ぶことができます。バグを理解不能な魔法と間違えると、それは常に魔法のままでしょう。
そうですね、もちろん。それが魔法だと思うのは愚かでしょう。魔法はありません。ほとんど常に何らかの競合状態です。
しかし、本当のところ、ひとつのことを付け加えたいと思います。最高の開発者になるためには、あなたが何らかの形で関わっているソフトウェアに問題やバグがある場合、それは自分の問題だと考え、そこから始めるべきだと思います。それはあなたを非常に良いチームメイトにし、一緒に働く相手にします。
何か問題が起きたとき、通常、私たちのゲームで何かが壊れると、自分の仕事でなくても、それは私の問題だと仮定します。そうすれば、すぐに助け、すぐに診断しようとします。そして、それが自分ではないとわかったとき、TJをからかうことができます。あるいは逆に、それが自分だった場合、TJが私をからかうことができます。
それは楽しい時間です。それは良い働き方です。常に責任を受け入れ、それが自分ではないとわかったとき、楽しんで知っている人やおそらく好きな人をからかうことができます。
「わからない」と言うことを恐れないでください。私はおそらく就職面接でこれをよく言いすぎています。面接の候補者に少なくとも一度「わからない」と言うよう強く促します。そうする必要はないと思いますが…
その理由は、私が優れているように見せたかったからではありません。確かに、一部の人々はそのような印象を持っていましたが…そうするのは難しくありません。なぜそのようなことが起こるのかは、あなたがそのようにするとき、それは目標であるべきではありません。
面接の本当の目標は、人に話をさせることで、その人がどれだけ知っているかを見つけることです。それは良いソフトウェアエンジニアリングの面接を測る一つの素晴らしい方法です。唯一の方法ではありませんが、一つの方法です。
誰かが彼らがやったことについて情熱的に説明し続けるのを聞きたいです。なぜ彼らが独自のHTTPサーバーを構築したのかを情熱的に説明してほしいです。なぜかは気にしません。その仕事では役に立たないかもしれませんが、彼らが何かをして、それを続けて続けたことを聞きたいだけです。
いいえ、私は彼らの知識の境界に到達したかったのです。彼らが知っていると思っていることの端に彼らと立ちたかったのです。
ここにも何かがあります… この文を書いている人が意図的にこのように見えようとしているとは思いませんが、あなたが誰かをその地点に連れて行けると思うとき、あなたは彼らよりもソフトウェアについて多くを知っているという仮定もしています。根本的にあなたは、人をその地点に連れて行くのに十分な知識を持っているという仮定をしています。
おそらく質問を続けるだけで、それがうまくいく方法があるかもしれません。そこには真実であるかもしれないことと、そうでないかもしれないことがあります。
しばしば私自身が答えを知りませんでした。そして正直に言って、答えについては気にしませんでした。気にしたのは、人々が面接で嘘をついたときです。
あなたが答えを知らないなら、彼らが嘘をついているかどうかをどうやって知るのですか？時々、良い嘘つきに会ったことがありますか？
私はNetflixの面接を通過しました。面接の一つは、本当に難しいRxJSの質問でした。ちょうどRxJSを見始めたところで、それについて何か言って、それが面接の理由だと思います。そのため、この本当に難しい質問を受けました。
私は何をしましたか？そうですね、嘘をつきました。必死に言い、面接官に対して本当に深く入り込み、彼は私たちが一緒に話していたので、ただ答えを教えてくれました。
「そうそう、それが言いたかったんです。select manyですね、すごいですね、インターフェースは… 一瞬忘れましたが、戻り値はobservableですか、それともobservableのリストですか？ちょっと…」とただ続けて、続けて、エンジンをかけ続けて… それは素晴らしかったし、うまくいきました。
最高の候補者は「ふむ、わかりません、でもそれは興味深い質問ですね。推測するなら…」と言い、答えを導き出すでしょう。それはあなたが素晴らしいエンジニアになる可能性があるという兆候かもしれません。
「わからない」と言うのは良いことだと思います。「わからない」と言うことには非常に良いものがあると思います。人々はそれを言うべきではないと感じています。なぜなら、それは彼らを愚かに見せるからです。そうです。しかし、それはOKです。あなたは特定のカテゴリーで愚かなのです。それはOKです。一部のカテゴリーで無知であることはOKです。
「わからない」と言うことを恐れているなら、あなたは傲慢さや防御的な立場から来ています。私のチームに嘘つきは要りません。あなたがすべてを知ることができないことを認めるほうが良いです。それを受け入れると、学ぶことができるようになります。重要なのは、質問することをやめないことです。アルバート・アインシュタインが言ったように。
前提は好きですが、彼がそれを出す方法は好きではありません。これは私にとっては、その面接も好きではないだろうということに感じます。
曖昧な状況では推測を拒否してください。これは私のお気に入りのルールの一つです。Pep 20、Zen of Pythonからのものです。
私はいつも推測します。反対のことをします。実際、良い製品を作る方法は推測することです。
それらはとても魅力的ですね。私も何度もそこにいて、自分の野心で失敗しました。推測すると二つのことが起こる可能性があります。最良の場合、あなたは間違っており、間違った仮定がバグにつながります。最悪の場合、あなたは正しく、二度と自分自身を疑うことはありません。間違った仮定に基づいて精神的モデルを構築します。これはあなたを長い間悩ませる可能性があります。
これは特定のソフトウェアとバグ修正についてのものだと思います。なぜなら、バグを修正するときでも、私はまだ推測します。情報を取り入れて、「起こっていることについての私の最良の推測は、この部分が更新を受信していないということです。それを証明しましょう」というようにします。
良いデバッグはすべて良い教育的な推測から始まると思います。わかりません… だから、彼が言おうとしている原則が何なのかよくわかりません。ここに私がおそらく正しく読んでいない何かがあると思います。「推測して進んで、二度と確認しない」ということなのかもしれませんが、一度は実行しなければなりませんよね？推測して間違ってバグにつながることがあるのでしょうか？わかりません。
とにかく、推測する衝動に抵抗し、質問し、リファレンスを読み、デバッガーを使用し、徹底的にし、答えを得るために必要なことをしましょう。
そうですね、その通りです。
シンプルに保ちましょう。賢いエンジニアは賢いコードを書きます。例外的なエンジニアはシンプルなコードを書きます。
賢い問題は時々賢い解決策を必要とします。シンプルな問題は時々賢い解決策を必要とします。複雑な問題は時々シンプルな解決策を必要とします。シンプルな解決策は時々シンプルな問題を必要とします。
すべてがそうであるとは思いません。「良いエンジニアだけがシンプルなコードを書く」というような規則が存在するとは思いません。わかりません。
時には物事は非常に難しいです。たくさんのツリーウォークをしたことがありますか？時にはそれらは難しいです。それがそのやり方です。それは難しいのです。問題を理解することが本当に難しいのです。
良い例をひとつ挙げましょう。私がしばらくの間維持していたオープンソースプロジェクトの一つでは、実質的に二つの別々のツリーの補集合、あるいは正確には違いが必要でした。
基本的に、生成された二つの異なるツリーがあり、あなたはツリーを作成する必要がありました。これが補集合です。右側、その部分が欲しいです。これが補集合です。
二つのツリーの補集合を計算する必要があります。それは難しいです。なぜあなたの尻は奇妙なのか、あなたの頬が時間と空間で重なり合っているのか。それは尻ではありません。それは全く別のものです。なぜあなたの頬は互いに交差しているのですか？
これを二つの異なるツリーで行う必要がありましたが、ツリーは「0から10まで」のような配列として指定されていました。これがなぜ非常に難しい問題であるか想像できると思います。
問題を深く理解し、この部分を取り出す能力以外にシンプルな解決策はありません。シンプルな解決策はありません。
最後の考え。上記はチェックリストや競争ではありません。偉大なエンジニアはレースではありません。困難な仕事をスキップできると自分を騙さないでください。近道はありません。あなたの旅に幸運を。
素晴らしいエンディングです。素晴らしいエンディングが大好きです。本当に素晴らしいエンディングです。大好きです。
そのエンディングは本当に素晴らしいです。なぜなら、それは真実だからです。近道はありません。何もありません。どんなリストも包括的ではありません。すべてはそれぞれの状況でユニークになります。ただ一生懸命働きましょう。
そして、私が人生で何度か言ったように、一生懸命働いて賢くなりましょう。「賢く働け、一生懸命働くな」などのばかげた言葉ではなく。一生懸命働いて賢くなりましょう。
コメント