絵描きにもエラーコンソールがあるといい

絵描きが感覚的な「違和感」ととらえるものを、エンジニアは具体的な「エラー」として把握する

エラーコンソールに表示される

エラーが分かれば「直す方法」につなげられる

「想定通り動作しない状況」には2種類ある

エラーコンソールでエラーが起きてると教えてくれる

そのエラーを読んで、何行目の何の命令が機能不全なのか調べる

エラー発生の直前までは、書いたとおりに動いていたということでもある

エラーコンソールに何も表示されない

どこかで道が途切れてて、期待する動作に到達できていない

ヒントが乏しく、正直つらい

どこまで想定通りに動いていたのか、ブレークポイントであたりをつけて探る

プログラムの場合、ここでエラーコンソールをある程度頼れる

絵にはないので、絵描き自身がエラーコンソール役となる

違和感＝エラーメッセージと認識できれば、どこでエラーが出ているのか見当がつく

エラーメッセージが出ていない状態でも、何がどのように違和感を生んでいるのか探る

いずれの場合でも、解消すれば絵がよくなる

エンジニアでもコピペを多用する人は、「エラー＝コピペミス」と認識してエラーコンソールから解決法を見つけようとしなくなるそうだ

絵描きが自分の絵のエラーをどうにもできない場合は、事実上のコピペだったのではないか

人間の顔や手などは共通の形状であることがほとんどなので、「○○の描き方」の精神的コピペに陥りやすい

絵は、ある程度柔軟にエラー対応を済ませられる

最終的にエラーと感じなければ直せたと考えてよい

そうして1枚の絵を完成にする

次はよりよくやれる

エラーコンソールにスランプはない、とも言える

不具合ならあるかもしれない

エラーコンソール役の自分自身に不具合が起こっていたら、休んだり寝たりしたほうがいい

機械も再起動するだけで直ることがままある

実際のところ、唯一無二の正しいコードというのがあるわけではない。

しかし、これはコピペを多用している人にありがちな考え方のようで、コピペしても動かないのはなにか間違ったことをしていて、正確にコピペできていないところがないかを探すというプログラミングサイクルが習慣化していることが背景にはあるのではないかと感じられた。

そのため、一度書き終わったコードは記号の羅列のように見えてしまい、そこに何か間違いがないか目で探すのだ。自分で書いたものもコピペで始まっているため、それは記号の羅列であって、理解していないものになってしまう。

プログラムのエラーが発生したということは、本来「完成に近づいた」一つの証跡であるはずだ。なぜなら、今まで意識されていなかった情報が一つ明らかになり、間違った仮説をたててしまっていた部分が棄却されて、それを修正するという明確なネクストアクションが手に入るからだ。