つだ

先ほどの方の記事で、こちらも良かった。共感する。 以下は、本文と順番違うがメモ： ・最高のエンジニアとは、バグを修正する人ではなく、誤解がバグになる前にそれを解消する人 ・経験を積むと、あらゆる議論に勝とうとすることをやめ、本当に重要なこと以外は受け流せるようになる ・成熟とは、完璧さを追求するのをやめ、物事が摩擦なく流れる状態（フロー）を重視することである ・最終的には、流行の技術より、自分が寝ている間も静かに動き続ける退屈で安定した技術（PostgreSQLなど）を信頼するようになる ・抽象化レイヤーを増やすことは、一見、（技術的な）進歩に見えるが、実際には摩擦を増やすことが多い ・経験とは、技術スタックが変わることではなく、何が重要かという「視点」が変わること ・キャリア初期は、巧妙で難解なコードこそがスキルの証明だと考えがちかもしれない ・巧妙なコードは、書いた瞬間は満足感があっても、後でメンテナンスする人を苦しめる ・真の熟達とは、複雑さを管理し、シンプルで明確なコードを書けることである ・アジャイルやTDDのような良いアイデアも、厳格な「プロセス」になると形骸化し、腐る ・プロセスの儀式を守ることと、チームが成果を出すことはイコールではない ・プロセスはコミュニケーションを助けるためのものであり、思考を停止させるためのものではない ・目的より手段（フレームワークなど）を擁護し始めたら、本質を見失っている証拠 ・エンジニアは、まだ来ない「将来のスケール」を想像し、過剰なシステムを設計しがち ・過剰設計は、技術力を証明したい野心や、準備不足に見られたくない恐れから生まれる ・業界は、物事を小さく保つことより、複雑なシステムを作ったことを評価しがち ・キャリア初期に嫌っていた型チェックや規約は、実はカオスを防ぐ「集団的防衛メカニズム」である ・これら「退屈なもの」が安定を生み出し、その安定こそが、本当に重要な場所でリスクを取る自由をもたらす ・命名規則や標準は、チームの「集合的記憶」として機能し、一貫性を保つ ・ソフトウェア開発は技術的な作業に見えるが、その本質は「人間関係」と「調整」である ・たとえば、システム障害の根本原因は、技術的欠陥よりも「誰かが誰かと話さなかった」というコミュニケーション不全にある（ことが多い） ・ドキュメントやミーティングは、単なる儀式ではなく、相互理解を支える「社会的な足場」作りである Most of What We Call Progress という記事から。