Book: Software Engineering At Google - steps to phantasien
Software Engineering at Google: Lessons Learned from Programming Over Time: Winters, Titus, Manshreck, Tom, Wright, Hyrum: 9781492082798: Amazon.com: Books 今月のプロジェクト。いちおう読み通した。が、しょうじきだいぶ読み飛ばした。面白くなかったので・・・。 まず最初にこの面白く無さについて分析したのち読みどころを振り返りたい。 面白く無さの一旦が自分にとっての新規性の無さなのは間違いない。仕事でやらされていることの話なわけで。これは自分の問題だから、まあいい。とはいえ内容の新規性のなさはある。たとえば "Chapter 2. How to Work Well on Teams” とかさ、あなたそれ本一冊書いてるじゃん既に。読んだよ。リー
高速化日記 (5) - JNI - steps to phantasien
カメラは画像処理とかの性質上 C++ のコードを使いがちなのだが、各チームどころか各個人がアドホックに使うものだから .so ファイルの数が大変なことになっていた。社内のグループで "そうはいってもネイティブライブラリ減らすのって大変ですよね。我々も N 個から N-1 になかなかできずに苦労してます" というコメントがあったが「いや我々 M (>>>超えられない壁>>> N ) 個くらいあるのでとりあえず low hunging fruits からやっつけますわ」などと会話をしたら、M の大きさに相手は戦慄していた。 そんなん Blaze (Bazel) のせいで俺のせいじゃねーーー。とおもって放置していたのだが、全社的に性能問題への締め付けが厳しくなった結果 OS の中の人からチクチク言われることが増え、仕方ない尻拭いするか・・・と直したら色々速くなった。あ、ごめん・・・。みたいな気分
Attention Industry Complex - steps to phantasien
こどもちゃれんじに対する自分の抵抗をもうすこし長々と言語化してみる。気を済ますためであって、世間の親たちにケチをつけたいわけではない。 じぶんのこどもちゃれんじへの懸念は、Attention Resistance 勢すなわち Digital Minimalism, The Attention Merchants, Irresistible などを真に受けている人々の延長にある: この手のエンゲージメント強化型幼児教材は当初の目的(学力などの獲得)のためにユーザ(子供)の attention/engagement を exploit しすぎている。 一部の attention resistance はここに企業の悪意を見出しているが、個人的にはインセンティブのフレームワークみたいなものすなわち The System の帰結だと考えている。 ユーザーの Engagement すなわち DAU
誰が力を持つのか - steps to phantasien
製品開発においていちばん影響力をもっているのは誰か。もちろん組織構造で上の方にいる人が偉いわけだが、それはさておき様々な SWE, SWET, PM や UX など色々ある職能のうち誰が強いのか。 ブラウザをやっていたころは、プログラマが強い印象だった。自分が Web の API を増やす部門だったせいもあるとはおもう。プログラマ（のうち意見のあるアジテーターみたいな人）が色々とやりたいことを決める。PM は主にロジスティクスとか辻褄あわせとかをやる。仕事の性質上 UX はいない。Web API に限らず、ブラウザという製品の舵取りをするのは founding member のエースプログラマだった。今はどうだか知らないが・・・。 UI にしても、デスクトップだとメニューに要素を一個足すくらいなら UX に相談とかは一切なく新入りプログラマが思いつきで足すようなことを平気でやっていた。と
Peer Reviews - steps to phantasien
人事考課の季節。チームでの tenure が伸びてきたのと隣接チームと仕事をすることが増えた結果、今回は割と多めにピアレビューを書いた（といっても社内的には普通の量）。久しぶりだったので感想。なお社内のピアレビューには大きく「出世用レビュー」と「普段着レビュー」の二種類があり、出世用レビューは一段真面目に書かないといけない。あとは更に気楽な「一言レビュー」みたいのもある。今回は普段着レビューと一言レビューのみ。 まず、できる同僚に「おまえは良い仕事してるぜ！」みたいなレビューを書くのは普段の気持ちを伝える意味でも書いてて気分が良い。ただ「階級の期待値の記述を満たしていることがわかるように書け」と指示されており、そこは難しい。とりあえず自分の気分をバーっと書いた後、肩書期待値表を見ながら事後的に調整している。たぶん良い書き方ではない。 「もうちょっとこうしたら良い」的フィードバック。良い仕事
教えない対価 - steps to phantasien
「後輩を指導する」みたいなことを基本的にあまりやらなくてよい立場にいる。誰かを指導する行為には副作用があり、それを被らずに済んでいる事実を appreciate している。 多くの人々が無意識に払っているであろう「教えることの対価」についてそのうち書こうと思っていたが、最近は逆側にある「教えないことの対価」に出くわしがちなので、まずそれについて書く。 隣の席の同僚の書く UI まわりのコードにやや不満がある。性能改善のために UI まわりもさわりたいのだが、変更に弱くバグりがちで困っている。これはもうちょっと MVC とか MVP とかなんか architectural pattern みたいのも考えてくれや Flux にしろとはいわねえからよ・・・という抽象度高めの不満と、それコピペしたり雑に分岐する前にもうちょっと考えて整理してくれや・・・という細部への不満がある。 抽象度高めの方は件
実践 Backyard Grilling - steps to phantasien
Backyard Grilling の謎 のつづき。 持ち歩ける小型グリルおよび周辺機器を買い、家の patio で BBQ をしてみた。なおうちは二階建てアパートの一階で、表は駐車場と柿畑。 結論: 自宅で BBQ は無理。煙ですぎ。序盤の火を起こすところを乗り切れば何とかなるかとおもったけれど、肉汁や油が焦げるなど定常的にモクモクしまくる。タバコどころじゃない。ご近所ごめんなさいと胃が痛くなってそそくさと終わらせた。 それ以外はまあまあ楽しいし炭火で焼くと何でもおいしいので場所をみつけてやっていきたい。アパートにもいちおう BBQ エリアはあるので、そこに食材および火鉢を持ち込んでやるのが現実的かな。 焼いたものたち: 市販の冷凍バーガーパティ。チーズのせて溶かし、バンズも軽く焦がし、適当にはっぱなどを挟んでバーガーする。ふつうにうまい。 ソーセージ。うまい。しかも失敗しにくい。Hot
Backyard Grilling の謎 - steps to phantasien
近所の公園とかで家族 BBQ をしたい気がする。しかしいきなり公園に突撃しても火の付け方もわからないし失敗して飢えた子どもの不機嫌で休日を ruin するのもいやだから家の patio に小型の bbq 火鉢を買って実験できないかと考える。しかしこれもまた衝動的物欲のような気もするのでとりあえず BBQ 入門的なものを読んでみよう、とオンラインを冷やかしたのち Weber's New Real Grilling というレシピ本を買って眺めていると・・・よくわからなくなってきた。 この本は、一戸建居住者が自宅の裏庭に火鉢、というような生易しいものではなくこういうやつ、を置いてつくる BBQ 料理を主に想定している。そしてこれがアメリカ BBQ の基本っぽい。公園とかキャンプはこの延長にある特殊系という位置づけ。 しかしこうした grill は oven より便利なのか？便利か不便かはおいとく
On note - steps to phantasien
Kzys が note.mu などを使い始めるという。 むかし Mercurial ユーザだった頃、Kzys に「時代は Git ですなぜなら GitHub があるからです」と言われて Git を使い始め、それが圧倒的に正しかった体験から Kzys の流行りものへの適応には信頼を置いている。自分の中二病的アンチメインストリーム傾向は他人の力で訂正するしかない。（同じ理由で Higepon のメインストリーム力にも高い信頼を置いている。) 自分は Qiita や DEV に値するがんばった技術的文章を書く気はない。けれど note はつかってみていいかもしれない。それがなぜかはわからないが、それがなぜかを理解するために。 文章に課金したい書き手にただメッセージを公開したい自分のような人間が混ざるのは筋が悪そうではある。というか同業の Medium がその筋の悪さを pay-nudge-wal
画面の不透明さ - steps to phantasien
ソーシャルな場面、特に家庭で、ラップトップなりスマホなりの画面を眺めているのは感じが悪い。自分も食事中にスマホをされるのは不愉快なので家では夫婦とも食卓でのスマホはナシとしている。 一方、たとえば食後にソファなりベッドなりで画面を眺めているのはどうだろう。人にもよるだろうけれど、自分の感覚だとこれは食事中ほど感じはわるくない。一方で、子供がいるとやりにくいし、実際自分たちはあまりやっていない。しかし、結果として子供の目を盗んで画面を見るという本末転倒なことがしばしば起こる。なんか不毛。 いま子に画面を見せたくないのは、それが過剰に引力を持っているから。一旦画面に気を取られると、たとえば何らかの動画を見せろと tantrum が起こる。一旦見せても次々に見たがりきびしい。この問題は、ある程度は時間が解決すると思っている。 もう一つの問題は子に限ったことではなく、画面というものが持つ awkw
The Tales of Two Firsts - steps to phantasien
Eric Schmidt が最初に mobile first と言ったのは 2010 年らしい。興味深いことにリンク先のインタビューには Android が一言も出てこない。Sundar Pichai が AI first と言ったのは, 探した範囲だと 2016 年が最初。これらは自分の記憶ともだいたい一致している。 Mobile first がなんなのか、最初は誰もわかっていなかった。モバイルウェブをがんばれという話にも思えたし、アプリをつくれという解釈もあった。数年のちようやく「モバイルのアプリとしてサービスインする前提で製品をデザインする」のが mobile first だと人々は理解するに至ったが、新製品とかそんなにないので、まずは既存サービスのアプリをちゃんとするのが現実的な行動となった。アプリはみな最初はなんとなく Android 版をがんばっていたものの、世界の半分は iP
Book: Whilstleblower - steps to phantasien
Whistleblower: My Journey to Silicon Valley and Fight for Justice at Uber: Susan Fowler むかし Susan Fowler すげえなという話を書いたが、自分の認識は全然甘かったと深く反省した。件のブログはすごいクールにズバッと相手を切ったように見えたがそれは体裁であって、人生を賭けた一撃だったのだね。そりゃそうだよね。自分は「Stripe で楽しくやってる」とか書いたけど、件のブログを書いたせいで PR からめちゃ煙たがられたりして気の毒・・・だがその気の毒さは Uber が反撃のために送り込んできた私立探偵やおそらくインターネットトロルたちからの攻撃の酷さとくらべると些細な問題に見えてしまうという辛さのスケール。なお今は NYTimes の editor になり、思わぬ形で物書きになるという年来の夢を果
伸ばした背筋の記憶 - steps to phantasien
仕事日記、もともとの着想はワインバーグの「スーパーエンジニアへの道」という古い本から得た。 この本は会社員になってすぐの頃に読んで以来、仕事を真面目にする気になるたびに読み返している。別段新しい本でもないし、別にリーダーになりたいわけでもない（原題は Becoming a Technical Leader。）プログラマ向け自己啓発、今なら他にも色々あると思うので特に誰かに勧めたいとは思わないのだが、自分はなんとなく読み返してしまう。今もってるやつなんてこっちに引っ越してきたあとわざわざ Amazon.co.jp で買い直してる。 大した本でもないのになぜそんなに読み返してしまうのかと考える。たぶん、過去に自分が仕事を真面目にやろうとした頃の気分がかすかに蘇るからだろうな。それで背筋が伸びる。 20代の、自分がそのうちリーダーシップ的なものを持つと疑わなかった自分はきっと、この本を読んでやが
You probably don't need a single-page app | Hacker News - steps to phantasien
via You probably don't need a single-page app | Hacker News 自分も手元に SPA の悪口を書いた draft があるのだが、世間での hate が高まっているところに加えて言うこともないかなと思う。 なお自分は不満は開発者としてではなくユーザとしてのものである。すなわち世のウェブ製品や内製のツールが SPA になったとたん URL が壊れるなど激しくゴミ化する現象が観測され、気に入らないという話。出来の悪いコードというのはいつの世にもあるのだけれど、内製ツールという観点だとダメージの現れ方が厳しいと思う。 この話は長々書いても悪口にしかならないのでやめとこう。 それよりは、出来の悪い SPA はなぜ生まれるのかを考えて見る方がいい気がする。個人的には Web というプラットホームが十分な基盤を提供してないせいだと思う。JS フレー
Agile And Micromanagement - steps to phantasien
少し前に JIRA is an antipattern という記事があり、盛り上がっていた。どうも ticket を assign するという形で micromanage されることがあり、それが嫌という話らしい。 これはツールの濫用/誤用であるというのが主要な反論で、そうだろうとは思う。一方でツールやプロセスが暗に促す方向というものもあり、JIRA は micromanagement を遠ざけるような力を持っていない。それはそれできっと事実なのだろう。 自分は勤務先内製の bug tracker に長いこと不満を持っているわけだが、ひとつだけ良いこともあると気づいた。このツールは管理職が下々を micromanage するには出来が悪すぎるのである。一方、むかし Pivotal Tracker を使っているチームの TL/M によるものすごい micromanage を目撃したことがあり
More On 20-Percent - steps to phantasien
On 20-Percent を読んだ知り合いから反応があった。自分の考えをもう少し整理し、「20パーセント制度」の語りをめぐる自分の中のわだかまりを三つの論点にまとめてみる。 ひとつ目は、勤務先の中の人の語りは盛り過ぎではないかということ。20パーセント制度の成功例としてよく Gmail が引き合いに出される。Gmail はユーザ数が 1B を超える超大成功製品である。そんな成功を生んだ制度ならたしかに自慢の甲斐もある。しかしこの主張の信憑性は薄い。Paul Buchheit はインタビューの中でこう話している: [Larry] and Wayne Rosing, who was the VP of Engineering at the time, would sit down with engineers and give them projects. When they sat dow
出荷を見届ける - steps to phantasien
朝早く会社に来て、ほかの早起きな同僚たち数名と新製品発表会のライブを観る。いまのチームに入ってちょうど一年、ようやく仕事でやっていた製品が出ていくのを見届けた。年に一度のハードウェア発表に向けてがんばって働くこのソフトウェア開発モデルには懐疑的な自分だけれども、やや感慨はある。 今のチームは、自分が全く活躍できていない点を除けば割と良い。カメラはスマホの重要機能とみなされていて、しかもまだ良くなる余地がある。スマホ自体も競合に対しキャッチアップする側におり、それでありながら敗戦処理モードでなくやることがある。こういう伸びしろのあるチームで働く方が、会社員としての精神衛生を保ちやすい。 コードも、まあまあ良い。良くないところも多いが問題の多くは認識されており、人々に直す気もある。なのでコードを良くする仕事をしやすい。若干官僚的なところは気に入らないが、適当にしらばっくれている。それで角が立つ
何を仕事に数えるか - steps to phantasien
仕事、というとなんとなく会社に行って働く・・・でなくてもいいけど直接の対価のためになんかやることを指すように思えるが、趣味でコードを書くのもプログラミングの本なりネットの記事なりを読むのもブログを書くのも仕事だよなと思う。仕事というと若干ニュアンスが違うかもしれない。 Work といえばいいだろうか。Work Life Balance の Work. 仕事とか Work という言葉にアレルギーがあるなら career progression でも良い。 「仕事」と「勉強」を区別するのはナンセンスである。仕事と仕事以外の境目だってそれほどはっきりしていない。会社での仕事はふつう収入に直結している。投機性がない。いわゆる「勉強」には将来役に立つかもという期待があり投機的である。ここでいう期待は動機のことではなく、期待値とかいうときの期待ね。 会社の仕事にしろ、チームや組織の思惑と自分の思惑が
プログラミング言語の習熟 - steps to phantasien
C++ を書いていると、数年のブランクがあるにもかかわらず妙な安心感がある。自分は間違っていない、というと語弊があるが、自分の間違っている程度を自分はわかっている、というような。コードの質もなんとなく高い気がする。 仕事で Android アプリの Java を書いているときはそこまでの confidence を感じない。そこそこだろうとは感じている。 Python とか JS を書いていると、我ながらこのコードはダメだなと思う。しかしどう良くしていいか検討もつかない。似たような話を前に書いた気がする。 最近のモダンメインストリーム言語、すなわち Go, Swift, Rust, TS とか全然使えない。Kotlin は Better Java として使っている範囲ではそこそこだと思いつつ、Kotlin を活かしている感じはない。 自分は学生時代、 C++ の習得に莫大な時間を費やした。学
2015/02/04: 謙虚なリーダーシップ - steps to phantasien
数年前に二泊三日のリーダーシップ研修みたいのを受けた。上司の指令により送り込まれた。そのトレーニングは一部の社内ボランティアが始めたもので、評判がよかったのと運営してる人の熱意などにより全社的なエンジニア向けプログラムに格上げされていた。教えるのは普段はエンジニアしてる人たち。各種アクティビティを通じリーダーシップを学びましょう、みたいな内容。講義:グループワーク が 2:8 くらい。 US, ヨーロッパ, アジアで開催があり、僕は東京で開かれたアジア枠に参加した。参加者は中国、韓国、インド、オーストラリアから。転勤で海外勤めしているアメリカ人やヨーロピアンも結構まじってる。 主たるメッセージは、自分の主張ばっかりしてないで一歩下がって話を聞き議論をまとめ合意を引き出す工夫をしましょうね、というもの。最初のグループワークは参加者数十人が全員でやる大人数作業。参加者が意思統一し足並みを揃えて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
