いちど自分が書いたプログラムは、実行前に、査読をすると良い。

セルフコードリーディング。とにかく手を動かす派だと、ついつい省略してしまいがちなステップだが、ここでもコードリーディングにおける禅というか、眼の使い方を養うことが出来る。

スクリプトやクラスや関数、分割するかどうか迷ったら、まず分割した方が良いと思う派だ。

自分の脳に優しい方を選ぶ。チーム開発の場合、個々人の感じ方や脳の経路も違うので、見方がまるで違う場合は、円集合に合わせる。みんなにやさしいプログラミング。

良いやり方を探していくと、必然的に Linux 哲学に行き着きそうだ。 stdin / out ではなく log file を input / output の媒介とするマイベストプラクティスが成長する。

仕事の余幅を意図的にもたせるためには、むしろそれほど悪くない風潮なのかもしれない。今後シングルタスク教みたいなものがもし出来上がれば、あらゆる横道が封鎖されて、封建社会的なデスクワークさえ出来上がりかねない。社会は誤用に満ちている。

なかなかハッピーな話だと思った。 It Makes you Happier Zapier.

給与というのは会社全体の儲けに強く依存するというし、個人の資質よりもそちらの影響が強いと聞くのだが。やはり誰もが確かな評価基準を持たないところで、採用の指針になるものなのだろうな。とかく採用や就職の世界は難しい。#e

#engineer

受動的に流されてばかりでは、理想は叶えられるのだと。しかしその逆には、縁という考え方もある。ゆるやかなタイミングと、機会と、その波に身を委ねる姿勢とでもいうか。例えば結婚でも、お互いちょうど良いタイミングというものがある。#e

QiitaやTwitterやらの威力おそるべし。こう書けばなんとも鼻に付く感じもしなくもないが、たとえ仮に不運続きだろうと僕は事実を淡々と書いただろうから、勝手に引き分け審判としようか。

少し寂しくもあるが良い傾向だ。僕は良いネガテイブを信条としており、前職でもほぼ4年間、ストーリー着手のたびに、まず自分には無理だろうと、最初には思う連続であった。#e

長く組織にいると意識が埋没して見えにくくなる部分でもあろうから、この機会に見直したい。今後仮にひとつの組織で長く働くにしても、そうでないにしても、責任には緊張感を。取引関係、契約関係。#e

何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。