自分の知っているプログラマにはこんな方もいました。

・コメントが、あれの方たち。
　1.「言い訳」や「お詫び」が書いてある。
　　　// よくわかりませんのでこうなりました。間違ってたらごめんなさい。
　　　コードするときに聞いてください(vv;)。
　2.「～をする。(たぶん)」と書いてある。
　　　いや、「たぶん」て言われても・・・。
　3.Author欄が他人の名前
　　人のせいにする気はないと信じます(しくしく)。

・からだ、大丈夫ですか。な、方たち
　4.昼までにコーラのリッターが3本カラなってる。
　　んで、お昼は大盛りのカップ焼きそばだったりする・・・しかも2個ね

・どうしましたか。な方たち
　5.彼のリターンキーは部屋中にこだまする。
　　まあ、元気は良いようです。コードの質の方もよろしくお願いします。
　6.実行するたび「えっ」と言う
　　これもこだまするんですよね(泣)。

私のことじゃありません(きっぱり)。本当です(念)。

すぐ Google 先生に聞く。
たまにでもいいから、公式のドキュメントを読んでよ・・・

「・ソースが芸術的　　他の誰も読み取れない。」
の類似で、

・ソースからセキュリティ対策ができている。
他の誰も読み取れないが、なぜか動く。書いた本人も読み取れないこともある。

関数のコメントが丸ごとコピペでgrepすると大量に同じ名前がヒット(>_<)
もちろん、コメントと関数名は別物ですが(笑)

そう言えば、Yahooの知恵袋にコードを質問する、という奴もいたな

・突然笑い出す人…
　煮詰まりすぎると笑い出す人、いますよね。
　# 自分もなりますけど (ぁ)

・3歩歩くと忘れてしまう人
　指示された内容を忘れてしまう人。メモとってたはずなのに、
　最初から説明しなおし、あれー…?

仲澤＠失業者様　sa様　CMP様　やなちゃん様

コメントありがとうございます。

もしPG編の第二弾がありましたが、皆さんから教えてもらったネタを紹介
させていただくかもしれませんので、その時はよろしくお願いいたします。

「仕事はコンパイルが通るまで。」
コンパイルが通らず唸っていた後輩がある日、
「コンパイルが通りました」
と報告。
見ると、「コンパイルエラー」となる箇所全て、
「コメントアウト」してありました・・・。

FIRE　様

コメントありがとうございます。

それで、機能を満たしていたらすごいですね。

・ソースのコメントで「これで大丈夫ですか？」と誰かに訴えている。
　誰に・・・？しかもテストしてないのと理解していないことが一目で分かりました・・・。

yama 様

コメントありあうございました。
ソースのコメントに書く暇があるのならば、そのまま誰かに聞けばいいのにね。

これって、フィクションなんですか？

・ほとんどが、コピペ
→コピペするコードをメソッドとしてベースクラスにまとめて、サブクラスから使うようにすれば
　次から使いまわせますよ。

・知っている構文は、「for」と「if」
→if文のかわりに三項演算子やSwitch-Caseを使ってくださいということですか？
　for文なんか使わずにwhile文やgoto文でループまわしてくださいと？

・DBアクセスや、フレームワークの操作は呪文として覚えてる
→内容を理解した上で、呪文として手に馴染ませるといい感じです。
　内容を理解してない状態だと、障害対応ができなくなりますが。

・お膳立てをしてもらわないと始めらない
→Javaプログラマ募集っていうくらいだから、JavaプログラマはJavaしかわからないのが自然です。
　SVNの操作はSVNエンジニアにやらせるべきだし、Eclipseの調整はEclipseエンジニアにお願いすべき。
　当然TomcatやJDBC経由でのOracleへの接続は、データベースエンジニアにやってもらわないとｗ
　そんなの当たり前でしょ？

・パソコンの操作が分からない
→プログラマは、パソコンではなくサーバやDBの操作に詳しいべきです。
　UNIXのコマンドとかSQLとか、LLの対話的アクションを自在に操作できるべき。
　パソコンなんて、MACでもWinowsでもLinuxでも自作物でも、全くどうでもいいと思います。
　SSHでサーバ接続さえできてれば。

・仕事はコンパイルが通るまで。
→コンパイルが通れば、論理的・構文的には問題ありません。
　物理的にどうなるかは保障されませんが。

・仕様書は、読まない
→アプリケーションやサーバ・ネットワークの仕様書というのは
　サービス開始後に運用担当者が構成を理解するために読むものですから
　リリース前の工程では、そんなもの作る必要はありません。
　「テスト終了後、リリース直前」のタイミングで
　レポジトリから最新ソースを持ってきてperldocにかけた生成物を仕様書として提出するものですよね？

・画面に向かって独り言をいっている
→自分の中で自分自身とすら議論・対話できない人が
　他人と議論・対話できるはずがありません。コミュニケーションは命です。

・パソコンに名前を付けている
→ホスト名が存在しないと、別マシンと通信できませんよ？

・貧乏ゆすりが激しい
→ハードロック聴きながら開発してるんでしょう。

・遅くまで仕事をやっている
→リーダーの立てたスケジュールが無謀なら、夜遅くなるのは仕方ありません。
　営業の取ってきた案件が無謀なら、夜遅くなるのは仕方ありません。
　異動・退職等に伴う引継ぎが全くないのに後任にされたら、夜遅くなるのは仕方ありません。

・ソースが芸術的
→芸術的ということは、非常に美しい論理・構成をとっているわけですよね。
　特殊表記満載の汚いPerl案件から、美しいインデント構成のPython案件に移った時に感じたアレですな。

・ソースがロック
→チーム開発においては、バージョン管理こそが命綱ですから、重複修正は避けるべきです。
　ソースがロックされてるなら、バージョン管理が徹底的に実施されているわけですから
　事故防止の観点から、きちんとセキュリティ・SOX法に配慮したエンタープライズな環境だと思います。

・コメントがない
→コメントは、GitやSVNのコミットログに書いておくべきものであり
　ソース上にはコメントなどない方がスッキリしてロジック追いやすいと思います。

・コメントもJava
→JavaもC#もPHPもRubyも言語なんですから
　コメントはどんな言語で書かれてても、コミュニケーションは可能だと思います。