プログラミングの原始衝動を思い出す旅の途中で by 業務経験約4年 Ruby on Rails エンジニア #転職 #ノベル 2019-03-29
いちど自分が書いたプログラムは、実行前に、査読をすると良い。
セルフコードリーディング。とにかく手を動かす派だと、ついつい省略してしまいがちなステップだが、ここでもコードリーディングにおける禅というか、眼の使い方を養うことが出来る。
スクリプトやクラスや関数、分割するかどうか迷ったら、まず分割した方が良いと思う派だ。
自分の脳に優しい方を選ぶ。チーム開発の場合、個々人の感じ方や脳の経路も違うので、見方がまるで違う場合は、円集合に合わせる。みんなにやさしいプログラミング。
shell script は、スクリプト毎に、なにかと役目を分割させて、それぞれの役割を小さく抑えた方が良いな。
良いやり方を探していくと、必然的に Linux 哲学に行き着きそうだ。 stdin / out ではなく log file を input / output の 媒介とする マイベストプラクティスが成長する。
世間でまだまだマルチタスクが悪の権化とみなされていないのは、
仕事の余幅を意図的にもたせるためには、むしろそれほど悪くない風潮なのかもしれない。今後シングルタスク教みたいなものがもし出来上がれば、あらゆる横道が封鎖されて、封建社会的なデスクワークさえ出来上がりかねない。社会は誤用に満ちている。
Zapier は あなたをもっと幸せ Hapier にするという意味でサービス名がつけられたような感じがある。
なかなかハッピーな話だと思った。 It Makes you Happier Zapier.
転職の時、なぜ前職の給与というものが基準になるのだろうなあ。
給与というのは会社全体の儲けに強く依存するというし、個人の資質よりもそちらの影響が強いと聞くのだが。やはり誰もが確かな評価基準を持たないところで、採用の指針になるものなのだろうな。とかく採用や就職の世界は難しい。#e
就職で、前職の給与が基準となる件。たとえば仮の話だが、売上に苦戦する会社で10年間働き、めきめきと実務能力を伸ばしたとしよう。だが給与がまるきり上がらなかったとしよう。その時、その有能な人材の報酬を、前職の給与で決めたりするのだろうか。このことはかねてより疑問であった。
engineer
自分が望むものは、自ら動かなければ手に入らないという。
受動的に流されてばかりでは、理想は叶えられるのだと。しかしその逆には、縁という考え方もある。ゆるやかなタイミングと、機会と、その波に身を委ねる姿勢とでもいうか。例えば結婚でも、お互いちょうど良いタイミングというものがある。#e
まだ本格的に就職活動を始めてもいないのにも関わらず二社からラブコールをいただいた。
QiitaやTwitterやらの威力おそるべし。こう書けばなんとも鼻に付く感じもしなくもないが、たとえ仮に不運続きだろうと僕は事実を淡々と書いただろうから、勝手に引き分け審判としようか。
幸いに仕事先が瞬で決まろうかというにも関わらず、それでふわっと浮かれる感じも微弱であり、なおかつほんの5分も続かない。
少し寂しくもあるが良い傾向だ。僕は良いネガテイブを信条としており、前職でもほぼ4年間、ストーリー着手のたびに、まず自分には無理だろうと、最初には思う連続であった。#e
しかし問題はこのようなアイデンティティ問題ではなくいかに良い仕事ができるかということである。
長く組織にいると意識が埋没して見えにくくなる部分でもあろうから、この機会に見直したい。今後仮にひとつの組織で長く働くにしても、そうでないにしても、責任には緊張感を。取引関係、契約関係。#e
