はじめに

プログラミングの上達への近道は、「とにかく作りたいものを決めてやってみる」に限る。

C#は、Windows7以降であれば標準でコンパイル環境が入っているので、テキストエディタさえあればすぐに始められます。
（「環境構築しようとしてパッケージ間のバージョンが合わない」というようなことで挫折する目に遭わずに済みます。）

追記：Excelマクロやバッチファイル以外の選択肢として、C#は強力なツールになると思います。（※適材適所ではあるので、使い分けが大事。）

追記

開発環境(Visual Studio)については、導入可能であれば、慣れのためにも入れたほうがよいです（外部ライブラリとかも取り込みやすいし、キーワード補完とかも便利）。

職場的に環境を入れれない場合は本記事の内容が参考になるかと思います。

とりあえずはじめよう

コマンドプロンプト(cmd.exe)を使います。この時点で不安がある人は、超入門 - 知識ゼロからコマンドプロンプトをつかう - Qiitaを見てね！

csc.exeでC#のソースコードをインプットとしてコンパイルします。
既に解説記事がたくさんあるので、調べてやってみてください。（核心部分を丸投げ。）
下記の記事が参考になるかと思います。

コマンドラインコンパイラ csc.exe で C# コードをコンパイルする - Qiita

（※PowerShellである必要はなく、コマンドプロンプトで代用できます。）

上記でうまくいかない場合は、下記から探すかググるかして頑張ってください・・・。

「tag：C# csc コンパイル」の検索結果 - Qiita

初心者が心掛けるべきこと

超重要 （身を守るために）
職場などの本番環境で危ないこと¹をやってはいけない。ファイル操作やネットワーク通信など。どんなことになるかは本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita とかを見てみるのもよいかも。
機密情報の管理に注意する。（とくに、ソースコードや入力用のテキストファイルにパスワードを書いたりする場合は、うっかり漏洩しないように注意。）
職場のルールを守る。（ツールやライブラリの、使用やインストールなど。）
自作ソフトがウィルスとして誤検知されることがあるので、その場合の対応についてあらかじめ考慮しておく²。（投げやり・・・）
自作ソフトを使って業務や製品開発している場合に、自作ツールの不備が一要因となってトラブルや不具合混入や不具合見逃しなどを引き起すケースもあり得るので、無保証であることを全面的に周知しつつエビデンスを残すなりウィンドウのタイトルの先頭に【無保証】とつけるなり色々と保身を図ったほうがよい。
他人の書いたソースコードやライブラリなどをローカル環境以外で使うケース（社内外に公開したり商用利用したりなど）では、著作権など国内外の法律に抵触しないかに注意する。
開発環境（使用ツール）
使いやすいテキストエディタを導入する。Undo＆Redo，シンタックスハイライト，検索＆置換は必須。Visual Studio Codeがベストだと思うが、サクラエディタとかでもキーワード設定とかしっかりやっておけば十分何とか使える³。メモ帳は無理。。
バージョン管理ツールをつかってソースコードのバージョン管理をする。⁴
テキスト差分比較ツールをいれておくとよい。
Windowsプログラミング(≒ツールづくり)で意識していること
自動化しすぎない。汎用化しすぎない。（投入労力と有用性のトレードオフのポイントを定める。汎用的に作ろうとするとケアすべきことが爆発的に増えるので頓挫する。）
独自色を出さない。（マニュアルが無くてもすんなり使えるのが理想）
時間軸を意識する。(例. 途中で編集対象のファイル内容が変更されているかもしれない)
変わりそうなところ（機能を追加したりするつもりのところ）を予測して、取り換えが利くように関数（メソッド）を分離するなどする。
特定の種類のファイルを扱うとき - ファイルフォーマットの規格を調べる。
特定の種類のファイルを扱うとき - 規格を守っていないデファクトスタンダードにも気を付ける⁵。
あるものは使うべし
ありそうな機能は、標準ライブラリにあったり、誰かがソースを公開してたりするので、それを組み合わせて使うのが基本。⁶
調べかた
わからないことはまずは調べる。
堅苦しい本やリファレンス本を買うよりもネットで調べるべし。（「習うより慣れろ」なのと、この分野の本の情報（とくに特定の言語に特化したもの）はすぐ陳腐化する。）
ただしネットの情報は鵜呑みにしてはいけない。（バグってるコードとか、非推奨なコードが平気で転がっている。）
掲示板とかブログなどの単発記事よりも、++c++;やdobonなど、まとまっていて論理立った説明を多数書いてくれているサイトのものを採用するのがよい。（ただ、ニッチな内容を調べるときは掲示板とかを頼らざるを得ない場合もある。）
Qiitaの記事の信頼性については、各記事や著者次第なところがある。情報発信ツールであり、ノウハウ共有のためのツールであって、内容が常に正しいわけではない。自分自身もあまり裏どりせずに記事を書いてたり、「とりあえず動けばいいや」レベルのコードを投稿してたりする。
文法知識
変数の型とか、関数（メソッド）とか、制御構文（条件分岐、繰り返し）の書き方は、トライアンドエラーする前に、多少は理解してから着手したほうがよい。少なくとも代入文とかオーバーフローを知らずにコーディングし始めるのはNGだと思う。
とはいえ手を動かさないと始まらないので、まずはHello world的な入門コードをコピペって動作させるところから。
コーディング
インデントする。これ絶対！ 参考: インデントをしよう！（プログラミング）
極力コーディングスタイルを決めて統一する（市民権のあるスタイルからいずれかを採用しておいたほうがよい）。括弧とか空白，改行の位置、変数の大文字小文字など。
判りやすい名前をつける。 hoge1 hoge2とかはヤメテ！
ソースにつけるコメントは必要十分に。⁷
機能単位で関数（メソッド）単位に分けていく。
イメージ：「〇〇を△△から検索する機能」「〇〇を入力として△△を表示する機能」
慣れてきたら class を分解する。無理して使うのではなく、使うと楽になると思ったら使うのがよいかと。（感覚的には、1000行超えたあたりから、分解しないと管理できなくなってくる。）
コンパイル
こまめにコンパイルする（いろんな変更を一度にやると、コンパイルエラーへの対処やデバッグに苦労する）
参考: ネットに転がっているC#のサンプルコードがコンパイルできないときの主な要因
参考: C#のコンパイルエラーの対処例を書いてみる
動作テスト
細かい単位に分けて想定通りの動作をするかを試すのがよい。わりとビッグバンテスト的にやってしまいがちだが、不具合箇所を突き止めるのが大変。
情報工学とか数学とか
プロとしてやっていくつもりなら、避けては通れない。
プログラムはなぜ動くのか　とかの本を読んでみるのがよい（？）
メモリのアドレス空間とか、整数や浮動小数点数がデータがビット(0,1)の並びとしてどう表現されているかとか、原理的なことを知ると、色々なことがクリアに理解できるようになる。
大規模なデータを扱うときは、アルゴリズムに関する知識が必要になってくる。（処理時間とかメモリリソースを意識する場面）
音声処理や3Dグラフィックスや機械学習⁸などを取り扱う場合は、高校～大学レベルの数学の概念や計算規則をしっかり理解していないと厳しい。
文字コードについて
多バイト文字はハマりどころが多いので（とりあえず軌道に乗るまでは）使わないようにする。もしくはちゃんと調べて使う。
参考: C#における文字コードの扱い(Windows10環境) - Qiita
テクニックに溺れない
マルチスレッドの使用は避ける（ムズカシイため）。

よくつかう機能

分離しました。
C# - よく使う機能の逆引きリファレンスを目指して - Qiita

よくつかうコントロール（Windows Forms）

分離しました。
C# - Windows Formsでよく使うコントロールたち（Visual Studioなし環境向け）（作成中） - Qiita

参考サイト

C# によるプログラミング入門 | ++C++; // 未確認飛行 C

ファイルを延々コピーしてしまってサーバーのディスクを一杯にしちゃったり、削除してはいけないファイルを削除しちゃったり、DoS攻撃しちゃったり、機密漏洩したり、、、人生オワタなトラブルを起しかねない。わりと気づかずに無限ループさせてしまったり入力間違いなどで簡単に起き得る。 ↩
一部のウィルス対策ソフトは、使用実績の少ない実行ファイルを片っ端からウィルスとして検出するような、プログラマからするとクソ迷惑なタイプのものがあるので、割とそういう場面に出くわす。 ↩
【コメント指摘を受けて内容見直しました】サクラエディタだと、括弧の閉じ忘れとかに気づきにくいので、Visual Studio Codeに比べると構文エラーを混入してしまいやすく、コンパイルエラーに慣れない初心者向けには厳しい。あとC言語向けにはデフォルトで色々入っているけどC#向けは手薄です。 ↩
GitHubがベストなようである。自分はとりあえずSubversionを使っている（職場でも使ってるので）。とっつきづらいようであれば、安定動作しているソースのバックアップをとっておくくらいはやっておいたほうがよい。（テキトウに上書き保存しつつやってたら元に戻れなくて泣く可能性大。） ↩
mp3タグとかで規格上Shift_JIS使っちゃだめなところにShift_JIS使ってたりするものが氾濫してて、規格に反しているといえど実用上無視できない存在もあったりする。プログラムを作りこんだ後だと、簡単には適合できない場合があるので、プロトタイプを開発していろんなファイルを入力して試してしまうのが早い。もしくはオープンソースで対策しているソフトを漁ってみて参考にしたり（玄人向け）。 ↩
学習目的であれば、フルスクラッチで作ってみるのもアリ。標準外のライブラリは、中身が把握できなかったり、環境やバージョン要因でうまく動作しなかったりするので、あえて使わないことも自分は多い。 ↩
第三者がソースを見て一瞬でわかることをコメントに書く必要はないし、書くとかえって見づらくなる。また、ソースを改変したときにコメントが古いままで不整合な状態になるなど、悪影響を及ぼすことのほうが多い。学習用にメモとして書くのはいいけど、慣れてきたら不要なコメントは残さないほうがよい。 ↩
機械学習については、表層を扱うだけなら数学的な知識がなくても使えるかもしれない。ただし、数学知識がないと機械学習の原理は理解できない。 ↩