（今さら）Operation Engineers' Casual Talksの感想メモ。 #operationcasual

もう１ヶ月以上前（2012/12/14）だし、年も跨いでるし・・・と思ったけど、今でも印象に残ってることはきっと大事なことなんで軽くメモだけ。

• 「ほげエンジニア」の定義について（tagomorisさん）
  • 「自分を何者と名乗るのか？」という話。
    • （感想）自分は消去法でプログラマかなーっと漠然と思ってたけど、横割りの組織でミドルウェアやOSから完全に切り離されてコードだけ書いてる環境の話を聞くと物足りなさそうな印象を受けるので、関わりたい範囲をもっと縦に抜いた名前を持った方がいい気がした。

• 「枕を高くして寝る話」 （fujiwara）
  • 全くコードを書かない状態からステップアップしていく流れが綺麗にまとまっていた。
    • （感想）プログラマをやれ、というのではなく、課題を解決する道具という目的がスタート。
  • ちょっと試したり、自分用の道具としてのコードもちゃんと管理する話（Dropboxに同期しておく）
    • （感想）家で作業してて社内Wikiを参照したくなるあの感じに近い。
  • 慣れてきた頃に凝った方法をとり過ぎる時期に気をつけたい「コードを書かないという選択」
    • （感想）2,3ヶ月後に「うわ、全然イケてねぇ…」って自分で思うパターンだｗ
  • 自分用のコードから皆が使えるモジュールにするのが皆に嬉しい形。
  • （CPANなど）ちゃんとしたところに公開するプレッシャーやフィードバックが良い効果を生む。
    • （感想）作法とかわからないしなかなかネタもないけどいつかやりたい。

• パネルディスカッション（tagomorisさん、fujiwaraさん、lamanotramaさん、myfinderさん、mikedaさん）
  • コードを書くべきか？という点については「プログラミングには適正がある」「どこまでも深入りする必要はなにのでは」「広義のコーディングは皆やってる」など
    • （感想）特別な行為として重んじるような意見は少ない印象。
  • 割と「必要なときに選択肢としてコードを書く。ただそれだけ。」という感じ。
    • （感想）インフラ扱ってる方はいい意味でドライ。
  • 勉強方法として、自分から（担当者など）フラグを立ててしまうのが良い。
    • （感想）たしかに無期限だと続かないし、最初からチームの課題解決という恩恵も得られるのでよさげ。
  • インフラ業務のためのコードはあまりテストを書いてないが、複数が使ったり、変更が繰り返されるならあった方がよい。
    • （感想）仕様書としてのテスト。デグレードを検出するためのテスト。
  • 後輩の教育について「（厳しい感じの意見。でも面倒見もよい）」や「一番下手くそであれ」、「自分で荒野を開く方が合ってる」などなど
    • （感想）厳しいけど面倒見も良い指導、新人の頃にいたスーパーエンジニアさん思い出したわ・・・
    • （感想）自分が新人の頃は一番下手くそであれ（情熱プログラマだっけ？）に助けられた感ある。
  • 不満とか転職についての色々
    • （感想）あぁ、気をつけよう・・・

メモ）「おぺかじ」まとめ - Togetter http://togetter.com/li/422826