プログラマーに必要な知識やスキルについて思いついたままに書き連ねてみます。
ひとつひとつ細かく説明するのではなく、箇条書き的に書いていきます。
まえがき
先に身もふたもないことを言ってしまうと、「ググる能力」１つあれば、あとはどうとでもなります。
といっても、言葉で言うのは簡単ですがネットで検索するためには結局基礎能力が必要になります。
検索というのは辞書と同じで、名前を知っているものを調べるのには向いていても、名前を知らないものを調べるのには向いていません。また、検索結果を読んで理解するためにも基礎知識が必要になります。
ある程度知識を身に着けて、あとはインターネットや専門書があれば自分でどうとでもできる状態になって、やっと一人前といえると思います。
プログラムを書くためのスキル
必要な知識・スキルを大きく分けると以下が挙げられます。
言語
プログラミングといえばすぐに連想するスキルがこれ。C言語、JavaやPythonなどのこと。
これはプログラマーにとって必要なスキルのほんの一部にすぎず、大前提の一つに過ぎません。
言語を覚えただけではソフトウェアを作ることはできません。例えるなら、英語を覚えたからと言って、英語で映画の脚本や小説をかけないのと同じようなものです。
アルゴリズム・データ構造
アルゴリズムとは何かというのは説明不要でしょう。わからない人は"アルゴリズム"でググりましょう。
データ構造というのは、大雑把に言ってしまうと、"線形リスト"や"ハッシュテーブル"など、情報をどのような形で取り扱うかというものです。
なぜアルゴリズムとデータ構造を一項目にまとめたかというと、これらには密接なつながりがあり、切っても切り離せないものだからです。
「アルゴリズムとデータ構造」という一冊の専門書で語られ、大学でも１つの講義で教えるようなことです。 「アルゴリズムとデータ構造」というキーワードでAmazonで検索すると、何冊もヒットするので適当なものを読むことをおすすめします。 自分がわかる言語でサンプルコードが書かれている本を選ぶとよいです。
デバッグスキル
プログラムを書いたら必ずバグが潜んでいるといっても過言ではありません。
画面にHello World!と表示するだけのサンプルプログラムですらバグがある、という意見すら某掲示板で見たことがあります。
多くのプログラマーの間にバグは必ずあるはずという共通認識があるので、プログラムを書いたら必ずテストをするというのが当たり前になっています。
趣味でちょっとしたプログラムを書く場合でも、コンパイルは通ったはずなのに思ったとおりに動作しないというのは頻繁にあります。そういうときは自分でソースコードを調べて、論理的な誤りを直すしかありません。
そういうときはデバッガで１行ずつステップ実行しながら、変数の内容を逐一観察するなどのデバッグ作業を行うことになります。
C/C++言語の場合、WindowsならVisual Studioなどの統合開発環境、Linuxならgdbなどのツールを使うのが一般的なので、それらのツールの使い方を知っておくと役に立ちます。 その他の言語の場合は、それぞれの言語用のツールを探して使い方を覚えましょう。
ちなみに、コンパイルエラーはバグ以前の問題です。そこでつまずいている場合は「言語」の習得が足りていません。
ソフトウェアを作るためのスキル
ソフトウェア工学（ソフトウェアエンジニアリング）
プログラミングだけでなく設計やテストも行う「プログラマー」と区別して、ソースコードを書くだけの人を「コーダー」と呼ぶことがあります。 プログラムを書くためのスキルだけでは「コーダー」止まりです。
企業でソフトウェア開発をするような、いわゆるソフトウェアエンジニアなどと呼ばれるような職種では、さらに"ソフトウェア工学"や"ソフトウェアエンジニアリング"と呼ばれるような知識・スキルが必要になります。
具体的には、"要件定義"、"設計"、"テスト"などのことです。
それぞれ、大雑把に「何を作るべきか決める」、「どう作るか考える」、「作ったもののバグを見つける（そして直す）」と捉えておけばほぼ間違いはありません。
「人月の神話」という書籍では、コーディングは、これらの作業を含めた中でだいたい１／６程度の作業量と言われています。ソフトウェアを作るという一連の作業の中で、ソースコードを書くという時間は、意外と少ないです。
コンピュータ工学
プログラムが実際にコンピュータというハードウェアの中で、どのように動くのかというのを理解しておくと何かと役に立ちます。
例えば、より効率の良いプログラムを書いたり、デバッグをしたりするのに必要になります。
また、プログラミング言語の流行り廃りに比べて、コンピュータそのもの、より厳密に言えばノイマン型コンピュータの知識というものはそう簡単には廃れないので、ここを理解しているかどうかで、プログラミングを極められるかどうか、ソフトウェアエンジニアとして長続きするかどうかが変わります。
とはいえ、他の項目と比べると、習得の優先度は低いかもしれません。
これについては日経ソフトウェアの書籍「コンピュータはなぜ動くのか」や「プログラムはなぜ動くのか」がオススメです。
ライブラリ・フレームワーク
コンピュータ工学とは逆に、流行り廃りが激しいものですが、手っ取り早く（＝時間、人件費をできるだけかけずに効率よく）ソフトウェアを作ろうとしたら必須のものです。
また、自分が習得していない知識や専門家のノウハウなどを手軽に利用できるという点でも優れています。
例えば、Pythonで数値計算をするならnumpyを使うとか、JavaでWebアプリケーションを作るならSpringを使うとかすることで、効率的、かつ独力で作るより高品質なものを作りやすくなります。
手っ取り早く即戦力になりたいなら、なにか一つの言語＋主流なライブラリやフレームワークを覚える、という戦略をオススメします。
ただ、"主流なライブラリやフレームワークを覚える"というのはかなりの労力を必要とするし、流行り廃りによって無駄になった結果、新しいものを覚えなおすハメになるなんてこともあります。
そのような流行り廃りに追従し続けていくためには、基礎能力が大事になってきます。ライブラリやフレームワークの使い方や表面的な機能だけでなく、その根底にある概念を理解しておくと良いかもしれません。
デザインパターン・イディオム
デザインパターンとは、もともとは服飾業界における「型紙」という意味で、それを流用した用語です。
多くの熟練プログラマが、似たようなものを作ろうとすると、自然と似通った構造のソースコードになるらしいです。それらをパターン化して名前をつけて共通認識化したものがデザインパターンです。
結城浩氏の「Java言語で学ぶデザインパターン」で勉強するのが鉄板かと思います。
イディオムは、「定型文」のことで、デザインパターンより細かいものです。規模がちょっと違うだけで、どちらも似たようなものと考えておけばいいと思います。
"言語名 + idiom"でググると、wikipediaなどがすぐ見つかるので、参考にすると良いです。
セキュリティ
特に、ネットワーク通信を行うプログラムを作る場合や、フリーソフト・OSSとして世間一般に公開する場合などには、避けては通れないものです。
バグがないプログラムがありえないのと同様、セキュリティホールがないプログラムもありえません（というかセキュリティホールはバグの一種ですが）。
例えるなら、絶対に破られない金庫や、穴のない完璧な法律くらい、セキュリティホールのないプログラムというのは作るのが難しいものです。
セキュリティに関しては、必要な知識の範囲が広い上に、攻撃側と防御側のイタチごっこが延々と続く日進月歩の世界なので、「習得し終えた」という状況がありえません。非常にめんどくさい分野です。
だからといっておろそかにすると、下手したら顧客に訴訟されかねないので、そのような意味でも本当にめんどくさいものです。
その他
適切なジャンル名を思いつかなかったものをここに羅列します。
おわりに
一通り思いついたものを書き終わったのでここまで。
