プログラミング作業を将棋に例えてみる
特に非エンジニア向けに書く。
プログラマーの仕事はエディタに向かうことではない。
「お前は何を言っているんだ？」
まぁ、待って欲しい。説明する。
「将棋指しの仕事は駒を動かすことだ」
？おかしいですよね。将棋指しの仕事は駒を「どう」動かすか考えることだ。
実際にレベルの高い将棋指し同士は、盤面が無くても脳内だけで試合ができる。
もちろん、プログラミングを実際に行なわないとコンピューターは動かない。
さらに例える。
プログラミング作業におけるコードをコンピューターに打つという作業は、
将棋指しが駒を動かす。というのに近い。
ただし、場合によっては駒の重さが30kgぐらいある。
どんだけ優れた将棋指しでも、30kgの駒を100回とか動かしたら、
疲れて頭回らなくて素人にも負けてしまうかもしれない。
30kgもある駒を動かすのは大変だ。
だからプログラマーはエディタ工夫したり、
開発環境工夫したり、色々して駒を軽くする。
盤面について考えることも大事だし、
駒を軽くすることも大事。
で、優れたプログラマーは駒をめっさ軽くする。
となると、プログラマーの仕事は、
ほぼ、考えることだ。
ご理解いただけただろうか？
バグの潰し方
バグ潰してますか？僕は毎日3個ぐらいは踏み潰してます
Android2.xでしかでないバグを死んだ魚のような目をして潰してます。
まぁ、バグは出さないほうがいいです。
TDDだったりDDDだったりCIだったりはバグを出さない、
出してもすぐ見つけるための仕組みですね。
ですが、どうしてもバグは出ます。
というか、バグがないシステムを保証することは出来ません。
人生は有限なので、無限にテストは出来ないですから。
ではどうやってバグを潰すか。
再現できるバグは潰しやすいですよね。
A B C D E という手順を経るバグがあったとします。
A B C D E のどれかにあるわけです。
ここで僕がやる手法は、
可能なのであれば、
ABC と DE をわけてテストします。
２分探索ですね。
で、Aに原因があるとわかったら、
A を α という単純な手法に変えられないか考えます。
単純化したほうがバグは見つけやすいですね。
Aという手順の中にも複数行にわたってプログラムなどがあるはずなので、
それをさらにだんだん簡略化、二分探索します。
はい。バグ見つかりましたね。
潰そう。
再現できないバグは難しいですね。
再現できないバグは、経験上以下の種別があります。
- 並列実行の問題
- メモリリーク
- 高負荷時の問題
- すごく複雑な手順
- 人間の問題
最後の人間の問題は、多くの場合、
バグ報告の情報が不足してることで起こります。
再現できないバグの修正は難しいので、
是非、エンジニア以外も、
OSのバージョンだとか、再現手順などの報告のしかたを覚えて欲しいものです。
まぁ、こういう再現できないバグは諦めるというのも手です。
せめてログが残ってたりするといいんですが、
ログ出すのもコストであったりするのでトレードオフですね。
さて、駄文を書き終わったので、
Android2.x 系のバグを潰す仕事に戻るぉ…
勉強会で何かを得るためにはどうすればいいか
「IT勉強会には意味が無い、得るものがない」というブログが
僕のTLでプチ炎上してたし、
まだ仕事の気分乗る時間じゃないし、
100回ぐらい勉強会主催して300回ぐらい勉強会参加したことあるし書くよ！
元ネタブログは書いてあることは正しいんだけど、
タイトルが釣りっぽいのが良くないね。
炎上マーケティングなのかもしれないけど。
http://blog.sumyapp.com/2013/09/it-study-event-is-not-recommend/
"勉強会で勉強するやつはダメだ"
みたいな言葉聞いたことがある。まぁ、正しい。
勉強会で得するにはどうすればいいか書く。
まずは、自分にあった勉強会を見つける必要がある。
なければ作る。
「会社に言われて勉強会きました」
悪くはないけど、それ仕事ですね。
だからそれは給料の一部なので得ですね。
「なんかよくわからないけど来ました」
うーん。人生大丈夫ですか？
「簡単すぎました / 難しすぎました」
次からはよく選びましょう。
「懇親会が本当の勉強会だ！」と言う人いますね。
僕も同意です。そもそもお酒飲んで人としゃべるの好きですし。
でも、ひきこもりには辛いですね。
ひきこもりは家で本でも読んで勉強しといたほうがいいですよ。
それぞれ人には特性がある。
だから、「IT勉強会には意味が無い、得るものがない」
などと断言するの、どうなんですかね。
社長さんみたいだから、あんまりそうやって人を断絶するの良くないと思います。
社長やってるけど根がひきこもり体質の人なのかもしれないですね
そんじゃーね
あ。来年あたり、500人規模程度を想定して、java-jaカンファレンスってやりたいので、
これ読んだ人協力よろー
人を信頼し任せるということ
結論。
人は信頼し、仕事を任せろ。
多くの人が、人に仕事を任せるのが下手だなと思う。
人は信頼し、仕事をどんどん任せるのがいい。
任せるのと丸投げは違うよ？
まず信頼しろってことについて。
人は裏切らん。
俺は10年以上仕事してて、職場で裏切られたり、
会社裏切ってる奴みたことがない。
俺が気づいてないだけかもしれないし、
観測範囲が狭いだけかもしれないけど、
まともな会社、お前がまともな人なら、
人は会社や人を裏切らない。
次に任せると丸投げの違い。
それは責任だ。
仕事を任せたら、その相手に、
「何かあったら責任は全部俺が持つ」と言え。
てか、責任とれないぐらいの事柄なんだったら、
そもそもお前には荷が重い。
責任をとれ。
任せた結果、そいつが仕事終わんなそうだったら、
自分も手伝え。２倍働け。
金銭的に損失が発生しそうならお前が払え。
信頼して任された人間は働ける。
そもそも、信頼され、任されるということは、
マズローの欲求段階説でいうところの、
安全の欲求、所属と愛の欲求、承認（尊重）の欲求
あたりが満たされるということだ。
下位の欲求が満たされてないと、
人は集中して仕事が出来ない。
餓死しそうなほどお腹が減ってるやつが仕事できると思うか？？？
ただ、任せるのに適してない仕事というか事柄はある。
それは本能に近い事柄だ。
例えば戦争。
軍隊は任せるのに適していない。
それは死への恐怖や、暴力への渇望は本能的だからだ。
あまり任せすぎると暴走する。
例えば恋愛。
恋愛は人に任せてはいけない。
刺されるぞ。
任せ方にも色々コツがある。
まぁ、深くは書かないが、
相手の能力よりちょっと上の仕事を任せろ。
成長する。
相手の力を見極めるのはなかなかに難しいがそうしろ。
あとは、悟られないように進捗をうまく確認しろ。
進捗どうですか。
結論。
信頼しろ。任せろ。
浜町、人形町ランチマップ
そういえば、ドワンゴ社が浜町にあったころに、
ランチマップというのを作った。
ドワンゴ社が銀座に移転して、ドワンゴ社の皆様には役にたたなくなったので、
せっかくつくったし公開しときます。
多分、世界一の浜町ランチマップです。
色が赤とか黄色になってるところがオススメ。
https://maps.google.co.jp/maps/ms?msid=210837246571344376838.0004ceeec0a99012640b5&msa=0
モチベーションで仕事をする２流
結論。モチベーションで仕事をしてはいけない。
よく「彼はモチベーションが高くていい」
とか「モチベーションを上げるにはどうしたらいいか」
という話を聞く。
まぁ、モチベーションが高いのがいいのは理解できる。
正しい。
だが、もっと大事なのは、
モチベーションがなくても仕事が回る人間、
システム、組織を作ることだ。
これは人から聞いたたとえだけど、仕事を車に例える。
モチベーションはガソリンで、
システムは車体だって。
そうガソリンは大事。なけりゃ走れない。
でもさ、だからって燃費が悪い車乗ってるのもアホくさい。
いかに効率のよい車体を作るかが、
会社、経営者、リーダーの役割だ。
どんだけモチベーションが高い人間だって、
バカスカ使ってたらいつか枯渇するよ。
あと、なんか「モチベーションを高くもっていきましょう！」
なんて言うやつ、他の人にもモチベーションを要求しがちなんだよね。
お前がモチベーションが高いのはいい。
認める。素晴らしい。
人に求めるな。お前の高いモチベーションは車体を良くすることに使え。
Redis 使ってるなら絶対に使うべき Redis Commander
皆さん Redis 使ってますか。
僕は一時期 Redis 厨になるぐらいには使ってます。
（今は一定の距離を保ったいいお付き合いしてます）
でだ。
まぁ、皆さん redis-cli とか使って key の管理とかしてると思うんですよ。
でも、もう2013年の夏も終わりですよ。
そんな前時代的なことしてちゃだめです。
はい。そこで Redis Commander。
http://nearinfinity.github.io/redis-commander/
四の五の言わずに、サイト見れば良さがすぐわかると思うんだけど、
まぁ、npmでサーバー立ち上げて、HTMLでRedisの管理ができちゃうすぐれもの。
インスコも楽ですしおすし。
え。皆さん普通 node はマシンに入ってますよね。
じゃあ、npm install -g redis-commanderで終了です。
もちろんローカル以外にもアクセスできますよ。
使い方は、redis-commander --help で。
