Redditで話題になっていたポストを訳してみた。 僕は自分が思っていたほどは頭がよくなかったという高校生の独白にたいしてつけられたこのちょっと長めの返信がとても的確で示唆に富んでおり、多くの人のこころをつかんでいました。私自身、勇気づけられるというか身につまされるところがあり、忘れないために翻訳をしてみました。 まずは高校生の独白から。 僕は自分が思っていたほどは頭がよくなかった 僕はいま高校の最終学年で、次の６月に卒業する予定です。高校の成績は、いままでずっとAを取りつづけていましたが、去年始めてBをとってしまいました。もしそのBがなければ、卒業生総代に選ばれていたでしょう。 総代にふさわしいのは自分だ、つまりクラスで本当に一番頭がいいのは自分だと思いたいです。でもこの一年で、僕にそれほどの知性はないし、僕より頭のいい人はたくさんいるんだということを思い知らされました。 また僕は、自分

本質的な複雑さ批判 森田が大ファンであるところの Dan Luu が「人月の神話」の Fred Brooks をディスる 記事を書いており、 痛快なのでみんなでこれ読んで与太話しようぜ、という回。(Dan Luu のページは Pocket か Instapaper 必須なのでみなインストールされたし。) ここで批判されているのは Brook の Essential Complexity / Accidental complexity に関する記述。 極めて雑に復習すると、Brooks は「問題には “essential complexity” すなわち “本質的な複雑さ” というのがあるから、 プログラミング言語とかツールとか計算機性能の改善とかで “accidental complexity” / “偶発的な複雑さ” を減らしていっても限度があるよね、 ソフトウェア開発って難しいですね・

会社などの組織体というのは、二つの側面があると思う。一つはその中にいる生身の人間そのものであり、もう一つはその人間が複数いることによって起きる人間同士の相互作用だ。 スタートアップの企業のように人数が少ない時期は、単に個々の人の集まりとしての活動だったものが、だんだん大企業になってくるにしたがってその相互作用が大きくなってくる。だから、会社も少し大きくなってくると、良い文化の定着を図ろうとしたり、組織構造をつくりはじめたりする。 この二つのうち「相互作用」の方は、生身の人間自体に比べると、なかなか理解したり制御するのが難しい。 さて話を変えると、なにか問題が起きた時に、人は、よくわからない何かに原因をおしつけて思考停止してしまうということがままある気がする。たとえば、今の給料が低いのは政府の政策に原因がある、のようなものだ。もちろんそこのロジックを精度高く理解して言っているなら別だが、大抵

僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職

まあお悩みですけどね、技術的に難しいことってありますよね。で、他のメンバーに任せておくと、いつ終わるかわからない。聞いてもわからんわからんばかりで、こりゃダメだと言う時のことです。 いつものように、それ私が引き取るよ、ってその課題を引き取って、難易度の低いタスクを他のメンバーに任せます。まあそのタスクも大量なので、誰かがやらなきゃいけないし、高度な問題のために大量のタスクが積みあがるのもそれはそれでまずい。適材適所と言えばそうなのですが、本当にこれでいいのかなと毎回思います。 だって、またこの高度な問題に対するトラブルシューティングを見ることなく、メンバーは最終的に「できた」という形を手順書なりなんなりで確認することになります。ああこうやればできたのか、という感動があればまだいいですが、忙しいのでそんなことしている暇は多分ありません。 これ、私はまたスキルを一つ積み上げたのですが、どう考え

チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知

十行程度のプログラムが読めること プログラミング言語の文法を知っている 分岐とループを追いかけることができる 変数の状態変化を追いかけることができる 関数呼び出しを追いかけることができる 十行程度のプログラムを複数回書いたことがある プログラムを読んでプログラムの動的な振る舞いを想像できる プログラムの主な処理の結果を想像できる 主な処理の終了条件がわかる プログラムから主な処理を読み取れる 似たようなプログラムを書いて、動かしたことがある 既知のプログラムと読んでいるプログラムの違いがわかる イディオムを知っている イディオムを書いたことがある プログラムがどう動くか知っている 重複したソースコードを関数に抽出できる 重複したソースコードがわかる 同じ入力と出力をもつコードブロックがわかる コードブロック単位で入出力を比較できる プログラムのある機能がソースコードのどの部分に依存している

youkoseki.com インターネットおじさんの2019年 叔父と初めて会ったのは90年代の後半で、私がまだ高校生のころだった。叔父は長くアメリカに留学していたが、日本の通信会社に就職が決まったので、帰国してきたのだ。叔父は日本のことがよくわからないからと言って、私達の家のすぐ近くにマンションを借り、しょっちゅう私達の家に出入りするようになった。 叔父と私は、親子にしては近すぎるような、兄弟にしては離れすぎているような、微妙な年齢差で、はじめこそ、お互いにどう接すればいいのかわからなかった。しかし夜になると決まって叔父が家にやって来ては帰らないので、気付けば次第に話をするようになった。たとえば、私がテレビゲームにはまって遊んでいると、叔父はもっと面白いゲームがあると、聞いたことのないアメリカ産のゲームを持ち込んでくるといった具合に。 大学でコンピュータについて学んだという叔父は、私に言

このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ

心を構える「気づき」からスタートする科学と技術が発展し全てのスピードが早い現代において、普通に生きていると「不足しているものはない」と感じられる。故に、針の穴を通すような「自分だけが知っている気づき」の中にだけ、その後大きくなりうるものを孕むと考えている。一握りの人間は現状に何かしらの気づきを得ようとしているが、多くの人はそうではない。気づきを得るためには、気づくための訓練が必要だ。現状に「なぜ」を問いかけ、欠けているものを見つける訓練である。僕がこれまでに得た最大の気付きは、どんなに優秀な経営者、起業家、プロダクトマネージャー、クリエイターであっても、「気づきを得る訓練」をしている人は極めて稀だという事実だ。気づきを得るためには、そこにある事象、因果、携わる人の気持ち、外部の構造など全てを深く理解しようと務めなければいけない。1点ではなく、多面をだ。全てを理解するために最も手っ取り早いの

とても勉強になったので写経のつもりで翻訳しました。 普段自分でもわかっている気がするけど言語化するのが難しかったこと、自分でやっていて確かにあとから痛い目を見たかもしれないと反省を促される内容でした。 ※ゲームプログラミング特有だなと感じた内容はきちんと理解できなかったので割愛しています。 Now that people have already said highly controversial stuff like ”debugger is useless for C++ development”, I think I can share my own controversial thoughts about unit testing, DRY, copy-paste coding and function length, etc... with 20 years of C++ pro

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。