@kyanny's blog

My thoughts, my life. Views/opinions are my own.

1 on 1 evaluation

会社の人事評価システムがいろいろ整備されたこともあり(この話は機会があればどこかで話したいと思っている。キーワード: グローバル企業、エンジニア評価制度、フェアな基準)評価面談的なのをやった。もちろん自分が評価される側。

現状そんなに悪くないからこの調子で、みたいな感じではあるものの、現状維持でokというわけにもいかないので今後なにをやっていくのか、というところで、前々から取り組みたいと思っていたことはあり、ニーズも大義もありそうで理解も得られそうではあるのだが、長い目で見ると自分のキャリア的にけっこう大きな進路変更になる可能性があるので(言うまでもなく、マネジメント路線ではない)、まだちょっと踏ん切りがつかないところもあり、悩み中、といったところで wrap up. あと自分にその適性がある仕事なのか?にいまいち自信というか確信がないのも及び腰になる一因ではある。

先日同僚と飲み会で話したとき、曰く、「若い頃はやりたいこと優先な考え方だったけど年とってくるとやるべきこと優先な考え方に変わってきて、自分がいまやるべきこと(仕事で求められること)って結局自分がすでにできることになっちゃうので、新しいことに挑戦しなくなって老害化するよね」という話になった。その通りで、そうやってちゃんと開発とか運用とかひいては事業・ビジネスってやつを回していくのも大事なことだし満足感もあるとは思うのだけど、この先何年何十年もそればっかりでいいんだっけ?とか考え始めると、うーん。。という気もしてくる。

特定医療費(指定難病)受給者証の更新手続き

今年もまたこの季節がやってきた。いい加減やり方を記録に残さないと毎年迷って苦労する。

昔は「特定疾患」と呼んでいた気がするが、いまはもうすたれた言い方なのだろうか。

受診を希望する医療機関等

利用頻度の高いものから書くとよい、とアドバイスされた。

利用状況が月一回に満たない場合は、分数とか「年一回」とか適当に書けばよい。

今回は、

  1. 新宿の診療所(実績から都が印刷記入済みだった) 1/6
  2. 埼玉のクリニック 1/2
  3. 埼玉の薬局 1/2
  4. 別紙に東京の大病院 一年に一回

で申請した。

「最大三つまで」と書き方の例にはあるが、窓口で相談したらわざわざ別紙に書くようにと紙まで用意してくれた。

住民票

健康保険組合なので不要。わかってたけど万が一書類不備があったときもう一度出向くのが面倒でつい安心料 200 円払ってしまった。

世帯の所得を確認するための書類

被保険者(おれ)の平成28年度住民課税(非課税)証明書。自動交付機で平成28年度のものがゲットできたのでよかった。

昔は源泉徴収票が必要だったが、あれはたいへん面倒だった(どこにしまったかわからない、過去分は何枚もあるのに指定の年度のやつだけ欠番してたりする、転職すると時期によって提出すべき枚数が増える、退職した会社から再発行してもらう必要すらでてくる、等)ので、自動交付機で安定して入手できる書類に変わって本当によかった。

公費負担番号が〜〜の方、というやつに該当したら

その番号はおれ個人ではなく「経過措置の対象者」みたいな単位で発番されてるもののようなので、名指しで何かしろと言われているわけではない。心配無用。


毎年このイベントが一番緊張する。36年生きてきて役所で邪険に扱われた記憶は全然無いのだけど、なにせこれをリジェクトされると経済的に破綻する(もしくは生命の危機にさらされる)可能性が非常に高いので、「いま目の前で書類をチェックしている役人の機嫌を損ねたら死ぬ」という気持ちになって、最大限へりくだった態度になってしまう。

Code Complete 第2版 下

blog.kyanny.me

上巻読了から半年、上巻を買ってからは実に九ヶ月も費やしてようやく下巻も読み終わった。長すぎて途中で何度も飽きたり挫折したりしてしまい間が空いたし、前の方に何が書いてあったかろくに覚えてもいない。

とにかく長すぎる。名著ではあるのだと思うが、時間に余裕があるか「俺はあの Code Complete を読破したんだぞ!」という満足感を得たいのでもなければ、もはやわざわざこの本を読まなくてもいいと思う。重要なトピックごとに、もっと深く掘り下げていてこれほど長くはない本がある。特に、良いコードを書くための知識については「リーダブルコード」のほうが良いと思う。

Code Complete 第2版 下 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

ちなみに自分がまさに「俺はあの Code Compoete を読破したんだぞ!」と言いたくて読んだクチなのだが、読めば読むほど「これを読んで『素晴らしい、名著だ、プログラマなら絶対読むべき』などと言いたくなるひとはサンクコストを意識したほうがよい」との思いを深めるばかりだった。得るものは少なくない。だが、もっと効率よくやれる。

最近読んだもの

「笑われたこと、常に達成」 イチロー一問一答:一面:中日新聞(CHUNICHI Web)

「でも三打席足踏みしてますからね。これを『サッとやってる』感覚なら、僕はここ(会見場)にいないでしょう。もっと早くできていた。時間がかかりすぎです」

こういう姿勢が違いをうむんだろうなぁ。

Tech Lead vs IC (Individual Contributer、つまり部下無しプログラマね) - 南よ! 海の見える方!

同世代とかで転職した、みたいな話を聞くと、なんか毎回似たようなチーム開発の体制整えたりとかそういう事やってるみたいなのを何度も聞いていて、なんで同じ事をこう何回もやってるんだろう? リードはもう新しい技術の話とか出来なくなってきていて、プロダクトのデザインだとかもっと大きな日本のIT業界のあり方だとか、そんなそこらの非技術者のじいさんとかが偉そうに語ってる薄っぺらい話と同じような話しかしなくなってる

その通りだと思うし(Ref: 第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog)、肩書無しでリードですらない一兵卒の自分自身も新しい技術の話ができなくなってきていて身につまされる。

一方で、

一方でガチでデータ分析の現場でAWSで大規模データ扱いつつ最新の論文キャッチアップして分析屋と仕事を出来るエンジニアの方が、明らかに少ない気がする。
年収も需要を割と素直に反映していて、分析屋のICの方がもはや高いように見える。
勝負を分けるのもコアになる少数のICの実力の所であってチーム全体のアウトプットという感じじゃなくなってきている気がする。

ここは違う気がする。稀有なスキルなので高値がつく、というのはその通りなんだと思うが、そもそも需要も少ないと思う(特定分野のスペシャリストを雇う余力がある会社はまだまだ少ないしポジションも少ない。なんだかんだいって普通のWeb/モバイルアプリを書くプログラマへのニーズが高い)し、そういう普通のプログラマたちが作った普通の製品を普通の営業が売る、みたいなサイクルがちゃんと回り続けてるところが勝っている印象(ただしそれは営業力の勝負になってしまっていて、技術力で勝ち負けをどうこうできていない時点でそこで働くプログラマとしては落第点なんじゃないの?というのはあると思う)