A Story Writer

(Caution: This is yet another ChatGPT-4 experience report that everyone has been writing these days. If you don’t like those, you’d better stop reading.)

My spouse had an idea: When we travel by airplane, it might be a good idea to record our reading-aloud of children’s books. Although some audiobooks are available, the selection of Japanese child books is limited in the audio market. And we read these books every night anyway, so why not record them?

Inspired by that, I got another idea: Maybe we can generate some personalized stories for my daughter using ChatGPT and read it to her. My father once wrote one for me when I was a kid of, and I remember loved it.

Even better, I can possibly make a podcast based on these “AI stories”. (What a stupid dad – you might think, and you’re probably right.)

So I signed up for ChatGPT Plus, enabled GPT-4, and gave it a try.

It was fascinating and disappointing at the same time: It does generate some short stories. What it spits out might be too short with a vanilla prompt, but you can tell it to generate “chapter N” to split it up.

Besides the length, I have encountered a few other problems:

The first problem is that it stutters: It stops generating the text in the midst of a sentence. It feels like a bug. I hope they implement some backtracking to keep it moving.

The second problem – although I’m not sure if I should call it a problem – is the boredom of the story: What it writes is extremely stereotypical and boring. It is, however, probably by design. The role of the language model is to generate “most likely text”, and that basically means being stereotypical and boring. In theory, OpenAI can “align” the model towards interestingness. But I’m not sure that’s the direction they would like. (This is not about the “temperature” – the disturbance of the generated text. I don’t think tuning the result less statistically likely makes the text more interesting. It would just make it more unintelligible.)

There is an escape hatch: You can mitigate the problem by explicitly directing the plot: Reject the boring part and ask for a retake. Give some clues on where you’d like to go.

Also, you can maybe ask for options for the plot first, then pick one of them to proceed. This “breast-first search” is something I’d like to try on the next iteration.

The third problem is more serious and for now a deal breaker to me: Its writing style is so cheap!

It’s known that you can ask for the writing style of famous writers, like Haruki Murakami, if the author is famous enough that the crawler has a good amount of data to mimic. But our (Me and Yuko’s) favorite writer of children’s books, Miyoko Matsutani, doesn’t reach that threshold. GPT-4 knows something about Matsutani and it tweaks the style a bit, but it’s far from satisfying. After all, I’m very picky about Japanese writing style and probably don’t care for “Internet Japanese” that GPT is based. I long for more boldness, beauty and authenticity. (What an old grumpy guy – you might think, and you’re probably right.)

The situation will change once OpenAI opens up the fine-tuning capability of their new models, and once it does, I’ll spend days and nights typing in Matutani’s work for training… well, maybe scanning all the books to OCR or cracking the ebooks to scrape, or whatever.

One thing I haven’t explored is the longer prompts: GPT-4 is known to be capable of ingesting much longer prompts than its older versions. My current prompts are a few hundred characters or less. It should go up to like a few thousand. (I’m not sure how byte pair encoding ingests Japanese text. My conservative guess is about one Japanese character per token.)

What should I ask to align the output to the Matsutani style? Is it even possible given her work isn’t in the model’s memory? Should I give some snippets as an example? I have no idea. It clearly needs more experiments and creativity.

Another possibility is to accept the “Internet Japanese” and the absurdity of the generated story, and push the model to the limit to see how crazy it can go. I’d never read it to my daughter, but it can be a great podcast episode. Maybe someone has already done that, but a few more is probably fine.

Despite the technical limitations, I consider my own creativity and taste as the largest limiting factors – How can I push the model hard? How can I judge the “interesting-ness” of the story? How to give it the right direction? It’s a creative challenge that might be worth pursuing.

That said, I’m not sure if it’s my kind of challenge. I should probably read more existing stories to my daughter using that time and energy: The stories are abundant out there, and the time with the little mine is a bit more scarse.

(For the record, here is my first attempt as a GPT-powered story writer. I’ll report back if I get better.)

It’s Time to Get Back to Work

Given both the competitive landscape and the safety implications of large-scale models like GPT-4, this report contains no further details about the architecture (including model size), hardware, training compute, dataset construction, training method, or similar.

gpt-4.pdf

“GPT-4 is not easy to develop. It took pretty much all of OpenAI working together for a very long time to produce this thing. And there are many many companies who want to do the same thing, so from a competitive side, you can see this as a maturation of the field.”

OpenAI co-founder on company’s past approach to openly sharing research: ‘We were wrong’ – The Verge

It dawned on me that they officially ended the era of AI as a research, and switched gears towards AI as a product. For many startups, AI has been a product, not a research, and OpenAI is one such startup, but they have pretended to be a research lab of a big tech company or an elite university. Although there have been signs of this shift, like not releasing the GPT-3 model to the public, they still kept publishing research papers and people loved it. Until now.

Another iconic line from the GPT-4 “technical report” is the Authorship section (p.15) – It looks a lot like a staff roll of a movie, and it asks: Please cite this work as “OpenAI (2023)”. This would never happen if it were a research paper. This signifies that GPT-4 is a product and the whole company has worked towards building it.

What does this mean? When their researchers have done the research-y stuff, it’ll be folded into the next version of GPT and won’t become a standalone research. No published paper that is.

And I think it is already happening. Look at the paper about the Vision-Language model CLIP. This is their early iteration of visual understanding and you can consider it a building block of multimodal models like GPT-4.

This paper is two years old. If they kept doing the “research”, they should’ve been another paper for its successor. That didn’t happen. There is no CLIP-2; they have built the progress into GPT-4 instead. This is how product development works: The innovations occur inside the product. (Compare this to MSR which has up to three generations of VLP models!)

After all, there are no papers about, say, Google’s ranking algorithms (forget Page Rank), Facebook’s feed scoring, Amazon’s logistics, or Apple’s CPUs. These are all the marvels of computer science achieved by smart Ph.D. people, but all have occurred in the products. Few papers (if not none) were written. GPT has morphed into one of these monumental products.

Am I disappointed? Definitely. Do I complain? Not really. Academic research has its limitation. Sometimes innovation needs a product. It needs a user. It requires real problems. It demands money to earn. That’s why tech companies hire Ph.D. and let them write production code instead of academic papers.

The downside is that it mostly happens behind doors. This darkness however is worth it, at least for the innovating engineers and researchers themselves.

However, for us begging paper readers – It feels like the end of a great season. It’s time to get back to work.

I still hold a hope: Someday, once this war is over and the victory makes the GPT gangs rich, one of them goes back to school, write a textbook about AI, in which there is a chapter called “History”, and they share their retrospective as an insider: What they did right. What their peers overlooked. What the vision was. To what extent it is achieved, and don’t forget some technical details. It’d be a fascinating read.

Until that book arrives, I’ll keep reading. Well, I should get back to work. But after business hours, I’ll keep reading.

McDonald’s Theory Of Bug Fix

I like Jon Bell’s McDonald’s Theory and have put it to use from time to time. Last Monday was one such day.

My boss gave me a random bug. I debugged it and figured out what was wrong, but I was still unsure how to fix it. The code seemed to have some layering violations, but the right way to distribute the responsibility between the layers was unclear.

Looking at the commit history, the person who can fix this became apparent. I was wondering if I should just reassign the bugs to them, but that kind of action has had mixed results: People tend to push back, dodge or ignore. No one wants to waste their time on bug fixes.

Then, the idea of McDonald’s Theory came to my mind: Instead of reassignment, I “fixed” it anyway, and sent the PR to that person. To my own credit, I didn’t make a McChicken fix. I tried my best, and I’d consider it more like a McCrispy.

Yet, I know they will push it back. They indeed did. It was still a cheap McDonald’s fix. And it worked as McDonald’s: They thoroughly explained how wrong my “fix” was in the PR comment. So I appraised their analysis, pointed out they are much better positioned to fix it then asked to take it over.

As the theory goes, they agreed. And they gave me their version of the fix after a couple of days. It was better for sure: Instead of piling crap like mine, they removed the code in question. The layering violation seemed to be a leftover from some past refactoring, and the smelly code was not necessary after all. My faith in the theory has elevated.

I should acknowledge my luck that I hit the good engineer. The pattern I had seen was either 1) People just took the crap or 2) People pushed back but did nothing. Neither happened. They did what was supposed to be done, and I appreciate this healthy ending. People shouldn’t eat McDonald’s every day, and they need the ability to cook a good meal.

Morning Spinach: February

2023-02-15

2023-02-17

  • きのうは寝坊してできなかったが、Podcast 準備です。

2023-02-18

  • 飛行機の搭乗に間に合わない、という悪夢で目が覚め疲労困憊。05:15.
  • Podcast 準備つづき。

2023-02-20

  • ハイクの疲労で起きたら五時。
  • 引き続き podcast 準備。
  • 終了。しかし収録は来週。
  • 次なにやろうかなー・・・という前に、税金をやらねばならぬ・・・。
  • 税金。終わらすぞと思うも自社株向け証券会社のやつが来ていない。しかも来月中旬まで来ないらしい。相変わらず suck である。こいつの入力が一番大変なのに・・・。大変な理由は売れる分をこまめに全部売る設定にしているからで、これをやめえばラクになるし過去十年はこれをやめた方が圧倒的に儲かったが、もうそういう時代は終わりました・・・というか自社株保持とか怖くてできません。やれやれ。まあいいです。3/14 までは no actionable items なのでなんか他のことに時間使います。

2023-02-21

  • 04:35
  • 考え事でもするか・・・と思ったが、その前に溜まっっている Todoist で消化できるものがないか見るべし。

2023-02-22

  • 04:22
  • 引き続き考え事

2023-02-23

  • 04:38. 財布をなくす悪夢

2023-02-24

  • 雨ですねえ。
  • Accepting The Funny Mediocrity – Spinach Forest
  • やりたいことを書き出してみたが、まず子の Kindergarden のサイトを crawl して写真を集めるのが最初だな、と思い至った。なぜならサ終に伴いあと一ヶ月くらいでサイトが閉鎖してしまうからです。ひどい。
  • Python (Playwright) でやるか JS (Puppeteer) でやるか。Python の方が慣れてるが、Puppeteer の方が headless としては出来が良さそうなので悩ましい。良い機会だから JS/TS に入門しとくかなー。

2023-02-25

$ npm install --save-dev @types/puppeteer
npm WARN deprecated @types/puppeteer@7.0.4: This is a stub types definition. puppeteer provides its own type definitions, so you do not need this installed
  • 世の中は進歩しているぞ！
  • では Shutterfly のサイトにログインしてみましょう。
  • この XPath 叩ける $x ってなに？どこから来てるの？とおもったら “Console utility function” なのか。べんりじゃん・・・。
  • こういう便利機能もさー、たくさん devrel 雇ってるからこそ生まれるんだよわかってるかい社長さん・・・とか不景気なことを考え出すと幸福感が薄れるのでやめるべし。
  • 時間切れ。

2023-02-26

  • 04:30
  • つづき。
  • TypeScript なしに async/await なコードを書ける気がしない。Vanilla JS ヤベーな。がんばって TS にしておいてよかった・・・。
  • サイトの出来が悪いのか page load 終了を安定して検出できないためしょーもない workaround を沢山いれて乗り切るが、本質的にそういう仕事です・・・。
  • なにかとよくわからないページ遷移が発生するせいで Puppeteer の JS が死ぬので、かなり checkpointing を真面目にやって途中で死んでも継続できるようがんばらないといけない。時間切れ。
  • 昼。妻子外出中につき継続。
  • Hover すると表示されるメニューをクリックするとどこからともなく (Content-Disposition で) ダウンロードが開始されるというクソ仕様なのでどうすんだこれ・・・とおもったら Page.hover() method があるじゃん！Puppeteer すごい！
  • ダウンロードとかどう処理されるのだろうか・・・とおもったが headless ブラウザなので普通にダウンロードされるらしい。ダウンロード先どこやねん、というと、裏口API を使う。なるほど・・・。
  • 動いた！すごいぞ Puppeteer!
  • Node.js 16: setTimeout with async/await | LinkedIn
  • 古い方法で書いてしまったので後で書き直そう。

2023-02-27

  • 04:25. つづきやんぞ。
  • 更にいくつかの setTimeout() と retry を追加したところ、動き出した。
  • とおもいきやまたコケる。そのたびに適当なワークアラウンドを足す、の繰り返しである。この retry は higher order function で書き直したいが、それよりはさっさと片付けたい気持ちが先立ってしまうな。
  • しかし一日あたり 100-200+MB くらいのデータが 200 日分ある。Google Photos にアップロードしようかと思ってたけど、ちょっとでかい。そういえばむかし secon.dev で JPEG を WEBP に圧縮する話をみたな。全部おわったら真似してみよう。
  • PC の auto suspend を一旦 off にしておく。そして待ってる間やることもないので Google Photos の API でも調べるか・・・。
  • Library API overview  |  Google Photos APIs  |  Google Developers
  • Shutterfly scraping の 10x くらいめんどくさそうだな。CLI のツールとかないだろうか・・・。と調べるとあるにはあるが、あまり手堅い様子ではないなあ。
  • gphotosuploader/gphotos-uploader-cli: Command line tool to mass upload media folders to your google photos account(s) (Mac OS / Linux) これはどうかな？アップロードの仕方がドキュメントされてない・・・が、 API をたたくかったるさを考えるとこれを使うのが良さそうである。機能リストをよむと色々実装しなければいけないことがわかって尚更。そして上の secon.dev の記事もよく見ると同じツールを使っていた。
  • それにしても最近のプリスクールはアプリベースのサービスを使ってるところが多いけど、それで Web UI がない日には scraping とかできなそうじゃない？どうするんだろうね。というかどうもしないのだろうけれども。
  • なお学校の写真というのは別にポーズ取らせたりせず遊んだり作業したりしてるのを邪魔しないように遠くから撮ってるだけなので、そんなには面白くない。しかもつい最近まではマスク着用のため尚更である。あと割と無理にズームでよっている。電話機は Pixel 6a を使ってくれておりありがたいけれど、Pixel 7 Pro を進呈したい気になる。これは absurd でありながら過去に何度か真面目に考えたけど、もう電話機部門勤務ではなくなってしまったので、さすがにナシだな。
  • 時間切れ。ダウンロードの進捗は 1/3 くらい。途中でコケ無い限り、今日中にはおわることでしょう。
  • 勤務開始直前。終わってる。そして 50GB くらいあるなどうするべこれ・・・。圧縮して半分になってもちょっと Google Photos には置きたくないサイズである。気分的には 10GB くらいが budget なので、downsample して 1/5 くらいになってもらうかなあ・・・。Shutterfly がサ終したくなるのも無理はない。

2023-02-28

  • 04:45. ねすごし…
  • とりあえずダウンロードした写真は zip にでもして作業ディレクトリ外に避難しましょう。本来なら GCS にでも避難したいところだが、でかすぎて時間かりそうなのでまた別の機会。
  • xargs で時間を溶かし、Python に避難。シェル力が低すぎる・・・てか最初から Python で書いていれば並列化とかもできただろうに・・・むしろ TS で書くべきだったか・・・。
  • はーやんなっちゃうぜ時間切れ。
  • しかし冷静に考えて Google Photos に 200 個以上もアルバム作っちゃうのだろうか自分。狂気なのでは。
  • Delete all photos from an album from Google Photos : googlephotos そうだよねアルバム消しても写真消せないよね。やはり preschool 写真を共有目的で Photos にアップロードするのは危険すぎるな。Drive 使うほうが良いかなあ。一個くらいやってみるべきか。
  • prasmussen/gdrive: Google Drive CLI Client こういうのを使うらしい。Google Drive は directory based な permission がないせいでほんとこういうの nervous でやだな・・・。
  • ていうか皆様 iPhone で Mac なのだから Google Photos を経由しない時点で WEPB 使えないじゃん。終了。HEIF … と一瞬思ったが今度は自分が見れんわ。これが first world social divide というものです。
  • 覚悟を決めて 50GB をアップロードするしかない。まあ一時的なものなのでいいです・・・。
  • 明日は podcast の公開作業をしなければなりません。

Accepting The Funny Mediocrity

2 年前に書いた Having Fun on The Dead Carrier は思ったより正しかった。けれどまだ板についていない。

8 年くらい前、それまで Web に傾倒していた反動で Android アプリプログラマに鞍替えした。結局モバイルはそれほど好きでないと思いつつ今日に至っている。ML やクラウドといった世の流行りに沿った仕事ができる日はこないだろうし、勤務先はともかく一般にモバイルエンジニアの給料は低い。だから異業種も同業種も転職のあてはない。なら今の職場で出世できないかと頑張ってみたが器でないことがわかった。

もはや仕事には大きな変化を期待していない。今のような業務が、少しずつ姿を変えながら、少しずつ給与を下げながら、ずっと続くのだろう。続くならまだいいが、勤務先でもレイオフが起きた。もはや継続性すら疑わしい。レガシー分野のプログラマ、将来が不安。

日々の業務が嫌というわけではない。チームを移ったばかりで ramp up するストレスはあるにせよ、理不尽なことにイライラしたり退屈すぎてうんざりといったことはない。ぼちぼちコードをかいて、ミーティングとかで人と話したりして、他人のドキュメントやコードをレビューもして、定刻に職場を出て家に帰る。20 代や 30 代のような熱意はないが、嫌でもない。コードを書いて何かが動けば多少の満足はある。レイオフは、今のところやり過ごせた。日々は平凡なりに滞りない。

憂鬱なのは将来を考えるときだ: 大きなことを成し遂げることはないだろう。大きな何かに立ち会うこともない。かつてのように夢中で働くこともない。でも、それがキャリアの帰結なので仕方ない。ぱっとしませんでした、残念でしたね。というだけ。

スキルがレガシーで、特定大企業に最適化されていて、その企業の先行きは不安。しかし現代的で勢いのある職場・職種に鞍替えする資源やリスク予算がない。息苦しい。「仕方ない」とは言いたくないが、自分のパラメタを鑑みて現状を選んでいる。より良い答えは特にない。ぱっとしない中年、将来が不安で息苦しいですね、というだけ。

一年の終わりやはじまりに我が身を振り返り将来を思うと、憂鬱が露わになる。それをを拭うことはできないかと考え、できないと思い至り絶望する。何度も何度もこれをループして時間を溶かし、心をすり減らせる。不毛。

業務でない課外活動は将来への準備だと思っていた。けれど準備が実ったことはない。大した準備もできなかった。少しばかり課外活動をしたくらいで将来有望な仕事に鞍替えできはしない。暇も体力もない自分が、暇で元気な若者が注ぎ込む湯水のような時間の勢いに競り勝てるはずがない。（これはぱっとしないなりに結果を出した裏返しでもある。全てを投げ出し新しい分野に掛け金を突っ込むよりは目先の仕事を続けたほうがマシと考えているのだから。）

新しい仕事のために新しいテクノロジを学ぶ – そんなファンタジーがなくなると「将来への準備」はただ気が重い。出世のための本を読む。LeetCode でレイオフに備える。希望を呼び起こしてくれた課外活動が、不安と憂鬱を反芻する時間になる。とても続けられない。無念や不安と毎日向き合う根性は無い。

準備はもういやだ。キャリアの残念さや、将来の不安や、根性のなさは受け入れるから、課外活動くらい楽しいことをしたい。それが Having Fun on The Dead Carrier だった。この結論は今も変わらない:

職業プログラマとしてのキャリアが冴えない結末を迎えるとしても、迎えるからこそ、そのキャリアを通じて発見した価値を大切にしたい。新しいテクノロジを触る刺激。コンピュータサイエンスのセンスオブワンダー。プログラミングの充足感。枯れ果てた未来の水やりに追われてこの美しい園を失ってしまったらあまりに悲しい。

日々の業務はきんとやるとして、その外では楽しいこと、役に立たない学びのあることを好きにやる。課外活動は将来のキャリアへの準備ではなく、キャリアから得た楽しみの養生。この二つが交わらないのは残念だが、交わらない以上どちらかを選ぶ必要がある。

トレードオフ。

課外活動では、被雇用準備による将来収入の改善という金銭的な利得を、価値観の養生という Well-being と引き換えている。根性がなく、頑張ってなにかやるのが高く付く（頑張れない）のでこのトレードオフを選んでいる。

昼の仕事では、やりがいや裁量といった個人的な関心を引き換えに、払いの良さという金銭的な利得と9時5時労働という時間的な利得を選んでいる。家族を養う稼ぎの必要性と家事子守という家庭の責務からこのトレードオフを選んでいる。

この二つを組み合わせると、昼の仕事で金銭を選ぶ代わりに課外活動で金銭以外を選んでいるとも言える。トレードオフとしては妥当な範囲と言えるんじゃないか。

トレードオフが必要という事実、つまり仕事のやりがいと収入が両立しなかったり、課外活動の充足と将来の準備が両立しないのは残念だが、それがまさにキャリアの失敗であり、ぱっとしなさなわけじゃん。それを無視してうまく行っているフリをしたら、家庭や Well-being や金銭を予期せぬ形で損ねてしまう。金銭は家庭や Well-being の足場なので、結局は家庭と Well-being を選んでいる。書いてみるとあたりまえの話だった。

もっと根性や計画性や先見の明があってキャリアをうまく積み上げられればよかったとは思う。けれどそうした後悔で日々を惨めなものにしたくもない。だから Have Fun と繰り返し言い聞かせ、選んだ現実を日常に塗り重ねていく。

In 2020s, Don’t Listen to Java Haters

To me, the book “A Philosophy of Software Design” was hard to go through.

An example of many frustrations: When talking about a hypothetical HTTPRequest class, the author first shows the “bad” version of an API:

public Map<String, String> getParams() { … }

And criticism is:

This method is shadow, and exposes the internal representation used by the HTTPRequest class to store paramters. Any change to that representation a change to the interface, …

Okay, what’s the alternative then?

Here is a better interface for retrieving parameter values:

public String getParameter(String name) { … }
public int getIntParameter(String name) { … }

getParameter returns a parameter value as a string. It provides a slightly deeper interface than getParams above; more importantly, it hides the internal representation of parameters. getInParameter converts the value of a parameter from its string form in the HTTP request to an integer. This saves the caller from having to request string-to-integer conversion separately, and hides that mechanism from the caller. Additional methods for other data types, such as getDoubleParameter, could be defined if needed.

Ouch.

  • If you are bothered by converting String to int, you shouldn’t program in Java1. Whether you like it or not, composing small methods is a way to write Java code. Going against the community norm has a price, and the author doesn’t seem aware of it.
  • Talking about awareness, I’m not sure the author is aware that Map is an interface and doesn’t have to be an “internal representation”. This signals the insufficient competence of the author as a Java programmer.

There are a lot like these. Zooming out, the hate for the convention of the Java community, and some of today’s programming practices (which are more modern than Java’s) permeates throughout the book. It seems that the author is primarily using C++. Also, his suggestions feel more applicable to C++ than to Java.

If so, the author should have used C++ instead of Java. If you don’t like Java, why bother? Everyone knows it’s a language out of fashion. Maybe the author thought Java was still more appealing than C++ to the general audience or their students? I have no idea.

Because of this dissonance, I have a hard time trusting the author – If the author thinks they know what they actually don’t, are his claims actually trustworthy?

But for the sake of a better review, let me mute my loud disbelief.

The problem with this book is that it claims the suggestions are generalizable when they don’t. Each programming language has its own trade-off, from the grammar to the runtime to the ecosystem. Things that matter for C++ won’t matter in Java, Python, or more modern languages.

My sense is that the suggestions in this book aren’t even appropriate for today’s C++. However, it makes more sense for thicker API boundaries like OS system calls and RPCs/REST where type systems are limited and programming language matters less. Ideas like “Deep module” and premature generalization can shine in this worldview.

This observation aligns with who is praising the book: Apparently, people around distributed systems and infrastructure platforms like this book a lot. In that world, the programming language does matter less: Things are polyglot and the boundaries between modules are thicker there.

On the other hand, to someone who works on a big monolithic code base written in non-C++, this book is baffling.

If this book were titled something like “A philosophy of platform modularization and API design” and was written with that focus, dropping all the irrelevant rumblings, it could have come out great and I might have loved it3.

It is OK to write code with minimum utilization of the language-specific features. Such an attitude was common until the early 2000s when the mainstream languages were poor. It is still okay sticking that same style today, but I don’t think that is what a reader expects from a book published around 20202.

Also, it’s fine to criticize Java. In the late 2000s, there was a large disappointment in Java. It accelerated the adoption of “lightweight” languages like Ruby, Python, and JavaScript. It also prompted the rise of modern statistically typed languages like Go and Kotlin.

But if you do criticize, do it well. What “A Philosophy of Software Design” did is less than talking two decades past. As a reader, I expect something better.

Talking about the reader’s expectations, chapter 19, “Software Trends”, is truly a killer. Why are you talking about OOP, Agile, and Design Patterns as trends now? Pleaaase!

Footnotes

  1. You should use Kotlin – I’m kind of kidding.
  2. The first edition was published in 2018.
  3. Here is another and narrower criticism of this book I wrote before. I won’t write another one.

Link: “The worst part of this is that everyone at GitHub is now forced to use Microsoft Teams.”

The worst part of this is that everyone at GitHub is now forced to use Microsoft Teams.

GitHub to layoff 10% and closing all offices | Hacker News

I haven’t used Teams and am not sure why it gathers that much hate. I’ve been “forced” to use Google Chat. It’s not as good as Slack I guess, but I’m fine with it.

Why do people love Slack so much? Do you like workspace chat in general? I like group chat but only if it’s private and among friends.

A Corner to Breathe

I haven’t taken a “real” break at work since I moved to the new office. The building of the new office is small and packed. It doesn’t give me either space or anonymity. The real break needs both – You need space where no one notices you, where you can take a breath and let your mind dress down.

Luckily, or by design (to the credit of the employer), there is always space. Many buildings have a few corners with sofas or stools. What’s missing is anonymity. So I walked to the building next to my new office, lurking around, and found this:

This is the perfect corner to have a break:

  • Nobody in my team will come here. Nothing fancy is around.
  • Nobody is stopping here. People tend to choose somewhere close to drinks and snacks. It’s on the other side of the building.

This place is too bland for the tastes of many, and that creates the anonymity I need. It has moderate foot traffic and therefore is not super silent, but that’s fine. I’m not asking much. Or I can keep searching for even more perfect corners if I desire. For now though, this will suffice.

When you move, you lose something subtle you don’t notice. You might need a checklist to pick it up again, and this is the first item of that list: Find a corner to breathe.

Peak and Bubble

During the tax return prep, I found my total income declined 10+ percent last year. This is primarily because of the stock price drop.

Next year or the year after, my income will fall, possibly another 10+ percent, this time because of lower performance ratings1. I had a long tenure in my last team and my previous manager gave me a high rating. As I moved to a new team starting a new role, the good rating is unlikely to sustain.

This is not a pessimism. It’s just a phase I have to go through. It happened the last time I moved, although, unlike this time, the stock growth softened the impact. That won’t be the case this time.

A slightly pessimistic twist: I’m not sure if I can “recover” my rating. I think my nice rating reflected a good opportunity I had, which is not common these days in hindsight. Also, my energy level has fallen for years. I’ll do my best to keep up, but don’t expect much.

This means that: 2021 was probably the year when my income hit its peak. I won’t see that price tag again in my career.

This might sound sad, but I am not that disappointed. I rather feel a kind of gratitude. The tech sector has been in a longstanding bubble, and we are all the tulips. I’m glad I was able to experience this bubble. It wouldn’t have happened if I wasn’t here. This is a sheer fortune.

And now, the party is coming to an end2.

The bubbles did feel nice. They were just a bit slippery, as are their residues. From now on, I have to walk a bit more slowly so as not to stumble.

Footnotes

  1. In addition to an extra stock price fall which is pretty much possible.
  2. Another party is starting, but I don’t think I’m in the room.

Link: Ask HN: Suggestions for working effectively with junior devs at FAANG | Hacker News

I’m a senior dev at one of the FAANGs with more than 15 years of experience, but the rest of my team consists of devs with an average of 2 years of experience. At first when I joined, I thought this was an aberration, but there are many teams around me that are structured similarly. Is this how FAANGs try to scale teams?

Ask HN: Suggestions for working effectively with junior devs at FAANG | Hacker News

The top comment:

And in general, there are two ways to go. The first is to accept the fact that many senior engineering and most staff engineering gigs are more about this kind of mentorship approach than actually doing work. And basically accept that the prime “getting shit done” years of your career are done and you will mostly be working in this new way now.

Unfortunately you will either need to change your attitude or change teams. In y… | Hacker News

One day I pointed out the massive amount of the code and design doc reviews the TL of my team is conducting every day, to the TL himself. His response was something like the top comment.

According to him, he used to do everything but that wasn’t sustainable. He was told to “delegate”, and in my guess, to mentor. That is what he’s doing these days.

I cannot articulate what I think here. He’s a good mentor, a good lead, and I appreciate that, but…?

Monica

Personal CRM done right – Monica

Yuko and I started using the Monica Personal CRM a few months back. We find it useful. Today It has about 140 contacts and about 150 activities recorded. The number keeps growing. Let me walk through how we use it and whether it can be helpful to you.

TLDR: We like it but I don’t strongly recommend it because of its niche nature.

What Is Monica?

Monica is CRM, that is, an address book with richer metadata. You keep records of people with their names, birthdays, relationships (who is married to who, and whose parents are who, etc.), notes, and other attributes.

  • In the parenting context, I tend to recognize other parents as nameless, saying, “Mike’s dad”. This is problematic in the first name culture, and not very respectful even outside the cultural radius. Monica helps me remember their names1.
  • The birthdays of the child’s friend circle are important for gifting purposes.
  • Some other basic attributes are also worth tracking: Their current and past jobs, where they are from, how we met them, etc. These are often mixed up if you don’t take notes, and such a mix-up can cause some minor embarrassment.

It is also a journal. You keep records of activities you did with these people: Went where with whom, who said what, who gave us which, and vice versa, etc. You can look back at these chronologically and it helps since:

  • This is another form of metadata, but you don’t have to organize it in any canonical way. All you have to do is add a journal entry with people tagged.
  • The memory of the conversation evaporates quickly if you take notes, and you’ll have to ask the same questions again and again. The activity log reduces that social awkwardness.
  • You share the conversations with your spouse. Although you can do it over the dinner table, having the written records is a nice addition.

Asking Personal Questions

For me, one unexpected benefit is that I became more curious about other people.

I thought I was indifferent to other people and often forgot what they told me because of my indifference. This indifference has amplified my social awkwardness.

However, I realized that I was indifferent because I forgot. I was afraid of asking personal questions partly because I forgot what I heard and I had to ask the same questions again and again. I feard the awkwardness and the fear made me more indifferent to other people2.

Monica gives me a place to take notes, therefore making me less forgetful – I can just take note of what I heard. It becomes my assisted memory.

Once you unlock to ask personal questions, small talks become a bit easier. “How are you doing” becomes a source of a journal entry in Monica. I don’t say I become a more interesting person, but at least I become more interested in the other side of the talk. That does help.

Even better, it is also our assisted memory: I can share my findings with my spouse. This collective nature makes the memories more useful and robust.

Is Monica Worth It?

Monica isn’t for everyone. First of all, not everyone needs personal CRM. Some people are just good at remembering this kind of people’s details super well. Others are not, but they don’t care. You want something like Monica only if you’re in the narrow window of a “not good at this but do care” personality.

Even if you are in that window, adopting Monica can be a high bar:

  • The membership is expensive – $9/month. Monica is open source and some people choose self-hosting because of the price.
  • The UI design is outdated and some important features like full-text search are missing.
  • They don’t have mobile apps.

They are working on a new version and I hope it’ll fix the feature parity and UI problems, but the price will be the same. Niche products are expensive.

Still, we will stay on Monica because:

  • It allows sharing notes with family. This isn’t free with more mainstream tools either. For example, Notion costs as much as Monica ($8/m) if you want the collaboration bit.
  • The dedicated UI is better than the generic UI (say, Notion or Spreadsheet).
  • We know we use it somehow.

I tried other mainstream tools but none did suit well enough to stick.

I hoped there were less-niche options than this. In fact, we used to use Highrise from 37sinals. But they sunset it3 a while back. There are some others in this genre, but none are for families. Apparently, family-oriented CRM isn’t a big-enough market.

Overall, I wouldn’t strongly recommend Monica to anyone. It’s a bit too niche and too indie.

I’d rather ask other families how they keep up with the growing flow of relationship-oriented information. Am I just too bad to remember these relationship things?4

Footnotes

  1. Without asking my spouse about their names which are in her text archive.
  2. Besides the fundamental indifference I have. I have accepted that to some degree.
  3. To their credit, they’re still running the app. But no updates are available anymore.
  4. I don’t want to believe it, but I kind of know the answer.

Link: Actually, Japan has changed a lot – by Noah Smith

There are some interesting numbers in the first article.

Every time I find Japan-related posts in places like HN, I realize how little I know about Japan. I stopped paying attention to Japan-related news when I moved to the Bay Area, but I admit that I didn’t pay attention either even when I was in Tokyo.

I was a typical single nerd male who didn’t read the news. And I’m not sure I should have read more – What was the point of being informed if the only choice was to live in Japan and (although I didn’t realize) I was in a pretty privileged position? Well, there were points, but there were other priorities.

Now being an expat with a hypothetical option to move back or not, should I read more about Japan? I still don’t know. Such a decision is probably led more by local and personal context than the global, objective parameters like GDP or mortality rate.

If that’s the case, why do I subscribe to NYT and read the U.S related news? Isn’t living in the Bay Area a personal, local choice? (It is.) That’s a fair question. I used to think that this is a survival strategy as an expat and that there are also some moral values, again as an expat, to be aware of the local habitat, and to blend in.

For some reason, these points don’t feel as convincing as they used to be. Nowadays I rather read it just because it’s interesting enough at a pass time. They have good writers and some articles are deeply researched and well-written. I didn’t have that feeling when I was reading newspapers in Japan. Also, exposing myself to the American value system still feels fresh to me.

This too is very subjective. I consider myself a very picky Japanese reader who has strong taste. And I consider myself a very mediocre and slow English reader who has less than middle-school vocabulary size. This fluency gap surely biases my judgment here.

It’s ironic that I read less because I can read more. Maybe what I should do is read The Japan Times or Nikkei Asia. It sounds as ridiculous as it can go. But just by visiting the site, I learned Toyota’s CEO is stepping down which is a big deal, I guess?

Link: Remote Workers Face a Lonely Wave of Layoffs – The New York Times

But management experts stress that businesses don’t have to navigate periods of economic turbulence so haphazardly.

Ms. Sucher noted that Nokia, when it was restructuring in 2011, gave the roughly 18,000 people who would be affected about a year of advance notice and offered them several pathways forward: The company would help them find new roles internally, get new jobs externally, start their own businesses or begin an educational program, among other options.

Nokia’s success metrics were whether people had a job lined up when they left the firm, and whether they were leaving with a positive enough impression that they would be open to returning in the future. Nearly two-thirds of people who left knew what their next steps would be.

Remote Workers Face a Lonely Wave of Layoffs – The New York Times

This sounds very European. Although I hope my employer and the peer companies did this, they are too American to behave like this.

According to Wikipedia, Nokia is kind of fine after they sold the mobile division to Microsoft.

Lifer

A month ago I wrote this but somehow didn’t publish it.

I feel I’m becoming a Lifer at Google. If you work for a single company long enough that you can imagine yourself retiring at that company, you are a Lifer.

I’m here at Google more than twelve years. That’s long enough for me to become a Lifer, I guess. It’s kind of a shame. When I moved from Japan to the US, I wanted to experience more diverce careers. That didn’t happen.

I’m old enough to be OK with it but it feels weird. Before I arrived at this place, I was a hopper and had never worked at any single company for more than three years.

A month ago it was disappointing to recognize me as a Lifer. Today it is scary. I can still imagine myself retiring here. What I find not able to do anymore is picture any other non-devastating future. And we just learned that life here can end at any time for no reason.

I want to ask Lifers elsewhere – What’s it been like to be one at, say, IBM? How about Adobe, Microsoft, Apple, or HP? Please tell me it is okay. Tell me you are okay.

This was such an insensitive, selfish and cowardly rumbling. There are people who lost their jobs. I should just collect the pieces and move on. That’s the right thing to do here.

I’ll leave this post alone to mark my wimp.

Agile Roles

Capital One cuts over 1,000 roles in Technology • The Register (Also HN)

The consumer lending company told The Register that its plan was to eliminate its “Agile” job family and integrate staff there into “existing engineering and product manager roles.”

As someone who worked in the Japanese IT industry, I used to be wondering how Agile was adopted in the U.S. and why it had collected so much hate.

I then learned that many companies not only hired Agile consultants but also had full-time “Agile roles” like Scrum Masters. There are even certificates for these professions. Hiring more people to run the process didn’t feel like lower-case “agile”, and that was probably one of the reasons why the upper-case “Agile” was disliked.

This upper-case Agile was not as common in Japan, and I suspect it is still the same. I preach this fact because, to me, Agile was always a grassroots movement. It was hard to imagine what a full-time Agile role was like. I still don’t understand.

Today, before I figure it out, the era of the upper-case Agile seems to be ending.

You would point out that the statement from Capital One is just an excuse. Maybe. Partly at least. On the other hand, I smell a pinch of truth; There are countless ways to cut and excuse, and they choose the above from the endless options.

You may then wonder if the lower-case agile is also ending. I hope not. The statement says:

The Agile role in our Tech organization was critical to our earlier transformation phases but as our organization matured, the natural next step is to integrate agile delivery processes directly into our core engineering practices

As an ex-grassroots-agile-believer, I’m too biased to question this. I’d rather ask you what you see from your trench. Is the lower-case agile dead, or is it “integrated”?

Link: Tell HN: It is impossible to disable Google 2FA using backup codes | Hacker News

The solution (which is too late to help you with now) is to take a photo of the QR code that is first showed to you when you originally set up 2FA. Keep that safe somewhere and you can always go back. For anyone who is freaked out by this and currently still has access to their google Authenticator app, I suggest exporting all your codes to a big QR code in the app and keep that safe (maybe print it out).
https://news.ycombinator.com/item?id=34442690

Printing it out and putting it in some safe is what i did.

And works like a charm.

I mean, if it works for crypto wallets it might also work for 2FA…

https://news.ycombinator.com/item?id=34443283

This is why I use SMS as my second factor for my Google account. Much harder to lose. It could be vulnerable to sim swapping attacks, but I consider Google locking me out of my own account a more likely threat (and frankly I’m probably not a high-profile enough target for anyone to bother with that, and in any case they’d still need my password).

https://news.ycombinator.com/item?id=34442690

See You on Sunday

Last week we had a birthday party for my daughter. We wanted it outside but it was a rainy day. So we ended up inviting a few families to our apartment. All kids had fun, and so did grownups.

It had been almost three years since the last time we invited people home. We forgot how it felt, but the party rekindled the excitement. The next round, hosted by one of the party’s guests, is already set up. It’s going to be a great potluck.

I recalled a book I bought right after the pandemic started. The book, See You on Sunday, is a cookbook about home-gathering meals: Big Meats, Big Pots, Pizza, and Pasta.

The author claims that the Sunday home gathering is an important social fabric. I read it under the COVID-sheltered apartment and dreamed that someday, this virus would go away, and we would have a meal with these big dishes. The virus hasn’t gone away and it never will, but we started gathering anyway. I have yet to have any big dish though.

One recipe I was intrigued by was Momofuku’s bo Ssam. I have no idea, however, where I can find “whole bone-in pork butt or picnic ham (8 to 10 pounds)”. Probably I should start with something easier like spaghetti.

Pumpkin Sugar

pumpkinsugar/source/_posts at master · omo/pumpkinsugar · GitHub

Dependabot のうるさい未使用 repo を archive していたら、10 年以上前に二年くらいひっそり書いていたブログが発掘された。基本的には少女マンガの感想を記録しており、かなりしょうもない。こういうのをみると、結婚して子供ができて強制的に真人間になれてよかったな・・・という気がしてしまう。独身の友人たちは特に心を病むこともなく楽しく暮らしているのでそれが悪いわけではない。自分が思ったより独身生活に向いてなかったという事後的発見。

“あなたのインターンに Blog (これ) の URL を教えておきましたよ” と同僚は明るく告げた.

pumpkinsugar/2012-09-26-closing.markdown at master · omo/pumpkinsugar · GitHub

会社員がインターンに見られて止めたくなるようなブログを書いてはいけない。ばかめ・・・。

Outdated Code Comment Enthusiasm

This article argues against code comment supremacy and discusses the modern writing venues in software development.

The book “A Philosophy of Software Design” discusses code comments through three chapters. The author is enthusiastic about code comments and argues against Robert C. Martin’s “comment as code smell” principle1.

I used to be in Robert’s camp, but after encountering many useful comments in real life, now I appreciate the values of good ones. Still, however, the enthusiasm in “A Philosophy of Software Design” puts me off. Such an extreme comment supremacy feels outdated: The author overlooks recent advances in software development tooling.

Today, software developers have various venues to leave written notes outside the code comments, for example:

  • In-repo notes like a directory README.md
  • Commit logs or PR messages
  • Threads on issue trackers
  • Other documentation tools like Wikis and Google Docs.

These have some advantages over traditional code comments:

  • Better formatting capability: You can highlight words, have headlines, use tables or even put some images, thanks to Markdown or WYSIWIG.
  • Conversational capability: Issue trackers and code review tools have a textbox. It allows you and your teammates to leave some extra comments, keeping the note a bit more nuanced and fresh.
  • Stable URL: You can link the notes from almost anywhere, including the code comment.

On the other hand, the traditional code comment has only one strength: It lives next to the code itself, inline. This is nice and why it’s been preferred.

Web-based Code Browser

However, the code comment’s lead has eroded once Web-based code browsers like GitHub or Sourcegraph have become common. You can just put the URL to the note in the source code so that readers can click through. For a note to be accessible, it no longer has to stay inline.

Code browsers assist code (and note) reading. A few notable features are:

  • It makes URL clickable: Although opening such a link can be cumbersome for text editors or IDEs, it’s instant in Web-based code browsers. Links are the first class citizen on the Web.
  • It makes blame handy: The commit log becomes a click away and the summary line even shows up next to the code itself. The code archeology has become a routine.
  • It runs in the Web Browser: You have tabs. You have handy extensions. You can search the code, others’ code, and StackOverflow, seamlessly.

In-Repo Notes

Among the new types of written notes, the in-repo notes are particularly powerful because:

  • They live next to the source files.
  • It is inherently versioned.
  • It can be part of the code review.

In the other words, it is like the code, without suffering from the limitation of the code comment (lack of formatting, missing stable URL).

And like the code, you can refactor the notes, making the trade-offs: Inline comments are like inline code. They are handy and immersive. However, it can also be noisy and annoying, diluting the code density on the screen. Extract them into a separate in-repo note when that makes sense. It reduces the noise and increases the code density2.

Also like code, don’t repeat yourself. You don’t have to explain a weird workaround. Leave a link to the relevant bug, that has a link to the relevant commit, that tells the story in detail. This is done only with a couple of clicks.

Suggestions

Let me rephrase the claim above as a few suggestions:

  1. Read the code in the Web-based code browser, in addition to the text editor or the IDE. Treat the code browser as a read-optimized IDE. If you don’t have one, invest.
  2. Pick the right venue for your written note assuming the above is the norm.
  3. Consider leaving links in the code to connect the relevant information.

In this world, you’ll find the code comment less useful. That is not because the code is clean enough, but because the comment is no longer a primary place to leave the notes.

Looking from a different direction, Web-based code browsers turn code into hypertext. And the hypertext blurs the boundary between inside and outside the code. Take advantage of it.

This article doesn’t discuss what should be noted in which writing venue, but it deserves a discussion. I might write about that at some point.

To Resonate

This article doesn’t argue against the fundamental point the “Philosophies” book makes, that is, the importance of writing around the code. However, claims like this are convincing only when it is stated in relevant contexts for the readers. It doesn’t resonate otherwise.

To be resonating and relatable, industry veterans like us have to re-tell the lesson in today’s voice, instead of recommending old books. And the “Philosophies” book is a respectable attempt at that retelling. It delivers in some parts, but the comment sections are yet to reach that point in my opinion.

Footnotes

  1. Robert later followed up on this topic.
  2. Some IDE allows comment folding and it does help readability. If the code can tell the IDE to fold a specific part of the comment, it’ll change the trade-off.

Link: EVs are getting too heavy and too powerful, safety chief says | Ars Technica

EVs are getting too heavy and too powerful, safety chief says | Ars Technica

As someone who was recently hit by a car, this is a bit horrifying. Also, as an environmental awareness wannabee, this is a blind spot. I wanted a bigger EV with bigger batteries for less frequent charging, but maybe that’s not a good idea. If so, what I need is a close-enough charging spot. It’s unlikely that I get one in near future. This outlook makes me sad.

写本

日常の雑談とは別に、文書を書くスキルも少しは高めたいなという気持ちから、唐突に適当な英文を書き写す写本作業を二日くらいしてみたが、ぜんぜんなんの手応えもないので中断。同じ失敗を何年か前にもした気がする。数年後にまた過ちを繰り返さないため書き留めておく。

写本作業とは、英文をセンテンス単位・・・だとだいたい長過ぎるのでコンマ単位くらいで、見て、覚えて、書き写す。PC だと単語単位で書き写してしまいそうなので、手書きでやっている。テキストは印刷しておく。ある程度長い文章を覚えようとすることで、文の構造とかを頭にエンコードするスキルを増す期待がある。

写本が良いかもしれないなと思ったのは、基本的にはスピーキングの定番練習である shadowing からの連想だった。が、効果のありそうな感じがなかった。進みが遅すぎてトレーニングとしての圧が弱いのと、あとやはり進みが遅すぎて文章のリズムみたいのが完全に消えてしまう。

もちろん、何らかの効果はあるとは思う。文単位で書き写し、採点（？）すると、冠詞とか細かい時制の間違いとかには気付ける。続ければこうしたミクロな間違いは減らせそうな気がする。ただ、こういうのは最近だと Grammarly なり GDocs のチェックが直してくれる程度のものなので、訓練しがいがない。

単純な文法よりはもう少し粒度のある文章の筋の良さみたいのを体に覚えさせたいとなると書き写しよりはスピードが欲しい。 Audible で shadowing でもすればいいのだろうか。むしろ普通にテキストを音読すればいいのかもしれない。音読は、やりすぎると読速を落とすクセがついてしまいそうで抵抗がなくもないが、試してみて良い気がする。

一歩さがって、自分が改善したい writing はどんなものなのかと考える。と、まず design doc. あとは proposal. そういうお仕事文の類である。オンラインの文章、今回は The Electric Typewriter というサイトから適当に選んだ Malcolm Gladwell の文章だったが、そういうのが書けるようになりたいわけではない。そんな高いバーは目指していない。

そういう「面白い文書」に関する含蓄を高めるより、もうちょっとドメイン依存のやつないかな・・・と思ったら Technical Writing  |  Google Developers というのがあったので、読んでいる。まあまあ良い。このくらいベーシックなやつを読み、何らかの形で実践していくところから始める方が良いな。

このガイドを実践しても面白い文章はまったく書けるようにならないので excitement はないが、別に design doc は面白くなくて良いんです。仕事の proposal とか長めのメールとかも、別に面白くなくて良いんです。そしてこういうの、昔勉強したことあるはずだけど完全に失われているね。ここ数年、ひどい sloppy な文章を書いてきたものだと反省。

練習として、日常の雑談、conversational resume 的なものを technical writing の流儀で書くのはどうか。ドライで楽しくない文章になりそうだが、他に対して題材もないので試して良いかもしれない。まあ日常の雑談に限らず blog に書いているようなことを technical write してみればよい。試してみるべし。

Conversational Resume

Better Small Talk by Patrick King – Audiobook – Audible.com

今年は新しいチームにいることだし少しは同僚とのコミュニケーションとか頑張ろうかなと思い、聞いてみた本。

Conversational Resume という話がでてきて、要するに話のねたを貯めておきなさいという主張。自分について話せる話題をどこかに書いておく。そういうのはあっていい気がする。日常の記憶が、英語でぱっと話せるほど整理されていない。同僚に話せる程度の話題なら大体はブログに書いても問題ないはずで、Conversational Resume をブログに書き留めるのはありかもしれないと思った。ブログの記事としてはまったく面白くないだろうけど、別にこのブログは面白さを志向していないので問題なし。

Chromebook の良さ

Chromebook(Chrome OS) の良さは、Chrome が他のどの環境よりも断然ちゃんと動くことだと思う。速いし、キーボードショートカットとかばっちり。わかりやすい例はログインして Ctrl+N するとブラウザが開く。奇妙なツールとかで設定するまでもなく、標準で。デスクトップ環境の方がブラウザに寄ってきてくれるのは、ChromeOS でないと（当然）ありえない。ブラウザだけ使っている分には他より圧倒的に快適。これに慣れたあとで Windows とか Linux で Chrome を使っているとイラっとする場面がある。

こういうのは Chromebook の良さを語るレビューとかであまり言及されない、当たり前だが使っていないとわからない良さだと思う。ブラウザしか動かないが、そこにはセキュリティだの何だのだけでなく、エンドユーザの手触りとして見返りがある。

だから他より良いと主張するつもりはないけれども、Chromebook のレビューは理論上の良さ vs 現実の制限みたいな論点ばかりが目につくので、そうでない切り口を記録に残しておく。

AI とプログラマの仕事

この手の話はフーンと眺めていたが、Neeva というウェブ検索のスタートアップが思ったよりはやく LLM を直接製品に埋め込んできて感心した (スクリーンショット)。Google のサーチ部門も Code Red らしいし(※勤務先ですが他所の部門の話なのでインサイダー知識はございません) Bing もなんかやってるらしいし、こういう LLM-based な自然言語製品は思ったよりすぐ商業化されるのかもしれない。

”プログラマの仕事は AI に奪われるのか” という話題で見られる先のリンクのような議論は Remote And Vegan と同じ問題を抱えている。つまり、プログラマの既存のタスクや責務が自動化できるかどうかというミクロな問題にフォーカスしすぎ、マクロで構造的な変化を議論してない。自分はどちらかというと後者が心配。

でかいモデルの学習には巨大なメモリと速いアクセラレータを長時間専有する必要があり、めちゃ金がかかる。推論もわりかし高価であることが知られている。従って、AI を使いたい企業は直接的、間接的にハードウェア投資をしないといけない。そのための資金をどこかから調達しないといけない。

自社でデータセンターを持つでかいテック企業の支出は、大半が人件費とハードウェア費用であることが決算報告などから知られている。そして近年のハードウェア費用の増大は AI/ML 用途の計算資源需要の増大が大きな理由だとみなされている。つまり、人件費（我々の給料）とハードウェアコストは、限られた予算を奪い合っている。

だから今後 LLM を使った製品が次々に登場して成功を収め、その開発運用に必要なハードウェア費用の高騰が進み、そのぶん人件費が圧迫されるということは、ありえるんじゃないの？

一歩下がると: 相対として AI 用途のハードウェア(およびそれを直接間接に提供するサービス)に投資する方がプログラマの給料に投資するより見返りが良いなら、企業は、これまで沢山あった玉石混合のソフトウェア開発プロジェクトを切り捨て、(運用が高くつくため相対的には数の少ない) AI-based な製品開発に比重を置く・・・かもしれない。そうなったら末端で比較的どうでもいい機能とかを開発しているスマホアプリプログラマなんて失業ですよ。困るわ。

テクノロジーのイノベーションでモデルの計算効率が良くなる可能性はあるが、それがモデルサイズの増大をオフセットできるのかは、まったく自明でない。LLM 製品の力で売上が加速してコストをオフセットできるのかも、やはり自明でない。めちゃ競争がある分野なわけだし。

というわけで、プログラマは AI に目先のタスクを自動化される心配をするヒマがあったらリサーチャーが LLM のコスト問題を解決するイノベーションをしてくれるよう祈るほうが良い、が、どちらも特別 actionable ではないのでほっといて真面目に働き解雇リスクをさげるのが現実的。正常化バイアスという批判は甘受いたします。

Atmospheric River

雨続きのカルフォルニア、新聞記事がこの気象を Atomospheric River と称していた。細長い雨雲のことらしい。このビデオを見ると要するに台風の尻尾のところだとわかる。Wikipedia によると US では CA で特によく見られる現象らしく、CA の雨の半分はこれとされている。

NYT の降水量マップを見るとベイエリアは Santa Cruz Mountain によって豪雨を免れているように見えるが、これはいつも期待できるのだろうか。

どうでもいい細かいことを Blog に書いて見る試み。

2022

短い旅行より帰宅。運転のためにキメたカフェインの都合で眠れない夜に一年を振り返る。今年は、色々なことを試したがうまくいかず、そのほかにもトラブルの多い年だった。

まず今年のはじめごろ、仕事を真面目にやって出世できないかと考えた。子を私立の学校に入れる可能性が生じ、金を稼ぎたくなったため。そこで数カ月のあいだ真面目に・・・というのは、今までと違う優先順位と労働時間で・・・働いてみたが、挫けた。仕事に頭と時間を使いすぎて業務のイヤな部分をデタッチできなくなり、精神衛生を著しく損ねてしまった。とても続けられない。

挫ける速さには我ながら感心した。自分は出世に向かないボンクラだと悟り、余暇活動でもしながら楽しく暮らそうと改心。Podcast およびブログ(これ)を再開した。労働は以前の勢いに戻した。

いちおう勤務先の名誉のために書いておくと、子供一人を私立に入れるくらいの給料は貰っている。ただバッファが欲しかった。なおこの挫折とは無関係に私立の話は立ち消えとなった。

春を過ぎたころ、いつもように HN で他愛もないコメントを書いていたら、それを読んだどこかの会社のエンジニアからメール。「おまえわかってんじゃん！ちょっと話しない？」というので、何かと思ったら hiring のお誘いだった。聞いた仕事は面白そうだしこれも縁かと面接を受けることにした。ただ冷静に考えるとコーディングクイズを突破できる気がしないので、一カ月くらい待ってもらい LeetCode で準備のうえ臨んだ。

練習の甲斐あってインタビューは通過し、いちおう VP (部長) の話も聞いとく？というので聞き、あとは肝心な給料の話かと思っていたら返事がない。つつくと会社の都合で採用全体が止まっているという。そのあとも音沙汰なく、しばらくのちに同社のレイオフを知らせる報道があった。あれまあ。さほど積極的に転職したかったわけでもなく給料がバーンとあがるなら考えようという程度の甘い見通しだったので、忘れることにした。想定給料が見られなかったのは残念だけど仕方ない。

LeetCode で転職修行するのがどういう感じかわかったのはよかった。つまり: 嫌いではないがそんなに好きでもないし、他に何もできなくて大変。日頃からコーディング筋をつけておこうかと Codeforces を試したが、早々に脱落した。あたしプログラミング向いてないんですよ・・・。

夏。二年ぶりくらいで日本に帰省したら、旅先で COVID に感染してまった。発熱など一通りの症状があり辛かったのみならず、家族の旅行を台無しにしてしまい心苦しかった。隔離施設に入ったのは、経験としては興味深かったが、十年分くらいのコンビニ飯的弁当を延々と食べさせられ食傷。とはいえ日本の COVID はその後 surge して隔離施設も満室になったと伝え聞くから、入れただけマシと言える。

帰国後 2 週間くらいは体調が悪くしんどかったものの、最終的には回復。後遺症がなくてよかった。

日本からの帰国後、妻子および自分に虫刺されらしき腫れと痒みが発生。US 帰国後に一度外泊があったため bed bug を疑って色々と対処する。この一年で一番エネルギーを費やしたものが何かといったら、これだね。害虫対策。数カ月もの間、この見えない敵を相手に大量の資金、時間、精神力を溶かした。EPA, CDPH などオンラインの authoritative なサイトを読み漁り、専門書も読み、現実的な範囲で手を尽くした。家族は皮膚科にもかかった。件の害虫の発生で説明されるような頻度での痒みは一カ月くらいで落ち着いた。家族には最近も断続的に腫れや痒みが観測されているが、そもそも自分たちはアウトドアで過ごす時間も長く家の周りもまあまあ草なため蚊など他の虫刺されと区別がつない。虫とは無関係な蕁麻疹やできものなどの肌トラブルもある。だから最低限の防御だけを残し、問題は解決したことにしている。

なお、これだけ手を尽くしたにもかかわらず bed bug の実物にお目にかかることは一度もなかった。なので、本当に bed bug がいたのかどうかは藪の中である。Bed bug は、発生しているなら高い確率で実物を目撃するとされており、多くの駆除業者は現物を確認するまで薬物散布などの対策は打ってくれない。自分の中では「当初はいたが努力によって撃退した」ということにしている。

対策と調査の副作用で bed bug に異常に詳しくなった。詳しくなってわかったこととして、オンラインの体験談はだいたいゴミである。業者もわかってないケースが多い。ぼったくり業者、役に立たない製品も沢山ある。EPA のようなまともなサイトを読もう。あと近所の方で困った際にはご相談ください。

九月。車にはねられた。いやー死ぬかと思ったねマジで。一カ月以上、体のあちこちに痛みがあった。 勤務先では春に出社が始まっていたがしばらく通勤する気が起きず、痛みが治った後を含め二か月くらい自宅勤務をしていた。先月ようやく重い腰を上げて自転車を買いなおし、通勤を再開した。

体が痛いと何もする気が起きず、仕事をなんとかこなしつつ漫然と過ごしていた。Codeforces が途絶えたのもこれ（と害虫対策の疲労心労）が一因。しかし記録をみると Podcast は続けており、我ながらインターネット芸人魂がある。

インターネットといえば、雑談相手を求め Twitter を真面目にやろうとして、挫けた。今思えば新社長就任とは無関係に単なる気の迷い、気の散り、時間の無駄だったと思う。まあ時間をムダにするのはソーシャルメディアの本質なので別にいいんだけど、自分の求めていたヒマ潰しではなかった。それを改めて確認できたのは、よかったといえばよかった。

一方で COVID 時代の友人関係のありかたは、妻子あり中年の友人関係の在り方とあわせ考えているテーマなので、何らかの形で探索・気の迷いは続けていきたい。

こうした様々なトラブルおよび雑念の影響で集中力がなく、もともとパンデミック突入以降に破綻していた労働への姿勢を立て直せていなかったせいもあって、仕事は不調だった。チームでの tenure が長いおかげで経験で目先の作業をこなすことはできたが大きな成果を出すことはできず、むしろ段々と目先の雑事の比率が増えてしまって行き詰まり、やる気も下がってしまった。これはチームやプロジェクトのせいというよりは自分の数年にわたる気の散りの帰結なのだが、そうはいってもやる気が起きない事実はどうにもできなかった。

そこで気分を入れ替えるため、社内求人をあたって他のチームに異動することにした。来年の頭から他の部門で働く手筈。仕事は相変わらずアプリ業だけれど、環境を変え気分一新で働きたい。

そういえば前回の異動も子供ができて育休をとったあと、うまく仕事に復帰できなかったのがきっかけだった。我ながら人生の荒波を乗り越えるのがヘタ。つぎの危機ではもうちょっと踏みとどまれるよう、普段から姿勢の乱れに気を配っていきたい。

総体として、外的要因および自業自得で気の散った一年だった。集中力、生産性ゼロ。特に仕事はひどいものだった。そんななか Podcast を再開できたのと、久しぶりにブログをはじめられたのはよかった。これらは、仕事の視点では気の散り要素でしかないけれど、自分の人生にとっては大事な趣味だと思い至った。趣味重要。

いま振り返るに、これらの気の散りは 1) パンデミックの何もできない内向的生活の反動と 2) 一部中年にありがちな自分探し系気の迷い (aka. midlife crisis) が重なった結果だったように思う。だとしたら、あとに禍根を残すような大きなやらかしに至らず、生産性が低いくらいで済んでよかったと思うべきかもしれない。Great Resignation と突然のテック不景気が重なって惨事に至った可能性・実例はあるわけだからね。

家庭はというと、ここに書くことは特にないけど、まあぼちぼちやってます。夫婦関係は重視したほうが良いというアイデアはそれなりに続行中。子供も元気です。

来年はこんな粗悪 reality show ドラマのない、平和な一年でありますように。

Remote And Vegan

Bill Gates が「俺はもうチーズバーガーはやめたわ」と書いていた影響もあり、食事から動物性の材料を減らせないかと時折考え、断続的に試している。

各種の plant based 代替食材も試した。Milk, Cheese, Chicken Nuggets, Ground Beef. こういうのは悪くはないが、制限されている感は否めない。

これはベイエリアで日本食材スーパーに言って感じる残念さに似ているかもしれない。悪くはないが、本質的に制限されている。それよりは Safeway なり TJ なり、そのへんのスーパーで買える材料で、アメリカっぽい料理を作ったほうが良い。材料は安く、豊富である。バター多すぎだが。日本ぽい食事はアクセント程度にしておく・・・というほど制限してはないけど、アメリカっぽい飯の割合はだいぶ増えた。

同様に、動物性食材を減らそうと思ったら代替食品でがんばるよりも Vegan レシピを覚えたほうがいいなと考え直し、Vegan Recipe の YTer をランダムに何人かフォローしてみた。もうちょっと増やしたい。Vegan Recipe 勢、基本的に alternative ingredients は使わない。野菜と豆で生きている。植物性の材料から旨味やコクを最大化するノウハウを追求している。

日本飯からアメリカ飯へのシフトにせよ動物性から植物性へのシフトにせよ、それまでと同じ料理を代替材料で作ろうとするよりは作る料理そのものを置き換えたほうがストレスが少ないし、探求の楽しみも増える。

これはパンデミック突入にともなうリモートワークへのシフトの時に感じた印象と似ている。つまり in-person のアクティビティを、そのままオンラインに持っていくのはしんどい。

いちばんわかりやすいのはミーティングで、今は zoom fatigue と呼ばれるに至った。ただ個人的には in-person のミーティングそんなに好きでなかったし、パンデミック前から違うオフィスのひととは VC だったので、いきなり制限された気はしていない。まあ 1-1 とかは in-person の方がいいといえばいいかもしれない。

より滑稽・・・というと悪意があるみたいだけれど、うまくいかないと感じたのは “virtual” team building event みたいなやつで、これはほんとうにしんどい。物理的に近接することで深まる bonding が欠落している。McPlant 的な空虚さがある。

ずっと感じるのは all hands や tgif のような発表主体のイベントのリモートとの相性の悪さ。おそらく主催者・登壇側は拍手喝采されるアゲ感が名残惜しくて無意識にこのフォーマットを支持、維持しているんだろうけど、視聴者からすると発表やアナウンスを伝えるメディアとしてこのフォーマットは疑問。

自分の勤務先はでかいので、この手のイベントに実際に足を運ぶことは随分前からなくなっていた。基本的には録画を見る。そもそもオフィスが離れていたら足を運びようがないわけだし。これらがライブ開催される意義は、歴史的にはリアルタイムで参加者から質問に答えられるからだった。けれど地域格差を解消するために、今は事前にオンラインで質問を募っている。視聴にとってライブ開催の意味は、もはやない。

発表者が自宅からライブ・録画していたパンデミックピーク時は更に厳しくて、たとえばさ、社長とか VP とかがすごい立派な部屋を背景に話をした直後に下々が狭いベッドルームやごちゃっとしたリビングとかを背景に登場したりするわけ。はー我々ザコキャラはカネ持ってる資本階級にコキ使われてんだなーと冷めた気分になってしまう。現実には社長や VP が狭ーい部屋から登場したらその方が夢がなくてイヤなのだが、そういう格差は普段から目にしたいものではない。会社の建物はチームの一体感というファンタジーを維持する装置として機能しているのである。幻想重要。

なんの話だっけ。そうそう、発表の類。これは、きちんと編集したコンテンツとして出すのがいいと思うんだよね。司会もプロを雇う・・・までいかなくても得意な人にやらせてさ。ついでにいうと、情報量を考えると動画じゃなくて音声でいいね。Podcast にしてほしい。その方が編集の手間と効果の費用対効果も高いでしょう。新機能の発表とかもさ、一人で話させるんじゃなくてインタビューにしてあげるわけ。それがリモート時代の broadcast というものじゃないか。

自分のいるチームでは、あるとき有志が思い立って「同僚をインタビューする Podcast」を初めて、これがすごくよかった。同僚といってもランダムに選ぶのではなく主要な、つまりエラ目、存在感高めの人が中心。内容は仕事寄りでなくその人の生い立ちとかそういうパーソナルな話が中心。物理的な近接が担保していたある種の intimacy を、録音されたメディアを通じ人となりを知るという intellectual exposure で置き換える。リモートファーストの team building かくあるべきな見本として額に入れて飾りたいくらい。

いちおう勤務先全体を擁護しておくと、たとえば会社の動向を伝える newsletter みたいなやつは存在していて、毎日届く。これは良い。会社全体に限らず、組織がでかくなると、この手の newsletter は様々なレイヤで発生する。基本的にはレイヤが下になるほど仕事の具体的な内容に近くなる。そういう written communication があるのは良い。もっと普遍的になればいいのにと思う。

個人的には、特に組織の雰囲気とか文化みたいのを形成するのには、リモートであってもテキストに固執する必要はないと思っていて、だからこそ internal podcast は良いと思ったのだった。動画はどうかというと、本来は色々やる余地はあるはずだが Remote Techtalk とか、やっぱりいまいちだよね。もうちょっと YouTube / TikTok / Instagram とかなんでもいいけど動画メディアというものを研究して工夫して欲しい。動画は音声より production cost が高いのは事実なので、そこは会社が支援して上げるのが良いと思う。スタジオ作るとか、機材手当を出すとか。

Automattic や 37signals はテキスト世代の remote first 企業だった。パンデミック以降の若い remote first 企業がどうやって社内でコミュニケートしているのかは興味があるね。

Tumblr

Mastodon が隆盛している昨今。別に嫌いではないし恨みもないが、めんどくさい。気分が盛り上がらない。UX がしょぼすぎる。

Tumblr が ActivityPub をサポートするというので、これが公式にアナウンスされたら Tumblr as Mastodon frontend として使うのはいいかもしれないなあと思いつつ、発表を待っている。Tumblr は Marco Arment が CTO をしていた過去に加え WordPress の Automattic に買収されており、なんとなく親しみを感じてしまうのだった。おっさんの巣窟になっているかと思いきや、上のインタビューによれば未だに若者を引き寄せているらしい。中二病の巣窟か。サブカルだよな。

Automattic, 個人的には金銭のしがらみがなければ働きたい会社ナンバーワンである。そのラブリーな製品リストを見よ。まあ勤務先の製品群もそこそこラブリーでたくさん使ってるんですけどね・・・飽きたよね・・・あと For Everyone とか言っててサブカル感がないよね by design・・・。

さすがにこのご時世 open position はないっぽいなと求人ページを眺めていたが、上の podcast を聞いていたら Twitter layoff 勢向けに専用のページが用意されていると聞き笑ってしまった。ソーシャルメディアの会社は、景気悪いなりに ex-T の人々を雇っていそうである。Twitter layoff のいいところ(?)は、クビの切り方が明らかに雑なのでクビ = low-performer という負の印象がまったくない点。会社の人事評価なんてどのみち当てにならないので採用側は不当な bias なしに人を見てほしいもんだけれど、そういう「正しい態度」は期待できない不景気なのだった。

レイオフといえば、最近大規模解雇をした会社から「採用してるよーどう？」みたいなメールが来て、おまえらどうなんだそれは・・・。という気分になった。配置転換みたいな概念はないのかね。おまえらがクビにした low performer はほんとに low performing だったのかい・・・マネージャがダメだった可能性はないのかい・・・？

Stratechery Plus

少し前から Ben Thompson の Stratechery Plus を sub している。テック業界分析有料 newsletter+podcast. 自分はもともと Dithering に金を払ったり払わなかったりしていたが、Ben Thompson の他の podcast とセットで割引されるというので sub してみた。$12/m は個人メディアとしては安くもない一方、Stratechery はこのジャンルだと老舗かつ最大手なので、こんなもんかなと思う。

さいきん他所の podcast でインタビューされており、10 周年だと知った。自分はいつから聞いている（というかブログを読んでいる）のか覚えていないが、最初の頃はビジネス臭というか PM 臭がキツすぎてそんなに好きでなかった。今もテクニカルな細部への洞察は怪しいなと思っている。ただ Ben が友達の James Allworth とやっていた Exponent という podcast を聞いていたらにじみ出る personality に親しみが湧き、だんだんと読むようになった。(なおこの podcast は二年くらい前に終わってしまった。Big Tech が世を席巻している時期のその様子に fascinate する暑苦しい対話で、自分の podcast 視聴歴のなかでも favorite のひとつ。James 帰ってきてくれ!)

Ben Thompson の主要コンテンツである Stratechery は blog。Paywall はない。有料会員はこれに加えて daily update というテック業界短信が週に二回くらい読めるほか、週に一回テック CEO のインタビューが配信されてくる。このインタビューは大手からスタートアップまでほんとに隈なくたくさんの CEO がインタビューされていてびっくりする。大きいところだと Meta, Microsoft, NVIDIA, Intel の CEO が出てきたり、最近だと Midjourney の CEO もインタビューされていた。たぶんこれがキラーコンテンツ。

あと Sharp Tech というゆるっとした業界解説 podcast と John Gruber とやってる 15 分でおわる業界短信 podcast Dithering. このへんは相対的にはどうでもいいが、ちょっとしたヒマつぶしにはちょうどいい。ただしどちらもだいたい同じ時事ネタを話してるだけなので、両方聞くと飽きる。最近は Ben が出てこない Sharp China という podcast が追加された。これはアメリカテック業界人が気にしてる中国事情の話をしており、バリエーションになってよい。ただ個人的にそこまで興味のある話題ではないので、継続的には聞いてない。

それにしてもこんな個人アナリストがテック大企業の CEO にばんばん一時間くらいのインタビューをしていて、Ben Thompson は随分と大物なのだなとびっくりした。先の 10 周年インタビューを聞くとピンで食っていきたいアナリストワナビーの星らしい。昔はそんな大物じゃなかったはずだけど、10 年続けるなかで着々と影響力を伸ばしてきたのだね。

というかんじで二ヶ月くらい購読しており中身に不満もない。ただ Stratechery Plus だけで自分の音声コンテンツの帯域が使い果たされてしまい Audiobook の進捗がすっかりなくなってしまったのは問題。一旦 unsub して音声読書を進めたい気もするが、どうしたもんかな。