ブログについて考えること、2012年10月のスナップショット

misc.

id:E_Mattsan さんからのコメントで、「日誌を書くことは抽象化の訓練だ」という示唆に富むエントリを紹介していただきました。

今年の残りは、日記をもう少しマメに（ただし、できるだけ短く）書いてみます。

最近は、バカさをあまり喧伝すると、今後の転職に障るかなぁと思ってしまい、ついサボりがちでした。え？ 今さら気にするのかって？ しますよ……にんげんだもの……。しかし、遅すぎた／(^o^)＼

これを機に、ブログについての最近の考えをメモしておきます。

ブログを書くか、書かないか

そういう意味では、エンジニアはブログなんて書かなくていいんですよ。「ブログはコードを書けない人のもの」ですから。「ブログなんか書いていないが、とにかくソースコードを見てくれ」、というのが本当だと思いますね。それ位、ソースコードは強烈ですよ。

http://www.procommit.co.jp/feature/individuals/shibata/02.shtml

初めて上の文章を読んだ時、おそらくこれは真実なのだろうと思いました。

そして、出来ていない自分が恥ずかしくなりました。

実際のところ自分はプログラマではないので、そこまでストイックにソースコードにこだわらなくてもよいはずだ、と逃げを打つこともできるでしょう。そうすれば、心を守れるかもしれません。しかし、いやしくもITの世界で技術職として職を得て、実装技術を向上させたいと思っているのであれば、こういった考え方に背を向けてしまうのは、違う気がします。

というわけで、いろいろ考えましたが、今の考えはこんな感じです。

  • （業務外の時間に）コードを書く暇も、ブログを書く暇もない場合 → コードを優先して書いた方がよい
  • （業務外の時間に）コードを書いている場合 → ブログを書いてもよい

勉強会レポート

書くか、書かないか

「ブログを書くまでが勉強会」という言葉がありますが、個人が24時間を何に使い、何に使わないかという選択の問題なので、ぶっちゃけ書かなくてもよいと思っています。たとえば、上記のように、その時間をコードを書くことに充てたほうがよいという判断も、もちろんあるでしょう。

ただ、聴いた話を咀嚼して再構成すると、自分は記憶に残りやすい気がするので、後から思い出したい内容の勉強会については、なるべくレポート（というほどでもないメモ）を書いています。

書くとすればどう書くか

レポートの内容は、発表された内容を自分なりにおおざっぱにまとめたものになりがちですが、それ以外の書き方もあると思います。

  • 発表内容と違うアイデアを書く
  • 発表内容を自分の環境に合わせてカスタマイズしたアイデアを書く
  • 発表内容を実験してみて、結果や、過程から学んだことを書く
  • 発表内容の反証を出す

勉強会の後のブログには、こういったことを書けたらいいなあと思っています。まだ、上手くできませんが :-)

関連記事

年に一度か二度は、ブログについて考えているようです。

基本的な考えは、これまでと同じです。以下の記事に加えて最近考えていることを、今日は書きました。