合わせて聞きたい
rebuild.fm
ゴリゴリの技術系とはちょっと違う観点の書籍を読んでみた。第一版を前職の同僚に勧められたことがあったので気になっていた本。
古き良きアイディアが詰まっているので、過去の自分の経験や今のプロジェクト・自分のスキルレベルと絡めて妄想しながら読んだ。自分のいろんな習慣を変えていくきっかけになった。「なるほど達人に近づくためにあれもこれもやらないと!!」みたいな感覚。
他の人の感想を知りたくなってググったところrebuildのディスリ回があると知り、聞いてみた。当時は第二版出版前で改定された部分の内容も含まれているが、概ね分かる話ばかりで楽しかった。スキルがある人達が時代背景を語りながら、現状と違う部分・共感できる部分を面白おかしく話している。技術書に対して著者以外が批評しているコンテンツとして、かなり上位の体験だった。普通のブログ記事を読むのとはぜんぜん違う。
人にすすめるんじゃなくて読んだお前がどう思ったのか書けよというのはその通りなので、忘れる前に書いておく
石のスープと茹でガエル
課題に気づけない人になるなという話で、それが難しいんだけど・・・。まずは大きな視点を忘れないようにする。茹でガエルという表現が課題に気づけない人の例えとして丁度良く、意味も伝わりやすくて使いやすい。
十分に良いソフトウェア
トレードオフにユーザを巻き込む
障害を出すと問題になるので品質を上げるために何かしたいが、営業が納期を短く設定するから何もできずに悪循環になる というプロジェクトをよく見かけるが、そのときに思い出したい。
コンピュータは人に使われる。ならばエンジニアは人を知らなければならない。だから技術書以外の本も読め。とのこと。耳が痛いが確かに。最近UXを意識することが増えてユーザを理解することに興味が出てきた。若いときは技術をつければいいと思っていたがそうも言ってられない。何か取り入れたい。
学んだ知識はいつどこで有効になるのか考えること。一次思考で止まらず二次思考も
伝達
意識しているつもりだけど、そもそも日本語をちゃんと読まない人がいるわけで、難しい。
アプローチ
このあたりから、読みながら他の書籍の内容を思い出すことが増えてきた。一緒に読むと理解が深まるかもしれない。自分ももう一度読みたいと思った。
バグがないと信じるのではなく、検証する。
新規プロダクト動作確認をテストで実施するようにしていて、今までとマインドセットが変わった。検証できることで不確実性が減り、新しい部分への実装に集中できるようになった。
テキスト操作言語
目Grepに頼りがちなので、簡単なテキスト操作から始めたい。ドキュメント系の仕事の中には文章チェック系が多く含まれるので、今学んでおくことで将来楽をできそう。
契約・表明
引数チェックを厳密にやりたくなっった。が、rebuildを聞いているとそれが良いとは限らないことを知り、悩ましい。assertを入れておきたい。
フロントエンドであっても、無効な値が入力されたらクラッシュするようにしたいけど、色々厳しいからなぁ。。。
ヘッドライトを追い越さない
予言は難しい。今日と明日は似ていることが多いが、それを前提にしないこと。急なトラブルは起こり得る。人も辞める。チームメンバーの大半が入れ替わる状況もよく見かけるので、このフレーズは思うところがあった。最近は、6ヶ月後にはみんないなくなっているかもしれないと思って物事を考えるようになった。
偶発的プログラミング
慎重なプログラミングが良いのはわかるが、体調によるよなぁ。眠いときとかは適当になりがち。テストコードを書くことで検討プロセスが入り、少しマシになったかもしれない。
テストはバグを見つけることではない
定義した動作を実現できているかを見るもの。なのでテストをちゃんと考える
書くのがつかれたのでここまで。マーカーは色々引いているので、数年後にもう一度見ると別の学びになりそう。
