公式ドキュメントを必ず見るべきだという点に、とても共感します。

コーディングを最初に教えるとき、この人がエラーメッセージを丁寧に読めるかどうかで、プログラマーとしての素質が最初に表れるように思います。

すべてではありませんが、ほとんどは共感できる項目ですね。

手工業に近いというのはまったく考えたことがありませんでしたが、とても共感しますね。
この観点で考えると、多くの現象が説明される気がします。

Hyperlight - 軽量仮想マシンマネージャー(VMM) | GeekNews

Hyperlight WASM: 高速で、安全なOS不要 | GeekNews

批判的なコメントを見て、いろいろ考えさせられました。共感できる部分もあれば、異なる考えを持つ部分もあります。

• 現在の開発者の地位にはある程度バブルがあるかもしれませんが、それは他の職種も同じだと思います。少数から多数へ。つまり、従事者が増え多様性が広がる中で起きる自然な現象であり、この方向が正しいという意味ではありませんが、開発者だけが特にそうだとは思いません。
• 学びやすい。これは認めます。しかし参入障壁が低いことが、専門性が低いことを意味するわけではありません。他の産業、特に製造業の他の技術職と比べて学びやすい理由は、開発そのものが簡単だからというより、オープンソース文化やリスクの低さにあるのではないかと思います。先に述べた開発者の多様性という側面から見ても、短期間で学んでできる仕事もあれば、専門性を基盤にしなければならない仕事もあるのです。
• 環境は変化しました。市場で開発者に対する期待と報酬が過去より大きくなっている理由は、単に彼らの技術、熟練度、専門性だけではないと思います。人類の生活にITが深く入り込むほどソフトウェアは重要になり、多くのインフラを支えています。各開発者の能力が高まったから報酬が増えているのではなく、仕事そのものの単価が上がったのだと思います。以前より重要になったからです。
• 製造業と直接比較することに意味はあるでしょうか。産業の高度化が十分ではないという観点から、その比較対象は製造業に見えるのですが、製造業のパラダイムでソフトウェア業界を理解しようとすると、手工業や趣味の開発のように見えるかもしれません。しかし逆に、こうした部分こそがソフトウェア開発ならではの柔軟で創造的な文化を生み、それを足がかりに成長しているのだと思います。
• 過度な没頭は危険だ。これは非常に共感します。世の中に勉強すべきことは開発だけではありませんし、今でも私たちは職業欄に「会社員」と書くわけです。社会の空気にバブルがあるからといって、他の職業と大きく違うと考えることには慎重であるべきでしょう。ただ、これはどんな職業にも当てはまることです。

トスにとってUXはまさに生存に直結しているんですよね
ただ、この文章とは別の意味で、その会社が収益をうまく追えているのかは分かりません

お誕生日おめでとう。おじさんの言うことをよく聞いて、いつまでも元気でいてね。

この種のフィードバックは、性格や文化圏、個人差によっては、受けたときに気分を害したり腹が立ったりすることもあると思います。ですが基本的には、「あの人がわざと自分を苦しめようとしているわけではない」と考えて向き合うほうが、メンタルの面でも成長の観点でも良い気がします。そういう状況になったとき、この文章を思い出しながら「もしかするとこのマネージャーも？」と考えてみることはできそうです。いい文章ですね。

スペルミスを直してくれたなら、ありがとうございます、知りませんでしたと言えば済む問題であって、怒る材料ではないように思います。自分が感じたとおりに他人も感じるだろうと考えるのは、危険な一般化だと思います。そして、받아 드리는 게ではなく받아들이는 게です。

AI導入を見るときは、開発速度の側面ではなく思考の拡張という側面から見るべきなのに、いまだに速度ばかり持ち出す管理職がいるようですね。AIを推すプロダクトを見ると、特別に際立った製品というわけでもなく、たまに市場検証をしている程度ですが、自分が作るプロダクトの水準をそこに合わせるつもりなのでしょうか？

CTOの手足のような存在だと思いますね

お誕生日おめでとうございます ^^

おお…これはかなり意味がありますね？ 税務関連の業務もずっと円滑になるでしょうし、統計の正確さも上がりそうです。

XE1の初期のころからRhymixに至るまで十数年使ってきたユーザーの立場として、とても共感できる内容ですね。

Rhymixがターゲットにしている市場の大半が、直接開発するための十分な能力を持っていない点が、いちばん大きな問題だと思います。

自分で開発できる人たちは、XEやRhymixの不足したドキュメント、曖昧な構造、レガシーな部分を甘受するよりも、Laravelなどを採用することが多いでしょうし。

元記事の筆者の方と同じく、私もまた

1. 多くの人が馴染みやすいと感じる管理者ページ
2. 多少物足りなさはあっても、不足はないCMSとしての機能
3. 新しい提案を積極的に反映するコア開発チーム
4. 長年使ってきた愛着
   などの理由から、いくつかの新規プロジェクトでRhymixを採用していますが、そのたびにこの選択が本当に正しいのか、かなり悩んでしまいます。

Rhymixをフレームワーク代わりに使いながら、物足りなかった部分を補おうと個人的にいろいろ試しているのですが。
https://github.com/nemorize/rx-make (developブランチ / PoCプロジェクトのため本番投入予定なし)

Rhymixを丸ごとフレームワーク/ライブラリ化してしまうとか、レガシーAPIへのアクセスを最小限にして、もう少しモダンなAPIを（レガシーとおおむね互換性を持たせつつ）再構築するといった、いろいろな試みをしていますが……本当にものすごく悩みますね（笑）

この悩みを明確に整理したことはなかったのですが、これを機に一度はっきり整理してみようと思います。

Tossにとって、UXの差別化はそのまま売上と生存を意味するからです。
都市銀行や一般的なフィンテックアプリと同程度で満足しているようでは、成功とは言えないでしょう。

以下を除けば:
「意味のある仕事をしながら安定も求める方法
自分がやりたい仕事が収益性と直接関係ないなら、非常に収益性の高い大企業で働くことが重要
小さくて収益の低い会社では、価値ベースの仕事はリストラの対象になりやすい」

こちらのほうが私にはより説得力があるように見えます。

「会社が一定規模に達すると、金を稼ぐことは社会的構築物になる。how to get promoted という文章のほうが大きな組織の現実をよりよく説明している」

それは、トスのコンバージョン率が成果につながるからではないでしょうか？ しかも上場したわけでもないので、今は成長に
貢献しさえすれば、売上に直結しなくてもよいですし。

だから本文の途中で、会社がどうやってお金を稼いでいるのかを見るようにと言っていたのでしょう。

AIに脳を委ねてはいけないのに、AIがあたかもあらゆる思考を代わりにしてくれるかのように信じる風潮があるように思います。