回答:
"場合によります"
<>の知識または理解を体験します。
プログラマー1は、非常に優れたグルである場合もあれば、過去5年間言語をいじり回している誰かである場合もあります。
プログラマー2は、使用している言語とは関係なく概念を理解する人かもしれません。または、言語Bが難しすぎてAの方が簡単だと思っている人。
コーディングホラーの「The Years of Experience Myth」は一読の価値があります
場合によります。
私には1つの言語にこだわる傾向がある友人がいるので、彼を「プログラマーA」と見なすと、その言語で1年間、5回の経験があります。
言語が異なれば、さまざまなことができます。私が特に好きなエッセイの1つは、ポールグラハムによって「Beating the Averages」と呼ばれています。その中で彼は人々にlispを学ぶよう説得しようとしていますが、彼はまたいくつかの非常に有用なポイントを作ります：
プログラマーはお気に入りの言語に非常に執着しており、私は誰かの気持ちを傷つけたくないので、この点を説明するために、ブラブと呼ばれる仮想的な言語を使用します。ブラブは、抽象的な連続体の真ん中に落ちます。最も強力な言語ではありませんが、Cobolや機械語よりも強力です。
そして実際、私たちの架空のブラブプログラマーはどちらも使用しません。もちろん、彼は機械語でプログラムするつもりはありません。それがコンパイラの目的です。そして、Cobolに関しては、誰もがそれを使って何かを成し遂げる方法を彼は知りません。xもありません（お好みのBlub機能）。
私たちの架空のブラブプログラマーがパワー連続体を見下ろしている限り、彼は自分が下を見ていることを知っています。Blubよりも強力でない言語は、彼が慣れているいくつかの機能がないため、明らかに強力ではありません。しかし、私たちの架空のブラブプログラマーが、パワーコンティニュームを逆方向に見たとき、彼は見上げていることに気づきません。彼が見ているのは単に奇妙な言語です。彼はおそらくそれらをブラブと同等のパワーについて考えていますが、他のすべての毛むくじゃらのものも同様に投入されています。彼はブラブで考えているので、ブラブは彼にとって十分良いです。
しかし、強力な連続体で上位の言語のいずれかを使用するプログラマーの視点に切り替えると、次に彼はブラブを見下ろしていることがわかります。Blubで何かをするにはどうすればよいですか？yもありません。
一般的に、私のアドバイスは複数の言語を学び、言語の長所と短所を知ることです。
言語は問題ではありません。数日で言語全体を学ぶことができます。吸収に時間がかかるのは、規約、API、さまざまなサードパーティのフレームワークです。Xの5年間を尋ねるとき、彼らは言語に関心がなく、その言語の問題を解決した経験が豊富で、学習曲線にお金を払う必要がない人を求めています。
専門知識と意図的な練習。
意図的に練習しなければ、専門知識は得られません。（あなたは自分のエラーを調べて修正し、自分の弱点を練習し、専門家にあなたが間違っていることを教えてくれる必要があります。）
あなたが改善しようとしない場合、あなたは永遠に初心者になることができます！
1万時間の慎重な練習の後、専門知識を習得します。（教育/トレーニングからのこの発見はネット全体に及んでいます。）
プログラマーAが意図的に練習していないと、改善されることはありません。
プログラマーBが意図的に練習していない場合、彼らは決して良くなることはありません。
同じ調査からのもう1つの発見：私が15000時間、あなたが10000時間持っていて、私が練習を続けているなら、あなたは私より優れていることはありません。
2つの言語を知っていれば、おそらくBはより優れたプログラマーになるでしょう（ルールを練習する必要があります）。
言語は言語であり、概念は概念であることに同意します。
私の問題は、最近、高度なIDEなしではまったくプログラムできないプログラマーがたくさんいることです。彼らは本当にプログラマーではありませんが、本当にデザイナーのようです。
私は個人的な経験から、厄介なMicrosoftの開発環境で悩まされている人がたくさんいることを知っています。テキストボックスを画面にドロップしてから、ウィザードでプロパティを設定し、データベースの画像からデータをドラッグするのは間違いではありませんが、基本的な同等性テストをすべてセットアップしている場合、それらは実際に任意の言語のコーダーですか？
それらの人々は、彼らが学んだ概念を取り、それらを別の言語に適用することは決してできないでしょう。
私が人々にインタビューするとき、彼らが彼らの開発をどのようにしたか、そして彼らがどのフレームワークを使用したかにもっと興味があります。「イベントハンドラーをどのように記述しますか」、「どのように正確にデータをDBに入力しますか？」、または「この特定のボタンをクリックしたときに紫色にするにはどうすればよいですか？」これはすぐにデザイナーを排除し、プログラマーから離れます。3年か4年は実際に私の選択した言語で1年をプログラミングすれば十分です。
ちょうど別の意見、
タル
「X言語/プラットフォームの経験年数」は、主に採用の病理です...
それは解釈の自由があり、一見したところほど有用ではありません。言われたように、経験年神話は良い読み物です。
また、重要なことに、「経験年数」自体の測定は非常に不正確になる可能性があります。これが私の現在のギグの例です。私の主なタスクはJava Webアプリの開発と保守です。ただし、これはMFC / C ++ / SQL Serverであるバックエンドで実行されます。その結果、私もC ++コードをほぼ毎日処理しています。しかし、このC ++の経験は比較的表面的で保守指向であり、MFC / C ++で大きなコンポーネントやプログラム全体をゼロから作成することはもうありません（ただし、以前の役割で使用していました）。
これらの過去5年間を「C ++の5年間の経験」として数えることはできますか？多分。そうでないかもしれない。特定の役割を確保するためにどのように販売したいかによって、あからさまに嘘をつくことなく簡単にオーバープレーすることができます。:)この種の「測定の不正確さ」の問題に同様にオープンなケースがたくさんあると私は確信しています。経験の深さは、経験の質を著しく曇らせる可能性があります。したがって、「C ++で費やされるXの時間」は、それ自体にはあまり意味がありません。