sisyaのブックマーク - はてなブックマーク

アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう？｜牛尾　剛
アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。ドキュメントを書く理由　日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ
sisya 2023/05/30
別口で聞いた話では「引き継げないので分からない部分は捨てる」と言っていた。つまり引き継げないことを織り込み済みにしてトラブル込みで許容しているだけのように思う。それが良いことか悪いことかは場合による。
リンク
コードリーディングのコツは極力コードを読まないこと｜牛尾　剛
私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。技術イケメンの皆さんのアドバイス　よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど
sisya 2021/04/17
コードを解釈するときに使う頭と、記述する時（問題解決するとき）に使う頭が全然違うので、双方を行き来するような頭の使い方をすると疲れるというのはわかる。一旦仕様書だけ見て実装してから読んだ方がいい。
リンク
技術者には試行錯誤は圧倒的に悪であると腹落ちした話｜牛尾　剛
私はシアトルのクラウドの中の人として、ソフトウェアの開発を行っているが、先日ある問題がきっかけで、技術者には試行錯誤がとても良くないということが腹落ちしたので、忘れないように書いておきたい。先日起こった事先日起こった事は、私がシアトルから一時帰国して、普段使わないラップトップを使って日本から仕事をしている。 Application Insights というログを管理するプラットフォームがあるのだが、とても不思議なことに、Application Insights のログファイルを見ると完全に正常に動いているようにしか見えないのだが、クラウドのポータルに行くと、テレメトリが来ていない。 Application Insights のチームのメンバーが助けてくれることになったので、彼女に、Teamsで画面共有をして、「ほら、出ないでしょ？」と見せると、なんとテレメトリがポータルに来ている。その後
sisya 2020/12/21
頭の中に振ってきたものを検討せずに試すことを試行錯誤と言う無駄に感じるのではと感じた。まず最初にアイデアを取捨選択するという作業は、時間効率の意味で重要な意味を持つ。確認作業ができてない印象を持った。
リンク
1