コグノスケ

管理しない職

「変人」から一流になれる人、変人を一流に変えられる「管理職」の条件 - ダイヤモンド・オンラインを読んで。

同意できる内容なんだけども、これって変人か否かは関係ないような…。

自分で頼んでおいて、今君何してるの？って真顔で聴いてくる人、いつ出来るんだ、早くやれ、しか言わない人、こんなのは上司でも部下でも同僚でもイヤです。

（引用）
「こういう眼力のある人が自分の上についてくれると、変人たちは尋常ではない働きぶりを示します。自分の頑張りが“適切に”理解され、評価され、支援されるのですから。一方、仕事の質の評価ができず、売上と納期、コストのことしか頭にない上司だと、やる気はまったく上がりません。」

Facebookのコメントで「見方や活かし方によって「変人」になってしまう、て意味に見えました。」と指摘を受けました。なるほど、そういうことか…。

メモ: 技術系の話はFacebookから転記しておくことにした。

無線は速くなった

有線の次世代規格10Gbps Etherが足踏みしている間に、無線が1Gbps超えて（参考: NEC AtermStationのサイト）、有線が無線に負けちゃたなあ。

規格名メモ。

• IEEE802.3ab: 1Gbps Ethernet
• IEEE802.3an: 10Gbps Ethernet
• IEEE 802.11n: 600Mbps 2.4GHz/5GHz Wi-Fi
• IEEE 802.11ac: 6Gbps 5GHz Wi-Fi

メモ: 技術系の話はFacebookから転記しておくことにした。

Scalaコレクションとlength

Scalaでファイルの中身を解析したいとき、遅延評価コレクション（StreamとかViewとか）にファイル全体をマッピングすれば、好きな位置を解析できて楽だろう、というアイデアは誰しもが考えると思います。

実は私もその口だったのですが、実際にやってみるとScalaコレクションはlengthが全てInt型とされているため、アクセスできる範囲が短すぎて（最大で2Gi要素まで）困ってしまいました。

たかがそれしきのことですが、lengthはコレクション操作の至る所に出現しますので、非常に影響は大きいです。

Scalaの遅延評価は、事前に全て評価するのは不可能な（長さが無限大、あるいは大きすぎる）コレクションを扱うアイデアのはずなのに、何を思ってコレクションのlengthをInt型にしたのでしょう…。

独り言レビューだって良いじゃないか

$shibayu36->blog; - 2014-03-16コードコンプリートを再読した

「二人である物事に取り組むと、大体会話をしている最中に設計が良くなっていくことが多い印象がある。議論にならなくても良いことも多くて、話しかけるためだけのぬいぐるみとしてだけでも良いこともある。」（以上、引用、強調は私によるもの）

作業履歴代わりに、会社のRedmineに設計とかコーディングについて、独り言を書き続けていて、最近ちょっと虚しくなってきていたのだけど、実はレビューの意味もあったんだよ、ということを気づかせてくれた。そうだったのか…。

メモ: 技術系？の話はFacebookから転記しておくことにした。

難解なコードが増える理由

数年前から、会社で理解に苦しむ難解なコードが多いのはなぜだろう、誰に聞いても「このコードは意味不明だ、一見してもわからない」と言うのに、どうして誰も直さないのだろう？と疑問に思っていました。

金、土とほぼ風邪で寝てて暇だったので、久しぶりにこのブログ（脱社畜ブログ - 2013-10-30 - 「あなたにしかできない仕事」を無くすために必要なこと）を読み返していたら、なんとなく答えがわかりました。

特にこの部分です。
（引用）「あなたにしかできない仕事」を「誰でもできる仕事」に変えることは、「あなたにしかできない仕事」を一人で抱えるよりも遥かに価値があることだ。そういう意味で、この手の「標準化」は高く評価されなければならない。（引用終）

以前読んだときは「標準化」がイマイチわからなかったのですが、これを、

• 「あなたにしかできない仕事」＝「あなたにしか理解、メンテナンスできないコード」
• 「誰でもできる仕事」＝「誰でも理解、メンテナンスできるコード」

と置き換えて、「標準化」は「読みやすい、わかりやすいコードに書き換える」「一見して理解できる小規模に分割する」といった行為に置き換えると、非常にしっくりきました。

会社の難解なコードが増えていく理由は、標準化、つまりコードをわかりやすくするインセンティブが会社から与えられないというシステム的な問題が主な原因であって、個人に責はない、ということです。

このような評価体制だと、他人のコードに興味を示さない方が得になってしまいます。金より、エンジニアとして一目置かれたい、と思う人のやる気すらも奪ってしまうことになります。

私個人が会社の金銭的インセンティブのシステムを変えるのは難しいですが、せめて、わかりやすいコードを書く人を褒めて感謝し、自身もわかりやすいコードを書くことで報いることを心掛けようと思います。