プログラマとコーダの狭間

コーディングとプログラミングの違いがわかるだろうか。
与えられた目的を達成するためのコードを書くのがコーディング。
与えられた道具を使って何かできないか考えるのがプログラミング。
コーディングが作業であるのに対し、プログラミングは創作だ。

プログラミングという娯楽 - プログラマーの脳みそ

コーディングしかできない人をコーダ、プログラミングができる人をプログラマ、と言い示せばよいと私は考えていた。

しかし、このコメント欄で次のような意見が付く。

ゆの in language の問題は、正に与えられた目的。

与えられた目的を達成する
与えられた道具を使って何かできないか考える

この区分けでいけば、コーディングに分類されるように思えます。

ここで、愕然としたのだ。コーディングとプログラミングの境目はどこなのだろう?と。

コーダ-プログラマの間には何があるのか

プログラミングハイウェイ - プログラマーの脳みそのコメントでも

私の感覚では、コーダでないプログラマがやっていることも翻訳だと思います。ただ、コーダが直訳しかできないのに対して、プログラマは適切な表現を選択して、意訳することができる、と。

と言うような意見があった。

自分が思い描いたラインというのは伝わりにくく、誤解しやすい比喩なのではないかと思ったのだ。

冒頭掲げた定義だと、設問のスケールを小さく小さくしてくと、あるラインからはコーディングになってしまう。しかし、コーダとプログラマの越えられない壁は感覚としてあるわけで、その境は何なのかと考えていた。

IT業界というかSI業界*1の業務でやるコーディングというのは例えば以下のようなものである。

  • 投稿データの日付が現在時間から1日以内の場合、投稿タイトルの横に「new」と表示する
  • 投稿者の過去の投稿数を参照し、50以上の投稿があった場合、投稿者名の前に常連アイコンを表示する

仕様書には、こうした細々としたネタが記載され、コーダはこれを実装していくわけである。
およそ、コーダとプログラマを分ける壁と言うのは、パターンマッチングでできる仕事かどうかというラインではないだろうか。

(追記:twitterで2つ目の例じゃ抽象的すぎるダメ出しされた。えー。これ以上細かく書くのは嫌だな。仕様書を書く時間で実装作って時間が余るぐらいだw)

構造化定理で言われるような順次・反復・分岐というプログラミングの基礎の基礎と言える要素を、たかだか数個組み合わせることで対処できるようなコーディングというのは、設問に対するパターンマッチングで回答することができる。

受験勉強でもそうなのだが、こうした問題のパターンに対して定型の答えを返す、という機械的な対処は、黙々とパターンを暗記することである程度の成果が出るわけだが、応用がまるで効かない。

必要となった時に、応用することができるかどうかがコーダとプログラマ分水嶺のように思う。

冒頭掲げた文で私が言いたかったのは、「プログラマは自由課題をこなせる」ということなのである。定型の経験した設問ではなかったらとたんに作業が止まるコーダとの決定的な違いである。

*1:会社の経理とか在庫管理とか顧客情報の管理とか、そうしたことをシステム化する業界。いわゆるIT業界のうち産業に直結することから大きな市場を持ち、やれIT土方だのブラック会社だのという話が絶えない業界でもある。