久しぶりに読書をした。今回、こんな本を読んでみた。
仕事で底辺プログラマーをしている馴染みから、つい買ってきてしまった。
しかし読んだ感想としては、特に新しいことが得られたわけではなかった。
優先順位を付ける。完璧主義を捨てる。午前中は頭を使った仕事をこなし、午後は単純作業をこなす。本書に書かれていたのはそういったノウハウだったのだが、普通に働いている人であれば、すでに実践しているようなことばかりだった。
本書の内容に共感はすれど学びはほとんどなかった。何ページか読み飛ばしもした。
以下、底辺プログラマーたる僕が仕事でやっていること
上司がその場の思いつきで頼んだ仕事や、そもそも上司自身も頼んだことすら忘れている仕事は放置している。本当に重要な仕事であれば仕様書にも反映させているし、口頭で頼むにしてもある程度は念を押してくる。
しかしたとえどうでもいい仕事であっても、こなしておかなければそれを大義名分に怒鳴ってくる上司もいる。そういう人種だと相手にするのが難しくなる。
過去のソースコードを使い回すこともザラにやっている。すでにテストが終わっており動作も保証されているので、コーディングの時間を節約できるのでかなり楽だ。他にも変数名や関数名を分かりやすくしたり、作った関数をモジュールに格納してそこから呼び出すといったこともすでにやっている。
もくもく会にも参加したことがあるが、コミュ障なので他の参加者たちとはろくに交流することができなかった。
一応、自分ではできる限りのことはしている（つもり）。
備忘録
工数（〇人日）
（１人でやって）〇日分の作業量。ITパスポートの資格取得の際に初めて知った単語。今の仕事では特に意識していない。
保守
納品後のシステムをサポートする。弊社が専らこなしている業務。
要件定義
何のシステムを作るのかを決める作業。既存のシステムの保守・改修がメインである弊社にとってほとんど無縁と言ってもいい。
フレームワーク
効率的に開発できる枠組みとのことだが、未だに意味がよく分かってない。誰か手取り足取り教えて下さい。
ライブラリ
他の人が作った便利な機能。仕事でそれっぽいのを作ったことがあり、あろうことか運用されることになった。
