完全に独断と偏見、主観的な話です。
タイトルはプログラマとありますが、より広いソフトウェア・エンジニアという範疇でも当てはまると思います。
プログラマやエンジニアが何かを達成して満足感を得る場合、例えば依頼されていたタスクを完了した！という達成感や、ずっと問題になっていたバグを修正できた、とかそういう実務的な達成感とは別に、それそのもを美しいと感じる場合があったりすると思うのです。
規則性・パターンを美しいと感じる心
コードを書くといっても、プログラミング言語の限られた構文などを使って機械にやらせたい仕事を記述していくわけですから、同じようなパターンが自然に現れます。それを見て「美しい」と感じたり、逆に規則的なパターンが現れるように意図的にコーディングすることで「美しいでしょ？」と主張したくなるような感覚のこと。
パターンは実用性もあります。ある特定のパターンでコードを書くと、読み手はより効率的に全体を理解できます。規則性があることを発見したり、規則性を持つように工夫することで、他の美しさへつなげることが出来ます（例：汎用化すると美しいと感じる心）
単純な具体例としては、行や余白の使い方などの見た目をパターン化することもあります。単純なことですが、読み手（自分かもしれない）の目に優しいということで美しさ＋実用性もあります。
プログラミングをする上で、いろんなものに「名前」を付けます。名前の付け方に規則性を持たせることもよくあります。バラバラよりもストレスが少なくなります。
設計においても、design pattern と呼ばれる「よくあるパターン」のカタログから、その問題をすでに解決してしまったパターンがあるかどうかを調べたりして、応用できるかを検討したりします。
一般化・汎用化すると美しいと感じる心
コードを書くことである問題を解決します。ある特定の状況だけで解決する場合、それを英語で"One off"と言ったりします。「一度っきり」とか「使い捨て」という感覚です。
それでもいいや、っと思っている人と、これをもっとより多くの似通った状況でも解決できるようにコードを Generalize （一般化、汎用化）してみたい、という気持ちを持つ人がいると思います。後者が「汎用化すると美しい」と感じているのかもしれません。
具体的には、variant （変わるもの）と invariant （変わらないもの）に分類わけをして、変わるものを、その都度外界から受け取れるような工夫をします。例えば円周率は変わらないので invariant として扱い、数学やプログラミング言語の「定数」などの仕組みで表します。対して、直径や半径などはその状況しだいなので、パラメータとして実行時に値を得るように工夫します。
速さを美しいと感じる心
なんでもそうですが、同じ動作でも「ちゃちゃ！」っとやってのける人はカッコいいし、ある種の美しさを表します。プログラミングもしかりです。
アルゴリズムが好きな人は、たいていこの美しさを追及して、はまってしまった人が多いのではないかと思います。例えば、並べ替えのアルゴリズムも、バブルソートや挿入ソートや選択ソートでちまちまやるより、マージソートやクイックソートの方が早いのですが、もちろんそれは処理とメモリというお金がかかる点に着目しているわけですが、それとは別にその人の欲求として「速くしたい」と感じる心があることが多いでしょう。
効率の良さを美しいと感じる心
efficient という言葉でよく表します。同じ結果になるんだけど、より電気を使わない（プロセッサーの命令が少ない）とか、ストレージを使わない（読み書きするデータが少ない）、そういう点での性能を向上させたいという気持ち。
ネットワーキングなどでもコンピューター同士がメッセージのやり取りをするわけですが、コンピューター同士が細かく会話する場合、chatty （おしゃべり）と言ったりします。そういう場合は、依存関係のない内容を複数まとめて、一度にドーンと渡したり受け取ったりします。Batch処理と呼ばれるパターンです。そうすることで、ネットワーク資源（WiFiはタダではないですよね。インターネットですら、どこかで電気代はかかってますし）をより効率的に使うようになるほうが、美しいということになります。
短さを美しいと感じる心
ちょっと小道具がすごいよく出来ていたり便利だったら「スゲー！」と思うことがありますよね。「こんなに小さいのに！」
あとは、ただ単純に小さいのが好きな人もいます。よく出来たミニチュアに感動するような感覚。
プログラミング言語やオペレーティングシステムを操作するスクリプトなどは、そういう美的感覚を持った設計者が作った場合、短くなる傾向があると思います。
同じ作業、例えばファイルの中から特定の文字を検索する、などもスクリプト言語によって、知らない人にはとても理解できない暗号のように思える記述である場合もあれば、しっかり英単語で書いてあるので（その分、長いですが）分かりやすい場合がありますが、一般的にいって、短い方が美しいとされます（要するに人は面倒くさがりですから）。
理解しやすさを美しいと感じる心
これは実は上に上げたものと相反する場合が多いのですが、コードが達成しようとしていることがよく分かるように書くことが美しいと感じる人も多くいます（はい！、わたしもそうです）。
コードは人が読むために書きます。さらにコードは機械が読めるように機械語に変換されて、それから機械に実行してもらいます。この二つの言語がどのぐらい似通っているか（近いか）で人にとっての理解しやすさは変わります。近いほど人には分かりにくい、というのが一般的でしょう。
出来るだけ人にとって読みやすいように書く時、場合によっては機械が実行する際に遅くなる場合があります。そうすると「早さの美しさ」に反します。
読んですぐに何をする関数なのか分かるように、長い名前を付けたとします。すると、「短さを美しい」という感覚の逆方向に向かいます。
コメントといって、コードの周りに説明書きを加えることも出来ますが、それも逆にごみごみしていて美しくないと感じる人もいます。
バランスがとても難しいのです。逆にバランス感覚をもった人は有能なプログラマに成れるのかもしれません。
補完関係を美しいと感じる心
陰と陽、太陽と月、のような関係をプログラミングをしながら表す場合があります。「データを作成する」があれば「データを削除する」がある、すると相反する動作ですがひとまとまりのコードになって美しいです。
人間が本能的にもつ、組み合わせの美しさをプログラミングで活用することで、より人にとって理解しやすい構造を作るのです。
ネットワークプログラミングでも、リクエストとレスポンス、という組み合わせをセットで同時に考えたり設計したりすると、それぞれに共通するパターンが生まれたりしていろいろな効用があらわれます。
逆に、バランス感覚が無い人が設計すると、リクエストとレスポンスの作法がてんでバラバラでいちいち学ばなくてはいけないし、どっちがどっちだったっけ、などと混乱することもあり、実務的にも良くないですね。
抽象化を美しいと感じる心
具体的な世界は結構ごちゃごちゃしています。料理を作る手順で例えると、私は料理はさっぱり分かりませんが、デミグラスソースを作る手順はきっと面倒ですよね？ その手順をひとつひとつ言い表す代わりに「デミグラスソース作って」っと言って、しばらく待つとそれを作ってくれる、となるとスッキリします。そういう感じで、ごちゃごちゃした処理を抽象化した記号などで表すことが美しい、と感じることがあります。
処理だけでなく、データも抽象化できます。住民票という記号で表すデータは実は氏名やら郵便番号やらいろんな細かいデータの集合で出来ています。上手に抽象化されている場合、処理が理解しやすくなります。
いろんな処理やデータをひとまとまりのシステムやサービスとしてまとめ上げるのも抽象化です。美的感覚がある人が設計や実装をすると、使いやすいものが出来ます。逆に、そういうのはどうでもいいと思っている人に任せると、使いにくいものや独善的な、なにか偏った特徴をもつものが出来たりします。
まとめ
かなりこじつけてる感がありますが、おそらくそういう美的感覚というかセンスというものはあるのではないかと思います。
