professional programming

目次

• プロのプログラミング - このリストについて
  • 原則
  • このリストに貢献します
  • 必見の本
  • 必見の記事
  • その他の一般的な資料とリソースのリスト
    • 他のリスト
    • 本
    • 記事
    • 公理
    • コース
  • トピック
    • アルゴリズムとデータ構造
    • APIの設計と開発
    • 態度、習慣、考え方
      • 先延ばし
    • 認証/承認
    • オートメーション
    • ベストプラクティス
    • ソフトウェアエンジニアリングとランダムを超えて
    • バイアス
    • 仕事
    • キャッシュ
    • キャリアの成長
      • 次の/最初の機会を選択します
      • スタッフに行く
    • 文字セット
    • チェス
    • 雲
    • コードレビュー
    • コーディングとコードの品質
    • コミュニケーション
    • コンパイラ
    • 構成
    • 継続的統合（CI）
    • データベース
      • nosql
      • ポストグレス
    • データ形式
    • データサイエンス/データエンジニアリング
    • デバッグ
    • デザイン（ビジュアル、UX、UI、タイポグラフィ）
    • デザイン（OOモデリング、アーキテクチャ、パターン、アンチパターンなど）
      • 設計：データベーススキーマ
      • デザイン：パターン
      • デザイン：シンプルさ
    • 開発環境とツール
    • Docker
    • ドキュメント
    • ドットファイル
    • 編集者＆IDE
      • vim
    • メール
    • エンジニアリング管理
    • 演習
    • 実験
    • 機能プログラミング（FP）
    • ゲーム開発
    • グラフィックス
    • ハードウェア
    • http
    • ユーモア
    • インシデント応答（oncall、alerting、停止、消防、ポスト死）
      • 死後
    • インターネット
    • インタビュー
    • Kubernetes
    • 大手言語モデル（LLM）
    • 学習と記憶
    • ライセンス（合法）
    • Linux（システム管理）
    • ローコード/ノーコード
    • 低レベル、アセンブリ
    • 機械学習/AI
    • 数学
    • マーケティング
    • ネットワーク
    • 観測可能性（監視、ロギング、例外処理）
      • ロギング
      • エラー/例外処理
      • メトリック
      • 監視
    • オープンソース
    • オペレーティングシステム（OS）
    • オーバーエンジニアリング
    • パフォーマンス
    • パーソナルナレッジマネジメント（PKM）
    • 個人的な生産性
    • 視点
    • プライバシー
    • 問題解決
    • ソフトウェアエンジニア向けの製品管理
    • プロジェクト管理
    • プログラミング言語
      • Python
      • JavaScript
      • ごみ収集
    • プログラミングパラダイム
    • 人前で話す（提示）
    • 読む
    • リファクタリング
    • 正規表現
    • リリースと展開
      • バージョン化
      • チェックリスト
      • 機能フラグ
      • 生産におけるテスト
    • 信頼性
      • 弾力性
    • 検索
    • 安全
    • シェル（コマンドライン）
    • SQL
    • システム管理
    • システムアーキテクチャ
      • アーキテクチャパターン
      • マイクロサービス/モノリスの分割
    • スケーラビリティ
    • サイト信頼性エンジニアリング（SRE）
    • 技術的な負債
    • テスト
    • ツール
    • タイプシステム
    • タイポグラフィ
    • バージョンコントロール（git）
    • 労働倫理、生産性、仕事/ライフバランス
    • Web開発
    • ライティング（コミュニケーション、ブログ）
  • プレゼンテーションのリソースとインスピレーション
  • 最新の状態を維持します
  • 概念
  • 私の他のリスト

プロのプログラミング - このリストについて

木を切り倒すために私に6時間を与えてください、そして私は最初の4つを費やしてxを磨きます。 （アブラハムリンカーン）

プログラマー向けのフルスタックリソースのコレクション。

このページの目標は、あなたをより熟練した開発者にすることです。私が本当に刺激的であると感じた、または時代を超越したクラシックになったリソースのみを見つけるでしょう。

原則

• このページは包括的であることを意図したものではありません。私はそれを軽く保ち、圧倒的すぎないようにしようとしています。
• 記事の選択は意見です。
• 私は、これらのリソースのすべてに書かれているすべての行に必ずしも同意または承認するわけではありません。同じことが彼らの著者にも当てはまります：私はそれらの著者が言ったすべてのことを支持しません、そして決して言うでしょう。

アイテム：

• ？ ：リソースのリスト
• ： 本
• ？ ：ビデオ/映画の抽出/映画/トーク
• ？ ：スライド/プレゼンテーション
• ショ和：必見です
• ？ ： 紙

このリストに貢献します

貢献するためにPRを自由に開いてください！

私はすべてを追加するつもりはありません。上記のように、私はリストを簡潔にしようとしています。

必見の本

私はこれらの本が信じられないほど刺激的であることがわかりました：

• 実用的なプログラマー：ジャーニーマンからマスターまで：プログラミングについて読んだ最も刺激的で便利な本を実践しています。
• コードの完了：ソフトウェア構造の実用的なハンドブック：実用的なプログラマーへの素晴らしい追加は、コードについて話すために必要なフレームワークを提供します。
• リリースIT！：この本はコードを超えて、生産対応のソフトウェアを構築するためのベストプラクティスを提供します。それはあなたに約3年分の現実世界の経験を与えるでしょう。
• スケーラビリティルール：Webサイトをスケーリングするための50の原則
• Linuxプログラミングインターフェイス：Linux and Unix Systemプログラミングハンドブック：Linuxについて知っておくべきほとんどすべてのことを教えること以外に、この本はソフトウェアの進化とシンプルでエレガントなインターフェイスを持つことの価値についての洞察を提供します。
• コンピュータープログラムの構造と解釈（無料）：コンピューターサイエンスで最も影響力のある教科書の1つ（MITで書かれ、使用されています）であるSICPは、CS教育に影響を与えています。 BYTEは、「自分の職業に本当に興味があるプロのプログラマーに」SICPを推奨しました。

以下を含むいくつかの無料の本があります

• 専門的なソフトウェア開発：このページのかなり完全で良い仲間です。無料の章は、主にソフトウェア開発プロセス（設計、テスト、コードライティングなど）に焦点を当てており、技術自体ではありません。
• ？ VHF/FREEプログラミングブック
• ？電子ブックファウンデーション/フリープログラミングブック

必見の記事

• 新しいソフトウェアエンジニアへの実用的なアドバイス
• シニアエンジニアであること
• ソフトウェア開発で学んだ教訓：1つの短い記事で、長年の苦労して稼いだ教訓を提供する記事の1つ。読む必要があります。
• 私が難しい方法を学んだこと
  • 最初に仕様、次にコードします
  • テストにより、APIが改善されます
  • 将来の思考は将来のゴミ箱です
  • ドキュメントは、あなたの将来の自己へのラブレターです
  • 時には、何もしないよりもアプリケーションをクラッシュさせる方が良い
  • 貨物カルトを理解し、離れてください
  • 「ジョブのための正しいツール」は、議題を推進することだけです
  • 基本的な機能プログラミングを学びます
  • 必ず日付でタイムゾーンを使用してください
  • 常にUTF-8を使用してください
  • ライブラリを作成します
  • 監視を学ぶ
  • 明示的なのは暗黙的なものよりも優れています
  • 企業は専門家を探していますが、ジェネラリストをより長く保ちます
  • ユーザーデータに対処するための最良の安全な方法は、それをキャプチャしないことです
  • 停止する時が来たら、停止する時です
  • あなたはあなたのコードの使用に責任があります
  • そうでないときは「終わった」とは言わないでください
  • 人々があなたにどのように反応するかに注意してください
  • 微小攻撃に注意してください
  • 「私が知らないもの」のリストを保管してください
• あなたが良いプログラマーであることの兆候（ここのすべてが素晴らしいわけではありません - ポイントのいくつかは逆効果です）
  • 最初に実験する本能
  • コードとデザインからの感情的な分離
  • 壊れていないものを修正したいと思っています
  • 理解できないことに魅了されます
  • 教えることを強いられました
  • 腐敗しない忍耐
  • 完璧の破壊的な追求
  • プラットフォームの百科事典の把握
  • コードで考えます
  • ローマにいるとき、ローマ人がそうするようにします
  • 独自のツールを作成します
  • 階層に無関心
  • 失敗に興奮しました
  • 状況に無関心
  • コミットメントのために衝動を置き換えます
  • 経験に駆られます
• 7絶対的な真実は、ジュニア開発者として学習していません
  • あなたのキャリアの早い段階で、あなた自身でコーディングするよりも、1年で支援チームで10倍以上を学ぶことができます
  • すべての企業には問題があり、すべての企業には技術的な負債があります。
  • 現実世界の経験が不足しているトピックについて過度に意見を述べていることは、かなりrog慢です。
  • 多くの会議の講演は、実際のシナリオではなく、概念の証明をカバーしています。
  • レガシーへの対処は完全に正常です。
  • アーキテクチャは、ニットピッキングよりも重要です。
  • 必要に応じて、ドキュメントを介した自動化に焦点を当てます。
  • いくつかの技術的な借金を持っていることは健全です。
  • シニアエンジニアは、プログラミング以外に多くのスキルを開発する必要があります。
  • 私たちは皆、一部の分野でまだジュニアです。
• 優れたソフトウェアを構築する方法
  • 基本的なエンジニアリング慣行の優れた高レベルの要約。
  • 悪いソフトウェアの根本的な原因は、特定のエンジニアリングの選択とはあまり関係がなく、開発プロジェクトの管理方法に関係しています。
  • プラトンで優れたエンジニアリングのようなものはありません。それはあなたのニーズとあなたが遭遇する実際的な問題に依存します。
  • ソフトウェアは、静的製品としてではなく、開発チームの集合的理解の生計の現れとして扱う必要があります。
  • ソフトウェアプロジェクトは、小さすぎるために失敗することはめったにありません。彼らは大きくなりすぎるので失敗します。
  • 問題の声明を装った官僚的な目標に注意してください。私たちの最終目標が市民の生活をより良くすることである場合、私たちは彼らの生活を悪化させていることを明示的に認める必要があります。
  • ソフトウェアの構築は、失敗を回避することではありません。それは、何か良いものを構築するために必要な情報を取得するために、できるだけ速く戦略的に失敗することです。
• -10xエンジニアになる方法
  • 10人のエンジニアの出力を無効にします。
  • テクニカルディスカッションで10人のエンジニアを人質にします。
  • クラウドコストに10週間の賃金を無駄にします。
  • 悪いアーキテクチャで400時間のエンジニアリングを無駄にします。
  • 400時間のバグトリアージが発生します。

その他の一般的な資料とリソースのリスト

他のリスト

• Liuchong/Awesome-Roadmaps：ロードマップのキュレーションリスト。

本

• Imposter's Handbook -30ドル。著者から：「CSの学位を持っていないのですか？私もそうしません - それが私がこの本を書いた理由です。」
• コンピューターサイエンスの本

記事

• MR-MIG/すべてのプログラマーショール知っている：すべてのソフトウェア開発者が知っておくべき（ほとんど）技術的なもののコレクション
• ソフトウェア開発の有名な法則
• Amazon Builders 'Library
  • このTwitterスレッドには最高の記事のリストがあります
• Kdeldycke/Awesome-Falsehood：虚偽プログラマーが信じています
• Hellerve/Programming-Talks
• Techyaks：講演のリスト
• プログラミングについての考え方を変えた講演
• すべてのコンピューターサイエンス専攻が知っておくべきこと
• kamranahmedse/developer-roadmap
• mtdvio/すべてのプログラマーの整った知識：すべてのソフトウェア開発者が知っておくべき（ほとんど）技術的なもののコレクション
• マイク・アクトンのプロのソフトウェアエンジニアに対する期待
• 彼らがソフトウェアエンジニアリングについて教えていなかったこと
  • ドメインの知識は、コーディングスキルよりも重要です
  • コードはセカンダリです。ビジネス価値が最初です。
  • あなたはほとんどの場合、不確実性を伴います
• 短期的な能力を過大評価していますが、長期的な能力を過小評価しています。
  • 専門化は昆虫向けです。
• あなたの技術キャリアに不公平な利点が欲しいですか？他の役割向けのコンテンツを消費します
  • 近代的なハイテク企業では、職域を超えた理解が重要です
  • 他の役割の重要性と困難を過小評価しないようにするのに役立ちます
  • その役割の人々との相互作用において戦略的になるのに役立ちます
• 10年後に自分でプログラミングを教えてください

公理

• 教訓 - ウルビット
  • データはコードよりも優れています。
  • 正確性はパフォーマンスよりも重要です。
  • 決定論的はヒューリスティックを打ちます。
  • 100行のシンプルさは、20行の複雑さよりも優れています。
  • 抽象化が漏れている場合、それは宇宙の法則によるものではありません。抽象化を吸うだけです。通常、抽象化を十分に狭く指定しませんでした。
  • その中の悪魔を目覚めさせることを恐れてコードのセクションを変更しないようにすると、あなたは恐れて生きています。あなたが書いた、またはよく知っているコードの小さなセクションの快適な範囲にとどまる場合、あなたは伝説的なコードを書くことは決してありません。すべてのコードは人間によって書かれており、人間によって習得できます。
  • 明らかに何かをして間違った方法をする正しい方法がある場合は、それを正しい方法で行います。コーディングには信じられないほどの規律が必要です。
  • 正しい答えを得るための最良の方法は、間違った方法で試すことです。
  • 練習は、物事が良いか悪いかを教えてくれます。理論はあなたにその理由を伝えます。
  • 問題を解決する資格がないことは、それを解決しない理由ではありません。
  • 使用しているシステムがわからない場合は、制御しません。システムがシステムを理解していない場合、システムは制御されています。
• 埋め込まれた経験則
• 私の人生を変えた50のアイデア
• 10,000時間のプログラミングに関する反射
• 20年でソフトウェアエンジニアとして学んだ20のこと

コース

• Google Tech Dev Guide
• CS教育の失われた学期、MIT。シェル、編集者、データレラング、GIT、デバッグとプロファイリング、メタプログラミング、セキュリティ、暗号化に関する講義が含まれています。
• 冒険的な自己学習者、ニール・セインズベリーの数学
• Jwasham/Coding-InterView-University：ソフトウェアエンジニアになるための完全なコンピューターサイエンスの学習計画。
• 自分でコンピューターサイエンスを教える：最高のCSリソースの意見のセット。
• Ossu/Computer-Science：コンピューターサイエンスの無料の独学教育！

トピック

アルゴリズムとデータ構造

• CLRSを読んでください。 OCWでコースを視聴してダウンロードできます。新しいコースもあります。
• またはアルゴリズム設計マニュアル
• Project Eulerでいくつかのアルゴリズムを試してみてください
• CS 61B 2023年春

その他のリソース：

• アルゴリズム、ジェフ・エリクソン

正直に言ってください：アルゴリズムはかなり乾燥したトピックになる可能性があります。このQuoraの質問には、以下を含むいくつかの面白い学習の代替案がリストされています。

• グローキングアルゴリズム
• 必須アルゴリズム
• データ構造の視覚化
• ？ 15 6分間でアルゴリズムの並べ替え
• ハッシュ
• 視覚化アルゴリズム
• Bツリーとデータベースインデックス

実装の例：

• trekhleb/javascript-algorithms：JavaScriptに実装されたアルゴリズムとデータ構造
• アルゴリズム

分散システムのアルゴリズム：

• RAFTコンセンサスアルゴリズム

APIの設計と開発

一般的な休憩コンテンツ：

• アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計、Roy Fielding（The Inventor of Rest）
• RESTFUL HTTP+JSON APIを構築するための有用なリソースのコレクション。
• REST APIデザインのベストプラクティス、スタックオーバーフローブログ
• 邪魔されていない休息：完璧なAPIを設計するためのガイド：Restful APIデザインに関する非常に完全な本。

ガイドラインの例：

• MicrosoftのREST APIガイドライン
• Zalando Restful APIおよびイベントスキームガイドライン
• GoogleのAPIデザインガイド：ネットワーク付きAPIを設計するための一般ガイド。
• AIP-1：AIPの目的とガイドライン
  • AIPは、API改善提案の略です。これは、API開発のための高レベルの簡潔なドキュメントを提供する設計ドキュメントです。

より具体的なトピック：

• キーではなくリンクを使用して、API、Martin Nally、Googleの関係を表す理由
  • 「APIで関係を表現するために外部キーの代わりにリンクを使用すると、クライアントがAPIを使用するために知っておくべき情報の量が減り、クライアントとサーバーが互いに結合される方法を減らします。」
• webhooksではなく、私 /イベントをください
  • イベントは、Webhookの消費者がWebhookサブスクリプションの位置を再生またはリセットできるようにするなど、非常に必要なWebhook機能のロックを解除できます。
• JSONパッチのパワーのロックを解除します

態度、習慣、考え方

• マスタープログラミング、ケントベック。
• 熟練したプログラマーの特徴
• プログラミングのTAO：プログラミングに関するたとえ話のセット。
• 所有権を取ることは、あなたが望むものを手に入れる最も効果的な方法です
• より良い開発者になる時間を見つけます
• 1日10分：Alex Allainが毎日10分間書くことで、200時間以内に本を書いた方法。
• ソフトウェアエンジニアのケアと給餌（または、エンジニアが不機嫌な理由）
  • ソフトウェア、製品マネージャー、デザイナー、ソフトウェアエンジニアの勝利では、エンジニアのみが創造的な心をオフにして生産することが期待されています。
  • エンジニアとプロダクトマネージャーの両方が、製品の仕様または要件がIKEAの家具マニュアルに相当すると誤って考える傾向があります。
  • これは、エンジニアを不機嫌にするトップのものの1つです。絶えず優先順位を変えます。
  • 多くのエンジニアは、製品マネージャーが自分の心を変えると不平を言うでしょうが、時間の推定ではほとんどそれを説明するものはほとんどありません。
  • コンピューターサイエンスプログラムは、業界で直面するタスクの準備に関するものではありません。
  • 使用できるよりも多くのエンジニアがいる場合、エンジニアリングの時間は、開発、計画、同期、および調整に向けて離れることになります。
  • 創造的なプロセスにエンジニアを巻き込みます
  • エンジニアに創造的になる機会を与えます。
  • 休みを奨励します。
  • コードしましょう
  • 表明に感謝します
• 製品志向のソフトウェアエンジニア、Gergely Orosz
  • 優れた製品エンジニアは、最小限の愛すべき製品が正しい深さを必要としていることを知っています
  • 製品志向のエンジニアはすぐにエッジケースをマッピングし、それらの作業を減らす方法を考えてください：多くの場合、エンジニアリング作業を必要としないソリューションをもたらす
  • ユーザー調査とカスタマーサポートに従事します
  • テーブルによく裏付けられた製品の提案を持ってきてください
  • 製品/エンジニアリングのトレードオフを提供します
• 40年の40レッスン、スティーブシュラフマン
  • 最も重要なことを進歩させたい場合は、誰が失望するかを決める必要があります。それは避けられません。
  • あなたができる最良の投資はあなた自身の教育です。学習を止めないでください。あなたができる2番目の最良の投資は、本物の意味のあるやり取りを通じてあなたのネットワークを構築することです。それはあなたが知っていることであり、あなたが知っている人です。
  • あなたはあなたが求めていないものを手に入れたり、積極的に探し出したりすることは決してありません。頑張れ！
  • トンネルの端にある光についてではありません。それはトンネルです。毎日現れて、プロセスを楽しんでください。
  • 偉大なチームメイトは、常に組織とその目的を自分の自己利益よりも先に置いています。
  • あなたの斑点を選んでください。時間が限られており、脳はそれほど処理することしかできません。フォーカスが重要です。賢く選択してください。
  • すべての人が何かに苦労している可能性があります。親切に。役立ちます。
• コーディング、自我、注意
  • 初心者の心は、絶対的な知識が無限であり、したがってスコアを維持することは時間の無駄であるという事実を受け入れます。
  • 習得は、単に勢いの蓄積であり、知識の蓄積ではありません。
  • 自我の注意散漫に対処することで、問題解決プロセスを愛することが教えてくれました。学習プロセスを愛し、尊重することを教えてくれました。その結果、私はより生産的です。私はそれほど心配していません。私はより良いチームメイトです。私はより良い友達であり、より良い思想家です。
• 修正vs.成長：私たちの生活を形作る2つの基本的な考え方
• 優れたソフトウェアエンジニアはどのように見えますか？
• 良い睡眠、良い学習、良い生活
• ？スティーブ・ジョブズ：助けを求めなければ、あなたはそれほど遠くに行かないでしょう
• プログラミングの引用
• 親切に
  • 親切であることは、基本的にあなたの周りの人々への影響に責任を負うことです。
  • それはあなたが彼らの感情に留意し、あなたの存在が彼らに影響を与える方法に思いやりがあることを必要とします。
• ウォーレン・バフェットは、この1つの単純な習慣が成功した人々と他のすべての人を分離すると言います
  • 成功した人々と本当に成功した人々の違いは、本当に成功した人々がほとんどすべてにノーと言うことです。
• 幸運を得る方法は？
• プログラマーは無能を祝うのをやめるべきです、DHH
  • プログラミングの魔法は、主にあなたがまだ知らないものです。
  • あなたがあなたのキャリアをプログラミングするつもりなら、あなたが習得への道にいるべきではないと思うのは大丈夫ではありません。
• 速度制限はありません
• 動機を待たないで、勢いを求めてください
  • 小さなタスクから始めます。その後、その勢いに乗ってください。
• 最も重要なコーディング習慣
  • 最も重要なコーディング習慣
  • 毎日のストレッチ
  • 定期的な休憩を取る
  • 夜遅くにコーディングしないでください
  • コーディング環境を改善します
• 他のすべてのアドバイスエッセイを読んだ新しいソフトウェア開発者へのアドバイス
• マイクロサービスは問題ではありません。無能な人々はそうです

詐欺症症候群は過小評価されています。多くの話は、詐欺症症候群を克服することにかかっています。私は自尊心を受け入れ、毎日自分自身を疑うと言います。あなたの知識の多くが毎年期限切れになっている速い動きの業界では、あなたの周りの最も若い人でさえ、あなたが持っていないスキルを絶えず調理します。初心者の決意（そして恐怖さえ）を申請することで、競争力を維持します。このトレッドミルの利点は、すべてのエンジニアがその上にいるということです。あなたが詐欺師であるからといって、他の人があなたよりもふさわしいという意味ではありません。自分のために擁護し、リスクを冒して、物事がうまくいったときに背中を軽くたたいて、問題を解決する実績を構築し始めると、スキルと適応性を信頼します。間違いを犯さないでください：あなたはあなたが解決する最後の問題と同じくらい良いだけです。

ダン・ヘラー、ソフトウェアのキャリアを構築します

私は執筆の井戸を空にすることは決してないことをすでに学んでいましたが、井戸の深い部分にまだ何かがあったときは常に止まり、それを養ったスプリングスから夜に補充させました。 - アーネストヘミングウェイ

• Grug Braind Developer：自己認識プログラマーの習慣。プログラミングのタオのように、異なるスタイル。

良い判断は経験から生まれます。経験は悪い判断から来ています。

先延ばし

• ニュースはあなたにとって悪いことです - そしてそれを読むことをあきらめるとあなたは幸せになります、ガーディアン
  • ニュースの誤解
  • ニュースは無関係です
  • ニュースには説明力がありません
  • ニュースはあなたの体に有毒です
  • ニュースは認知エラーを増加させます
  • ニュースは思考を阻害します
  • ニュースは薬のように機能します
  • ニュースは時間を無駄にします
  • ニュースは私たちを受動的にします
  • ニュースは創造性を殺します

認証/承認

• マイクロサービスの世界での承認
• 承認ロジック：ルールは時間の経過とともに進化するため困難です
• コペンハーゲンの本は、WebアプリケーションでAUTHの実装に関する一般的なガイドラインを提供します

オートメーション

• 自動化は、ウルトロンではなくアイアンマンのようなものでなければなりません

ベストプラクティス

• ソフトウェアエンジニアリングプラクティス

ソフトウェアエンジニアリングとランダムを超えて

• ソフトウェアエンジニアが木工を好む理由

バイアス

バイアスは雇用にのみ当てはまりません。たとえば、基本的な帰属バイアスは、かなり前に書かれた誰かのコードをまったく異なる文脈で批判するときにも適用されます。

• 認知バイアスチートシート。 ＃雇用

仕事

• 開発者の支払い101
• 自家製の請求システムに関する4つの最大の問題
• ？独自の請求システムを構築する14の痛み

キャッシュ

• キャッシュの課題と戦略、Amazon Builders Library

キャリアの成長

• 上級レベルの開発の結合された三角形は、シニアエンジニアの定義方法を検討します。
• エンジニアとしての成長のための10の原則、ダン・ヘラー。
• 自分をプログラマー、パトリック・マッケンジーと呼ばないでください。
• エンジニアリングマネージャーであること
• 25歳であったらいいのに、キャリアアドバイス
  • キャリアはマラソンであり、スプリントではありません
  • ほとんどの成功は、新しいものではなく、繰り返しから来ています
  • 仕事が本当に素晴らしかったなら、すべての金持ちは仕事をするでしょう
  • 経営陣は、物ではなく人々に関するものです
  • 本当に他の人の話を聞いてください
  • スタッフは有限の感情的能力を持つ人々であることを認識してください
  • 自分の年齢とネットワークするだけではありません
  • 仕事の理由で個人的な倫理を犠牲にしないでください
  • 失敗が学習していることを認識してください
• キャリアアドバイス私が若かったときに与えられたらいいのに
  • 長期的な計画にあまり集中しないでください。
  • 良い思想家を見つけて、あなたが最も尊敬するものをコールドコールしてください。
  • 生涯にわたって生産性に高い価値を割り当てます。
  • あなたの最優先事項ではないものを過度に最適化しないでください。
  • たくさん読んで、あなたの周りの人々が読んでいないことを読んでください。
  • 解決に優先順位を付けるための問題を真剣に考えてください。
  • 続きの歴史を読んでください。
• 優れた開発者が不幸に昇進する理由、ロブ・ウォーリング。または、なぜ経営陣があなたのためではないかもしれない。
• 世界で最も差し迫った問題を解決するためにあなたのキャリアを使用するためのガイド
• シニアエンジニアの仕事は何ですか？単なる個々の貢献者以上のものである必要があります。
• ブートキャンプの卒業生のコーディングから、分散データベースの構築まで
  • ブログの投稿ではなく、本（および論文）を読んでください
  • あなたのキャリアの軌跡に責任を負います
• ？丸みを帯びたエンジニアには、たくさんの素晴らしい本の推奨事項が含まれています。
  • パラダイムポリグロット（さまざまな言語とパラダイムを学ぶ）
  • データベースポリグロット
  • プロトコルポリグロット（できればTCP/IPおよびHTTP）
  • ビルドツール、パッケージング、配信の習熟度
  • デバッグ、観測可能性
  • 展開、インフラ、デヴォープ
  • ソフトウェアアーキテクチャとスケーリング
  • おもちゃのコンパイラ、通訳者、パーサーを書く能力
  • おもちゃのゲームを書く能力
  • アルゴリズム分析を理解する能力
• いくつかのキャリアアドバイス、ウィルラーソン。
  • あなたが得るアドバイスは、世界がどのように機能するかについての正確な声明ではなく、彼らの経験を統合しようとする誰かの試みです。
  • 名声の貯水池を構築します。
  • 一部の人々は、彼らが現在の役割でかけがえのないものになることになることに非常に優れているため、彼らがより興味深い候補者であっても、彼らは彼らの役割にとどまります。
  • あなたが行くところはどこでもあなたに続く素晴らしい関係があなたに続きます。悪いものも。
  • あなたのキャリアの早い段階で、できるだけ多くの種類の企業やさまざまな製品で働くようにしてください。
• 邪悪なヒント：「簡単な」ものを避けてください
• 究極のコードカタ
• シニアソフトウェアエンジニアの特性：影響、認識、可視性、影響力、メンタリング
• ソフトウェアエンジニアリング - ソフトパーツ
  • 批判的に考え、十分に熟した議論を策定します
  • 基礎をマスターします
  • ユーザーに焦点を当てると、他のすべてが続きます
  • 学ぶ方法を学びます
• ソフトウェアエンジニアとしての成長を所有する方法
• 40年のプログラマー
  • あなたが良くなるほど、あなたは他のみんなのように見えません
  • あなたは基本をすることによって深い原則を学びます
  • 他のフィールドに目を向け、他のフィールドから学びます
  • 生産性のヒントに注意してください
• シニアエンジニアは将来住んでいます
• あなたのキャリアの地図はどのように見えますか？
• Amazon（またはそのための他の大企業）で成功する方法）

シニアエンジニアについて：

• 虚偽のジュニア開発者は、シニアになることを信じています

次の/最初の機会を選択します

• キャリア決定 - Elad Gil -Eladブログ

スタッフに行く

• 私は5年でファンスタッフエンジニアになりました。これらは、私が途中で学んだ14の教訓です。
  • ソフトウェアエンジニアリングは単なるコーディングではありません。実際、コーディングはそのほんの一部です。
  • あなたの仕事のパイプライン
  • フィードバックを受け入れて聞いてください。真剣に、聞いてください。
  • 素晴らしいフィードバックを見つけるのは難しいです。それを大切にしてください。
  • 地平線に注意してください（ただし、両方ではありません）。
  • 重要なことを理解し、残りを手放します。
  • 比較は本当に喜びの泥棒です。
  • メンターシップは美しいものです。
  • 一般的に、良い日は「起こる」だけではありません。
  • アドバイスとガイダンスはまさにそれです。それらはルールではありません。
• スタッフ以上のエンジニアリングの役割に到達するためのガイド、ウィルラーソン
  • 見える
  • スタッフプラスエンジニアリングに関する追加のリソース

文字セット

• 絶対的な最小のすべてのソフトウェア開発者は、Unicodeとキャラクターセットについて積極的に積極的に知っておく必要があります（言い訳はありません！）
• すべてのソフトウェア開発者が2023年にUnicodeについて知っておくべき絶対的な最小値（まだ言い訳はありません！）

チェス

（はい - チェスは独自のセクションを取得します:)

• チェスプログラミングwiki
• チェスの動きを圧縮します

雲

• Open-Guides/OG-Aws：AWSの実用的なガイド

コードレビュー

• コードレビューを行う方法、Googleのエンジニアリングプラクティスドキュメント。
• コミットポストレビュー：開発者の速度を高めるという興味深いアイデア（ただし、いくつかの注意事項があります）。
• あなたのコードレビュアーをあなたに恋させる方法
  • 最初に独自のコードを確認してください
  • 明確なチェンジリストの説明を書きます
  • 簡単なものを自動化します
  • コード自体で質問に答えます
  • 狭いスコープの変更
  • 個別の機能的および非機能的変化
  • 批評に丁寧に対応します
  • 不足している情報を巧みに募集します
  • すべての絆をレビュアーに授与します
  • レビューのラウンド間の遅延を最小限に抑えます
• 人間のようなコードレビューを行う方法
• HN：Codeをどのように確認しますか？：Hackernewsに関する素晴らしい議論、興味深いアイデアがいっぱいです。
• コードレビューのマスローのピラミッド
  • 同じトピックに関するもう1つ：コードレビューPyramid
• リモートチームのコードレビュー：非常に完全なルールセット。
• デフォルトではコードレビューはありません
  • 条約に対する責任

コーディングとコードの品質

• 削除が簡単で、拡張が簡単ではないコードを書き込む
• エゴレスプログラミングの10の戒め
• クリーンコード：アジャイルソフトウェアクラフトマンシップのハンドブック、ロバートC.マーティン。多くの有用なベストプラクティスについて説明しています。少し長い。クリーンコードチートシートもあります。
• ソフトウェアの職人技とは何ですか
  • がらくたを書くのにうんざりしています。
  • 後で物事を掃除することについての愚かな古い嘘を受け入れません。
  • 私たちは、クイックは汚いことを意味するという主張を信じていません。
  • 私たちは誰も私たちに専門的に振る舞わせることを許可しません。
• ブール変数の命名に関するヒント
  • 「IS」または「HAS」を使用したブール変数と関数名をプレフィックスするための規則があります。
  • 複数の場合でも、常に使用してみてください（ isEachUserLoggedIn areUsersLoggedInまたはisUsersLoggedInよりも優れています）
  • カスタムプレフィックスを避けてください（ isPaidFor wasPaidForよりも優れています）
  • ネガを避けます（ isEnabled isDisabledよりも優れています）
• 維持不可能なコードの書き方
• Kettanaito/Naming-Cheatsheet ：：変数の命名に関する包括的な言語に依存しないガイドライン。 A/HC/LCパターンのホーム。
• ？質の高いエンジニアリングガイド

コミュニケーション

執筆セクションも参照してください

• 開発者として効果的にコミュニケーションをとる方法
  • 具体的なアドバイスと短い、中型、長編の執筆のための例
• プログラミング中に何を視覚化しますか？

コンパイラ

• コンパイラライターリソースページ
• カナカ/マル：マル - リスプを作る

構成

• 構成ファイルのJSONの欠点、Martin Tournoij。
  • コメントを追加できません
  • 過度の引用と構文ノイズ
  • DC（宣言的構成）を使用してロジックを制御することは、多くの場合、良い考えではありません。
• あなたの構成は吸う？実際のプログラミング言語を試してください
  • ほとんどの最新の構成形式は吸う
  • 実際のプログラミング言語を使用します

継続的統合（CI）

• 継続的な統合、MartinFowler.com

データベース

SQLセクションも参照してください。

• キャップ定理の平易な英語の紹介
• PACELC定理：「分散コンピューターシステムのネットワークパーティション（P）の場合、可用性（a）と一貫性（c）（キャップ​​定理による）を選択する必要がありますが、システムがシステムがあっても（e）通常、パーティションがない場合に実行されているため、レイテンシ（L）と一貫性（C）を選択する必要があります。」
• ゼロダウンタイムデータベースの移行（コードの例はRailsを使用していますが、これはプログラミング言語に最適です）
• 最新のストレージシステム、ACMキューの背後にあるアルゴリズム
• 簡単なデータベースを作成しましょう
• データベースシステムの読み取り、第5版
• データベースタイプの比較：データベースタイプがどのように進化してさまざまなニーズを満たすか
• リレーショナルデータベースはどのように機能しますか
• インデックス、ルークを使用します
• コースの紹介 - 開発者向けのMySQL、PlanetScale
• クエリエンジンの仕組み
• おそらくSqliteを使用する必要がある理由| Epic Web Dev

nosql

• NOSQLパターン
• NOSQLデータベース：調査と決定ガイダンス
• DynamoDBドキュメントには素晴らしいページがあります。
  • 一貫性を読みます
  • SQLからNOSQLへ
  • dynamodbのnosql設計
• Redisは説明しました

ポストグレス

• 大量のPostgreSQLの安全な操作（これはPostgreSQL用ですが、他のDBSにも適しています）。
• ポストグレスでのトランザクション分離、説明しました
• PostgreSQLエクササイズ
• Postgres Operationsチートシート
• Postgresを使用するだけです
• ポストグレスで十分です
• Postgres：これをしないでください
• プライマリキーとしてのPostgreSQLおよびUUID

データ形式

• 虚偽のプログラマーは、電話番号、Googleのlibphonenumberについて信じています。
• オートコンプリートのルール：オートコンプリートフィールドの大まかな仕様
• 虚偽プログラマーは住所について信じています
• 虚偽プログラマーは名前を信じています
• Kdeldycke/Awesome-Falsehood：虚偽プログラマーが信じています
• UUID、ulids、弦の表現を理解する
• 虚偽プログラマーは、虚偽のリストについて信じています
• オーストラリア/lord_howeは最も奇妙なタイムゾーンです

データサイエンス/データエンジニアリング

• ダーティダース：オンライン制御された実験における12の一般的なメトリック解釈落とし穴
• dataStacktv/data-engineer-roadmap：データエンジニアになるためのロードマップ
• 素晴らしいデータエンジニアリング学習パス
• 最新のデータインフラストラクチャのための新しいアーキテクチャ
• モノリシックデータ湖を超えて分散データメッシュに移動する方法
  • データレイクアーキテクチャに基づくデータプラットフォームには、大規模な約束が満たされていない共通の障害モードがあります。
  • ドメインをファーストクラスの関心事と見なし、プラットフォーム思考を適用してセルフサービスのデータインフラストラクチャを作成し、データを製品として扱う必要があります。
• mlops
• Uberのビッグデータプラットフォーム：100以上のペタバイトが微小レイテンシを備えています
• SQLは、データ変換ロジックのデフォルトの選択肢である必要があります

デバッグ

また、このドキュメントのインシデント応答セクションも参照してください

• ラバーダックの問題解決
• ラバーダッキング
• 5つの理由
• 5つの嘘分析
  • 本当の問題は、テクニックがテンプレートの一部になると、それ自体を明らかにします。
  • アクションアイテムは、根本原因から非常に遠い場合があります。
• Infinite Howsは、5つの理由を批判し、インシデントから最も多くを学ぶために、異なる質問のセットを提唱します。
  • 参照：Human Errors：Models and Management
  • 「5つの理由の問題は、それがトンネルが分割され、仕事がどのように行われ、イベントが発生するかについての直線的で単純な説明に分割されていることです。」
  • 「ヒューマンエラーは、結論ではなく出発点になります。」 （Dekker、2009）
  • 「「どのように？」と尋ねると、物語を求めています。」
  • 「決定や行動に関しては、誰かが彼らがしたことをすることがどのように理にかなっているのかを知りたいと思います。」
  • 各「なぜ」ステップで、さらなる調査のために1つの回答のみが選択されます。 「どのように」を尋ねると、より広い探査が促進されます。
  • 「事故調査では、他のほとんどの人間の努力と同様に、私たちは何をしているのか、何をしているのか、それともwylfiwyfの原則を獲得します。これは、私たちが何であるかについての仮定が単純な認識です。 （見ているものを見てみようと）大部分は、実際に見つけたもの（何をしているのか）を決定します。」 （Hollnagel、2009、p。85）（wylfiwyfのイラストを参照）
  • 「「根本的な原因」が選択される最終的な理由は、特定された原因として政治的に受け入れられることです。他の出来事や説明は、組織またはその請負業者またはその請負業者に恥ずかしい問題を提起するため、詳細に除外されるか、詳細に検討されない可能性があります。政治的に受け入れられません。」 （ナンシー・レヴェソン、エンジニアリング・ア・サー・ワールド、p。20）
  • 境界の合理性：合理的な個人は、最適ではなく満足のいく決定を選択します
  • この記事は、人々からの物語を求める具体的な方法と質問を提供し、より良い洞察をもたらします。
    • What were you expecting to happen?
    • If you had to describe the situation to your colleague at that point, what would you have told?
    • Did this situation fit a standard scenario?
    • What were you trying to achieve?Were there multiple goals at the same time?Was there time pressure or other limitations on what you could do?
    • See template here
• Linux Performance Analysis in 60,000 Milliseconds
• Post-Mortems at HubSpot: What I Learned From 250 Whys
• Debugging zine, Julian Evans
• If you understand a bug, you can fix it
• The Thirty Minute Rule: if anyone gets stuck on something for more than 30 minutes, they should ask for help
• How to create a Minimal, Reproducible Example , Stack Overflow
• Some ways to get better at debugging, Julia Evans
  • Learn the codebase
  • Learn the system (eg, HTTP stack, database transactions)
  • Learn your tools (eg, strace , tcpdump )
  • Learn strategies (eg, writing code to reproduce, adding logging, taking a break)
  • Get experience: according to a study, "experts simply formed more correct hypotheses and were more efficient at finding the fault."
• What exactly is the 'Saff Squeeze' method of finding a bug?
  • A systematic technique for deleting both test code and non-test code from a failing test until the test and code are small enough to understand.
• tcpdump is amazing, Julia Evans
• What we talk about when we talk about 'root cause'

Design (visual, UX, UI, typography)

I highly recommend reading The Non-Designer's Design Book. This is a pretty short book that will give you some very actionable design advices.

• If you're working on data, Edward Tufte's The Visual Display of Quantitative Information is considered a classic.
• The Universal Principles of Design will give you enough vocabulary and concepts to describe design challenges into words.
• Book recommendations from HackerNews
• ?Design for Non-Designers

記事：

• 10 Usability Heuristics Every Designer Should Know
  • Visibility of System Status
  • The Match Between The System And The Real World
  • Every system should have a clear emergency exit
  • Don't forget that people spend 90% of their time interacting with other apps
  • Recognition Rather Than Recall (recognition = shallow form of retrieval from memory, eg a familiar person, recall = deeper retrieval)
  • ”Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery
  • Help Users Recognize, Diagnose, And Recover From Errors
• How to pick more beautiful colors for your data visualizations
• Visual design rules you can safely follow every time

Typograhy: see "Typography" section

リソース：

• ？ bradtraversy/design-resources-for-developers: design and UI resources from stock photos, web templates, CSS frameworks, UI libraries, tools...

Design (OO modeling, architecture, patterns, anti-patterns, etc.)

Here's a list of good books:

• Design Patterns: Elements of Reusable Object-Oriented Software: dubbed "the gang of four", this is almost a required reading for any developer. A lot of those are a bit overkill for Python (because everything is an object, and dynamic typing), but the main idea (composition is better than inheritance) definitely is a good philosophy.
  • And their nefarious nemesis Resign Patterns
• Patterns of Enterprise Application Architecture: learn about how database are used in real world applications. Mike Bayer's SQLAlchemy has been heavily influenced by this book.
• Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans
• Clean Architecture, Robert C. Martin. Uncle Bob proposes an architecture that leverages the Single Responsibility Principle to its fullest. A great way to start a new codebase. Also checkout the clean architecture cheatsheet and this article.
• Game Programming Patterns: a book about design, sequencing, behavioral patterns and much more by Robert Nystrom explained through the medium of game programming. The book is also free to read online here.

One of the absolute references on architecture is Martin Fowler: checkout his Software Architecture Guide.

記事：

• O'Reilly's How to make mistakes in Python
• Education of a Programmer: a developer's thoughts after 35 years in the industry. There's a particularly good section about design & complexity (see "the end to end argument", "layering and componentization").
• Domain-driven design, Wikipedia.
• On the Spectrum of Abstraction ?, Cheng Lou
• The “Bug-O” Notation, Dan Abramov
• Antipatterns
• Inheritance vs. composition: a concrete example in Python. Another slightly longer one here. One last one, in Python 3.
• Composition Instead Of Inheritance
• Complexity and Strategy: interesting perspective on complexity and flexibility with really good examples (eg Google Apps Suite vs. Microsoft Office).
• The Architecture of Open Source Applications
• The Robustness Principle Reconsidered
  • Jon Postel: "Be conservative in what you do, be liberal in what you accept from others." (RFC 793)
  • Two general problem areas are impacted by the Robustness Principle: orderly interoperability and security.
• Basics of the Unix Philosophy, Eric S Raymond
• Eight Habits of Expert Software Designers: An Illustrated Guide

You can use an eraser on the drafting table or a sledge hammer on the construction site. (Frank Lloyd Wright)

リソース：

• ？ Design Principles

Design: database schema

• A humble guide to database schema design, Mike Alche
  • Use at least third normal form
  • Create a last line of defense with constraints
  • Never store full addresses in a single field
  • Never store firstname and lastname in the same field
  • Establish conventions for table and field names.

Design: patterns

• KeystoneInterface, Martin Fowler.
  • Build all the back-end code, integrate, but don't build the user-interface
• 101 Design Patterns & Tips for Developers
• Python Design Patterns: For Sleek And Fashionable Code: a pretty simple introduction to common design patterns (Facade, Adapter, Decorator). A more complete list of design patterns implementation in Python on Github.
• SourceMaking's Design Patterns seems to be a good web resource too.
• Anti-If: The missing patterns

Design: simplicity

• Simple Made Easy ?, Rich Hickey. This is an incredibly inspiring talk redefining simplicity, ease and complexity, and showing that solutions that look easy may actually harm your design.

Dev environment & tools

• ？ Awesome Dev Env

ツール

• Glances: An eye on your system
• HTTPie: a CLI, cURL-like tool for humans
• jq: command-line JSON processor
• tmux: terminal multiplexer
• htop: an interactive process viewer for Linux
• htop explained
• socat
• Visual guide to SSH tunnels
• casey/just: a command runner written in Rust (claims to be better than Makefile)
• Gazr: an opinionated way to define your Makefile

Article about tools:

• The return of fancy tools
  • Simple tools make you think a little more
  • Drucker: "I'm not writing it down to remember it later, I'm writing it down to remember it now."
  • Frictionless note-taking produces notes, but it doesn't produce memory.

Docker

See also the Python-specific section in charlax/python-education.

• Best Practices Around Production Ready Web Apps with Docker Compose
  • Avoiding 2 Compose Files for Dev and Prod with an Override File
  • Reducing Service Duplication with Aliases and Anchors
  • Defining your HEALTHCHECK in Docker Compose not your Dockerfile
  • Making the most of environment variables
  • Using Multi-stage builds to optimize image size
  • Running your container as a non-root user
• Docker Best Practices for Python Developers
  • Use multi-stage builds
  • Pay close attention to the order of your Dockerfile commands to leverage layer caching
  • Smaller Docker images are more modular and secure (watch out for Alpine though)
  • Minimize the number of layers ( RUN , COPY , ADD )
  • Use unprivileged containers
  • Prefer COPY over ADD
  • Cache python packages to the docker host
  • Prefer array over string syntax
  • Understand the difference between ENTRYPOINT and CMD
  • Include a HEALTHCHECK instruction
  • Whenever possible, avoid using the latest tag.
  • Don't store secrets in images
  • Use a .dockerignore file (include **/.git , etc.)
  • Lint and Scan Your Dockerfiles and Images (eg with hadolint )
  • Log to stdout or stderr
• Docker Containers Security

ドキュメント

• Documentation-Driven Development
• Writing automated tests for your documentation: this should be required, IMO. Testing code samples in your documentation ensures they never get outdated.
• ？ Documentation is king, Kenneth Reitz
• Keep a Changelog
• Architectural Decision Records (ADR): a way to document architecture decision.
• Documenting Architecture Decisions
• joelparkerhenderson/architecture-decision-record: examples and templates for ADR.
  • And a CLI tool: npryce/adr-tools
• The documentation system
• Checklist for checklists
• Best practices for writing code comments
• Always be quitting
  • Document your knowledge
  • Train your replacement
  • 委任
  • By being disposable, you free yourself to work on high-impact projects.
• Write documentation first. Then build.
• Diátaxis: a systematic approach to technical documentation authoring
  • There are four modes: tutorials, how-to guides, technical reference and explanation
  • The docs goes into a lot of details about each model.
• Architecture.Md
• Two open source projects with great documentation (esbuild and redis)

The palest ink is more reliable than the most powerful memory. -- Chinese proverb

ドットファイル

• ？ Awesome dotfiles: lots of great dotfiles.
• My dotfiles

記事

• Setting Up a Mac Dev Machine From Zero to Hero With Dotfiles

Editors & IDE

• Sublime Text essential plugins and resources
• Bram Moolenaar (Vim author), Seven habits of effective text editing (presentation). This is about Vim but it contains good lessons about why investing time in learning how to be productive with your text editors pays off.
• VScode is one of the most popular text editors as of writing.
  • Visual Studio Code Can Do That?, Smashing Magazine.
• Coding with Character

vim

• ？ vim-awesome
• ？ Vimcasts
• ️ Is Vim Really Not For You? A Beginner Guide
  • The first part of a series of 6 articles with lots of detailed and practical tips for using Vim efficiently.
  • A Vim Guide for Advanced Users: more advanced shortcuts and commands
• Learning the vi and Vim Editors
• Practical Vim, Drew Neil
• Learn Vimscript the Hard Way
• VimGolf: nice challenges to learn Vim
• Vim anti-patterns
• Learn Vim For the Last Time: A Tutorial and Primer
• Vim Cheat Sheet & Quick Reference
• History and effective use of Vim
• Moving Blazingly Fast With The Core Vim Motions
• micahkepe/vimtutor-sequel: Vimtutor Sequel - Advanced Vim Tutor Lessons
• Vim Racer - An Online Game for VIM Navigation

Feel free to check my vim configuration and my vim cheatsheet.

Other editors:

• Use GNU Emacs

メール

• Email explained from first principles
• ？ Transactional Email Best Practices

Engineering management

Checkout my list of management resources.

演習

The best way to learn is to learn by doing.

• build-your-own-x: compilation of well-written, step-by-step guides for re-creating our favorite technologies from scratch
  • Richard Feynman: "what I cannot create, I do not understand"
• The elevator programming game
• Challenging projects every programmer should try, Austin Z. Henley
• Challenging projects every programmer should try: text editor, space invaders, compiler (Tiny Basic), mini OS, spreadsheet, video game console emulator.
• More challenging projects every programmer should try: ray tracer, key-value store web API, web browser, stock trading bot.
• Let's Build a Regex Engine
• Write a time-series database engine from scratch
• 7 GUIs to build to learn fundamental UI programming skills
• A list of programming playgrounds, Julia Evans
• Write more "useless" software

練習する：

• CodinGame
• Codewars
• Exercism

実験

• 8 annoying A/B testing mistakes every engineer should know

Functional programming (FP)

• Goodbye, Object Oriented Programming
• Functional Programming & Haskell ?: some good reasons to learn FP!
• Functional Programming Fundamentals: short introduction to FP and its advantages.
• OO vs FP, Robert C. Martin, The Clean Code Blog. A pretty interesting take on the differences between OOP and FP from an expert in OOP.
  • OO is not about state. Objects are bags of functions, not bags of data.
  • Functional Programs, like OO Programs, are composed of functions that operate on data.
  • FP imposes discipline upon assignment.
  • OO imposes discipline on function pointers.
  • The principles of software design still apply, regardless of your programming style. The fact that you've decided to use a language that doesn't have an assignment operator does not mean that you can ignore the Single Responsibility Principle.
• Parse, don't validate
  • Use a data structure that makes illegal states unrepresentable
  • Push the burden of proof upward as far as possible, but no further
  • Let your datatypes inform your code, don't let your code control your datatypes
  • Don't be afraid to parse data in multiple passes
  • Avoid denormalized representations of data, especially if it's mutable
  • Use abstract datatypes to make validators “look like” parsers
• ？機能プログラミング
• Monads in 15 minutes
• hemanth/functional-programming-jargon: jargon from the functional programming world in simple terms
• The definitive guide to learning functional programming, Exercism

Games development

• Introduction · Joys of Small Game Development

グラフィックス

• Text Rendering Hates You

ハードウェア

• NandGame: build a computer from scratch.
• What Every Programmer Should Know About SSDs
• How To Make A CPU - A Simple Picture Based Explanation

http

• Choosing an HTTP Status Code — Stop Making It Hard
• HTTPWTF
• 10 Surprising Things You Didn't Know About HTTP
• The HTTP crash course nobody asked for

ユーモア

• The Jeff Dean Facts
  • Compilers don't warn Jeff Dean. Jeff Dean warns compilers.
  • Unsatisfied with constant time, Jeff Dean created the world's first O(1/N) algorithm.
  • Jeff Dean mines bitcoins. In his head.
• The Daily WTF: Curious Perversions in Information Technology

Incident response (oncall, alerting, outages, firefighting, postmortem)

Also see this section on my list of management resources, "Incident response".

Also see the Debugging section in this doc.

• Incident Response at Heroku
  • Described the Incident Commander role, inspired by natural disaster incident response.
  • Also in presentation: Incident Response Patterns: What we have learned at PagerDuty - Speaker Deck
• The Google SRE book's chapter about oncall
• Writing Runbook Documentation When You're An SRE
  • Playbooks “reduce stress, the mean time to repair (MTTR), and the risk of human error.”
  • Using a template can be beneficial because starting from a blank document is incredibly hard.
  • The Curse of Knowledge is a cognitive bias that occurs when someone is communicating with others and unknowingly assumes the level of knowledge of the people they are communicating with.
  • Make your content easy to glance over.
  • If a script is longer than a single line, treat it like code, and check it into a repository to be source control and potentially tested.
• Incident Review and Postmortem Best Practices, Gergely Orosz
• Computer Security Incident Handling Guide, NIST
• Incident Management Resources, Carnegie Mellon University
• Sterile flight deck rule, Wikipedia
• Shamir Secret Sharing It's 3am.
• Site Reliability Engineering and the Art of Improvisation has lots of good training ideas
  • Walkthroughs of observability toolsets
  • Decision requirements table building
  • Team knowledge elicitation
  • Asking the question, “Why do we have on-call?”
  • Spin the Wheel of Expertise!

Alerting:

• My Philosophy On Alerting
  • Pages should be urgent, important, actionable, and real.
  • Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
  • Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
  • Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
  • The further up your serving stack you go, the more distinct problems you catch in a single rule. But don't go so far you can't sufficiently distinguish what's going on.
  • If you want a quiet oncall rotation, it's imperative to have a system for dealing with things that need timely response, but are not imminently critical.
  • This classical article has now become a chapter in Google's SRE book.
• ？ The Paradox of Alerts: why deleting 90% of your paging alerts can make your systems better, and how to craft an on-call rotation that engineers are happy to join.

Postmortem

• A great example of a postmortem from Gitlab (01/31/2017) for an outage during which an engineer's action caused the irremediable loss of 6 hours of data.
• Blameless PostMortems and a Just Culture
• A list of postmortems on Github
• Google's SRE book, Postmortem chapter is excellent and includes many examples.
• Human error models and management
  • High reliability organisations — which have less than their fair share of accidents — recognise that human variability is a force to harness in averting errors, but they work hard to focus that variability and are constantly preoccupied with the possibility of failure

"Let's plan for a future where we're all as stupid as we are today."

– Dan Milstein

Example outline for a postmortem:

• エグゼクティブサマリー
  • インパクト
  • 根本的な原因
• インパクト
  • Number of impacted users
  • Lost revenue
  • 間隔
  • Team impact
• タイムライン
  • 検出
  • 解決
• 根本原因分析
  • Eg with 5 whys method
• Lessons learned
  • Things that went well
  • Things that went poorly
• Action items (include direct links to task tracking tool)
  • Tasks to improve prevention (including training)
  • Tasks to improve detection (including monitoring and alerting)
  • Tasks to improve mitigation (including emergency response)

インターネット

• インターネットはどのように機能しますか？
• How the web works
• Advice to young web developers

Interviewing

Note: this is about you as an interviewee, not as an interviewer. To check out my list of resources for interviewers, go to my engineering-management repository.

• System design interview for IT company
• Technical Interview Megarepo: study materials for SE/CS technical interviews
• How to Win the Coding Interview
• I spent 3 months applying to jobs after a coding bootcamp.これが私が学んだことです。
• Top 10 algorithms in Interview Questions
• Interactive Python coding interview challenges
• Tech Interview Handbook
• A complete computer science study plan to become a software engineer
• Interview advice that got me offers from Google, Microsoft, and Stripe
• A framework for grading your performance on programming interview problems
• Preparing for the Systems Design and Coding Interview, Gergely Orosz
• What I Learned from Doing 60+ Technical Interviews in 30 Days
• System Design Interview Guide for Senior Engineers, interviewing.io

Questions you should ask:

• Questions to ask your interviewer
• Questions to ask the company during your interview
• Interviewing the Interviewer: Questions to Uncover a Company's True Culture
• Twipped/InterviewThis: questions to ask prospective employers
• tBaxter/questions-for-employers: A big collection of useful questions to ask potential employers.

再開する：

• The Red Flags on Your Resume
• What we look for in a resume
  • We look for demonstrated expertise, not keywords
  • We look for people who get things done
  • We look for unique perspectives
  • We care about impact, not meaningless metrics
• Why you shouldn't list certifications on LinkedIn

See also the exercises section in this document.

Kubernetes

• OWASP/www-project-kubernetes-top-ten
• Kubernetes Tutorial for Beginners: Basic Concepts

Large Language Model (LLM)

• What Is ChatGPT Doing… and Why Does It Work?, Stephen Wolfram
• Embeddings: What they are and why they matter

Learning & memorizing

Learn how to learn!

• How I Rewired My Brain to Become Fluent in Math: subtitled the building blocks of understanding are memorization and repetition .
• One Sure-Fire Way to Improve Your Coding: reading code!
• Tips for learning programming
• You can increase your intelligence: 5 ways to maximize your cognitive potential: forgive the clickbait title, it's actually a good article.
• How to ask good questions, Julia Evans.
• Stop Learning Frameworks
• Learning How to Learn: powerful mental tools to help you master tough subjects
• Why books don't work, Andy Matuschak.
  • "As a medium, books are surprisingly bad at conveying knowledge, and readers mostly don't realize it."
  • "In learning sciences, we call this model “transmissionism.” It's the notion that knowledge can be directly transmitted from teacher to student, like transcribing text from one page onto another. If only!"
  • "By re-testing yourself on material you've learned over expanding intervals, you can cheaply and reliably commit huge volumes of information to long-term memory."
• Strategies, Tips, and Tricks for Anki: those advices work for any tool actually
  • Add images. Our brains are wired visually, so this helps retention.
  • Don't add things you don't understand.
  • Don't add cards memorizing entire lists.
  • Write it out. For wrong answers, I'll write it on paper. The act of writing is meditative. I really enjoy this.
  • Keep on asking yourself why? why does this work? why does it work this way? Force yourself to understand the root of a topic.
  • Cornell Method: when reading a topic, write out questions on the margins to quiz yourself.
  • Pretend you have to teach it
  • Use mnemonics phrases like PEMDAS for lists and other hard-to-remember topics.
  • Delete cards that don't make sense or you don't want to remember anymore.
• Effective learning: Twenty rules of formulating knowledge
  • Build upon the basics
  • Stick to the minimum information principle: the material you learn must be formulated in as simple way as it is
  • Cloze deletion is easy and effective: Kaleida's mission was to create a ... It finally produced one, called Script X. But it took three years
  • Graphic deletion is as good as cloze deletion
  • Avoid sets
  • Avoid enumerations
  • Combat interference - even the simplest items can be completely intractable if they are similar to other items. Use examples, context cues, vivid illustrations, refer to emotions, and to your personal life
  • Personalize and provide examples - personalization might be the most effective way of building upon other memories. Your personal life is a gold mine of facts and events to refer to. As long as you build a collection for yourself, use personalization richly to build upon well established memories
  • Provide sources - sources help you manage the learning process, updating your knowledge, judging its reliability, or importance
  • Prioritize - effective learning is all about prioritizing.
• How to Remember Anything You Really Want to Remember, Backed by Science
  • Quiz yourself
  • Summarize and share with someone else.
  • Connect what you just learned to experiences you previously had.
• How To Remember Anything Forever-ish: a comic about learning
• Get better at programming by learning how things work
• How to teach yourself hard things
• Building Your Own Personal Learning Curriculum
• Always do Extra
  • Extra is finishing those two screens, but then researching a new library for form validation that might reduce the boilerplate code.
  • Extra must be balanced against Normal Work.
  • Extra must be aligned with your Normal Work.
• Against 3X Speed
  • Lectures are most effective when they're only a component of the classroom experience
  • Learning is about spaced repetition, not binge-reading books
• The Problems with Deliberate Practice
• Why Tacit Knowledge is More Important Than Deliberate Practice
• In Praise of Memorization
  • You can't reason accurately without knowledge
  • Memorizing organized your knowledge
  • It stays with you
• Celebrate tiny learning milestones, Julia Evans.
  • Keep a brag document
  • You can do a lot "by accident"
  • Fixing a bug can be milestone
• Why writing by hand is still the best way to retain information, StackOverflow
• ？ Making Badass Developers - Kathy Sierra (Serious Pony) keynote
• How to study (with lots of cartoons from Calvin & Hobbes!)
  • Manage your time
  • Take notes in class & rewrite them at home
  • Study hard subjects first & study in a quiet place
  • Read actively & slowly, before & after class
  • Do your homework
  • Study for exams
  • Take Exams
  • Do research & write essays
  • Do I really have to do all this?
  • Are there other websites that give study hints?
• 10 Things Software Developers Should Learn about Learning
• ？ Things I Learned the Hard Way, Bryan Cantrill

About flashcards:

• Augmenting Long-term Memory
• How to write good prompts: using spaced repetition to create understanding - also includes lots of insightful research papers.
• Effective learning: Twenty rules of formulating knowledge
• Rules for Designing Precise Anki Cards
• Fernando Borretti, Effective Spaced Repetition
• Anki-fy Your Life gets into why it makes sense to invest in your memory.

About Zettelkasten and PKM (personal knowledge management): see Personal knowledge management

Richard Feynman's Learning Strategy:

1. Step 1: Continually ask "Why?”
2. Step 2: When you learn something, learn it to where you can explain it to a child.
3. Step 3: Instead of arbitrarily memorizing things, look for the explanation that makes it obvious.

Most people overestimate what they can do in 1 year and underestimate what they can do in a decade. – Bill Gates

Frankly, though, I think most people can learn a lot more than they think they can. They sell themselves short without trying. One bit of advice: it is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the details/leaves or there is nothing for them to hang onに。 - イーロン・マスク

"Experience is something you don't get until just after you need it." ― Steven Wright

教えてください、そして私は忘れます。私に教えてください、そして私は覚えています。私を巻き込み、私は学びます。 – Benjamin Franklin

Education is the kindling of a flame, not the filling of a vessel. – Socrates

That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. – Ralph Waldo Emerson

A wise man can learn more from a foolish question than a fool can learn from a wise answer. – Bruce Lee

A lecture has been well described as the process whereby the notes of the teacher become the notes of the student without passing through the mind of either. — Mortimer Adler

Fools learn from experience. I prefer to learn from the experience of others. — Bismark

Licenses (legal)

• Software Licenses in Plain English

Linux (system management)

• Welcome to Linux command line for you and me!
• Linux Performance, Brendan Gregg

Low-code/no-code

• How Levels.fyi scaled to millions of users with Google Sheets as a backend

Low-level, assembly

• Back to Basics, Joel Spolsky. Explains why learning low level programming is important.
  • I think that some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels.
• What's in a Linux executable?
• The Elements of Computing Systems: building a modern computer from first principles (nand2tetris).
• Old pattern powering modern tech
• Demystifying bitwise operations, a gentle C tutorial
• Understanding the Power of Bitwise Operators. No math needed
• Memory Allocation (an interactive article)
• Why does 0.1 + 0.2 = 0.30000000000000004?, Julia Evans (about floating point)
• Putting the "You" in CPU
• x86-64 Assembly Language Programming with Ubuntu

Machine learning/AI

• Transformers from Scratch

数学

• ？ Statistics for Hackers

マーケティング

• goabstract/Marketing-for-Engineers

ネットワーク

• The Great Confusion About URIs
  • A URI is a string of characters that identifies a resource. Its syntax is <scheme>:<authority><path>?<query>#<fragment> , where only <scheme> and <path> are mandatory. URL and URN are URIs.
  • A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. Eg mailto:[email protected] .
  • A URN is a string of characters that uniquely identifies a resource. Its syntax is urn:<namespace identifier>:<namespace specific string> . Eg urn:isbn:9780062301239
• Everything you need to know about DNS
• Examples of Great URL Design
• Four Cool URLs - Alex Pounds' Blog

Observability (monitoring, logging, exception handling)

See also: Site Reliability Engineering (SRE)

ロギング

• Do not log dwells on some logging antipatterns.
  • Logging does not make much sense in monitoring and error tracking. Use better tools instead: error and business monitorings with alerts, versioning, event sourcing.
  • Logging adds significant complexity to your architecture. And it requires more testing. Use architecture patterns that will make logging an explicit part of your contracts
  • Logging is a whole infrastructure subsystem on its own. And quite a complex one. You will have to maintain it or to outsource this job to existing logging services
• Lies My Parents Told Me (About Logs)
  • Logs are cheap
  • I can run it better myself
  • Leveled logging is a great way to separate information
  • Logs are basically the same as events
  • A standard logging format is good enough
• Logging - OWASP Cheat Sheet Series
• The Audit Log Wall of Shame: list of vendors that don't prioritize high-quality, widely-available audit logs for security and operations teams.
• Guide on Structured Logs

Error/exception handling

• Error handling antipatterns in this repo.
• Writing Helpful Error Messages, Google Developers' course on Technical Writing
  • Explain the problem
  • Explain the solution
  • Write clearly

メトリック

• Meaningful availability
  • A good availability metric should be meaningful, proportional, and actionable. By "meaningful" we mean that it should capture what users experience. By "proportional" we mean that a change in the metric should be proportional to the change in user-perceived availability. By "actionable" we mean that the metric should give system owners insight into why availability for a period was low. This paper shows that none of the commonly used metrics satisfy these requirements…
• ？ Meaningful Availability paper.
  • This paper presents and evaluates a novel availability metric: windowed user-uptime

監視

• Google, Site Reliability Engineering, Monitoring Distributed Systems
  • Alerting on SLOs
• PagerDuty, Monitoring Business Metrics and Refining Outage Response
• ？ crazy-canux/awesome-monitoring: monitoring tools for operations.
• Monitoring in the time of Cloud Native
• How to Monitor the SRE Golden Signals
  • From the Google SRE book: Latency, Traffic, Errors, and Saturation
  • USE Method (from Brendan Gregg): Utilization, Saturation, and Errors
  • RED Method (from Tom Wilkie): Rate, Errors, and Duration
• Simple Anomaly Detection Using Plain SQL
• How percentile approximation works (and why it's more useful than averages)
• Implementing health checks
• IETF RFC Health Check Response Format for HTTP APIs

オープンソース

• Non-code contributions are the secret to open source success

Operating system (OS)

• The Linux Programming Interface: A Linux and UNIX System Programming Handbook: already mentioned above.
• Modern Operating Systems, Andrew Tanenbaum, Herbert Bos (not read)
• Operating Systems: Three Easy Pieces (free book, not read)
• Linux Kernel Development, Robert Love. A very complete introduction to developing within the Linux Kernel.
• The 10 Operating System Concepts Software Developers Need to Remember
• Play with xv6 on MIT 6.828
• macOS Internals

Over-engineering

• 10 modern software over-engineering mistakes
• A good example of over-engineering: the Juicero press (April 2017)
• You Are Not Google: the UNPHAT method to avoid cargo cult.
  • Don't even start considering solutions until you Understand the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
  • eNumerate multiple candidate solutions. Don't just start prodding at your favorite!
• 熟考の上
  • 1st poison: education.
  • 2nd poison: marketing.
  • 3rd poison: ego
  • Solution: Stop trying to connect all the dots ahead of time. Embrace uncertainty and start doing.
• Don't Let Architecture Astronauts Scare You, Joel
  • Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
  • Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it's interesting because it's peer to peer, completely missing the point that it's interesting because you can type the name of a song and listen to it right away.

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

— John Gall, General systemantics, an essay on how systems work, and especially how they fail..., 1975 (this quote is sometime referred as "Galls' law")

"Software engineering is what happens to programming when you add time and other programmers."

— Rob Pike, Go at Google: Language Design in the Service of Software Engineering

You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

- スティーブジョブズ

パフォーマンス

• Numbers Everyone Should Know
• Latency numbers every programmer should know
• Rob Pike's 5 Rules of Programming
  • You can't tell where a program is going to spend its time.
  • 測定
  • Fancy algorithms are slow when n is small, and n is usually small.
  • Fancy algorithms are buggier than simple ones
  • Data dominates.
• Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust: a great way to learn about measuring performance.
• The Mathematical Hacker
• Four Kinds of Optimisation

Personal knowledge management (PKM)

• Zettelkasten Method
• How to build a second brain as a software developer
• Notes Against Note-Taking Systems
  • An interesting contrarian take!
  • I am waiting for any evidence that our most provocative thinkers and writers are those who rely on elaborate, systematic note-taking systems.
  • I am seeing evidence that people taught knowledge management for its own sake produce unexciting work.
• MaggieAppleton/digital-gardeners
• Notes apps are where ideas go to die.そして、それは良いことです。

Personal productivity

Check out this section on my list of management resources, "Personal productivity".

視点

• At 31, I have just weeks to live. Here's what I want to pass on
  • First, the importance of gratitude.
  • Second, a life, if lived well, is long enough.
  • Third, it's important to let yourself be vulnerable and connect to others.
  • Fourth, do something for others.
  • Fifth, protect the planet.
• Life Is Not Short
  • "The most surprising thing is that you wouldn't let anyone steal your property, but you consistently let people steal your time, which is infinitely more valuable." — Seneca

プライバシー

• Privacy Enhancing Technologies: An Introduction for Technologists, Katharine Jarmul, MartinFowler.com

問題解決

• Dealing with Hard Problems
• Invert, always, invert
  • Define the problem - what is it that you're trying to achieve?
  • Invert it - what would guarantee the failure to achieve this outcome?
  • Finally, consider solutions to avoid this failure
• ？ Hammock Driven Development, Rick Hickey
  • A classic talk on problem solving.

Product management for software engineers

See the Product management section on my entrepreneurship-resources list of resources.

• Checkout this newsletter produced by Posthog: Product for Engineers

プロジェクト管理

See the Project management section on my engineering-management list of resources.

Programming languages

I would recommend learning:

• JavaScript and maybe another interpreted language (Python, Ruby, etc.). Interpreted languages are useful for quick one-off automation scripts, and fastest to write for interviews. JavaScript is ubiquitous.
• A compiled language (Java, C, C++...).
  • Learn c in Y Minutes
• A more recent language to see where the industry is going (as of writing, Go, Swift, Rust, Elixir...).
• A language that has first-class support for functional programming (Haskell, Scala, Clojure...).

A bit more reading:

• A brief, incomplete, mostly wrong history of programming languages
• 種類
• Resources To Help You To Create Programming Languages
• Effective Programs - 10 Years of Clojure ?, Rich Hickey. The author of Clojure reflects on his programming experience and explains the rationale behind some of Clojure's key design decisions.
• Learn more programming languages, even if you won't use them, Thorsten Ball
  • These new perspectives, these ideas and patterns — they linger, they stay with you, even if you end up in another language. And that is powerful enough to keep on learning new languages, because one of the best things that can happen to you when you're trying to solve a problem is a change of perspective.
• Programming Language Checklist: a fun take on "so you want to build your own language?"
• Static vs. dynamic languages: a literature review
• Polyglot Programming and the Benefits of Mastering Several Languages
• It's not what programming languages do, it's what they shepherd you to
• Ask HN: What do you code when learning a new language/framework?
• The seven programming ur-languages: ALGOL, Lisp, ML, Self, Forth, APL, Prolog
• Lua: The Little Language That Could
• The Montréal Effect: Why Programming Languages Need a Style Czar
• TodePond/DreamBerd: a perfect programming language

言語には2種類しかありません。人々が不平を言う人と誰も使用していない言語です。

-- Bjarne Stroustrup (C++ creator)

List of resources:

• Great Works in Programming Languages

Python

For Python check out my professional Python education repository.

JavaScript

In this repository: check ./training/front-end/

JavaScript is such a pervasive language that it's almost required learning.

• mbeaudru/modern-js-cheatsheet: cheatsheet for the JavaScript knowledge you will frequently encounter in modern projects.
• javascript-tutorial: comprehensive JavaScript guide with simple but detailed explanantions. Available in several languages.
• 30 Days of JavaScript: 30 days of JavaScript programming challenge is a step-by-step guide to learn JavaScript programming language in 30 days.
• Unleash JavaScript's Potential with Functional Programming

ごみ収集

• A Guide to the Go Garbage Collector: a very insightful guide about Go's GC

プログラミングパラダイム

• Imperative vs Declarative Programming, Tyler McGinnis.
  • I draw the line between declarative and non-declarative at whether you can trace the code as it runs. Regex is 100% declarative, as it's untraceable while the pattern is being executed.
• ？ Imperative vs Declarative Programming

Public speaking (presenting)

• Speaking for hackers

読む

• Papers we love: papers from the computer science community to read and discuss. Can be a good source of inspiration of solving your design problems.
• The morning paper: one CS research paper explained every morning.
• The Complete Guide to Effective Reading
• The benefits of note-taking by hand
• The Art of Reading More Effectively and Efficiently
• You should be reading academic computer science papers, Stack Overflow Blog
• How to Remember What You Read
  • メモを取ってください
  • 集中し続けてください
  • Mark up the book
  • Make mental links
  • Quit books
• Writing summaries is more important than reading more books
  • In 1-2 sentences, what is the book about as a whole?
  • What are the 3-4 central questions it tries to answer?
  • Summarize the answers in one paragraph each.
  • What are the most important things you have learned personally?
  • There was an interesting contrarian take in the Hacker News thread: "Once I relaxed and decided, 'If the stuff in this book is good enough, my brain will keep it FOR me' both my satisfaction AND utility of books increased dramatically."
• You Are What You Read, Even If You Don't Always Remember It
  • "I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me.", Ralp Waldo Emerson

リファクタリング

• The Rule of Three, Coding Horror
  • Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived.
  • It is three times as difficult to build reusable components as single use components.
  • A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
• Refactor vs. Rewrite
• Tripping over the potholes in too many libraries

正規表現

• The Best Regex Trick
• regex101: build, test, and debug regex

Releasing & deploying

• How we release so frequently
• How to deploy software, Zach Holman
• BlueGreenDeployment, Martin Fowler
• Move fast and break nothing, Zach Holman
• ？ Move fast and don't break things, Google
• Shipping to Production, The Pragmatic Programmer

バージョン化

• SemVer - Semantic Versioning
• CalVer - Calendar Versioning
• Semantic Versioning Will Not Save You
• Version numbers: how to use them?

チェックリスト

• Production Readiness Checklist, Gruntwork
• Checklist: what had to be done before deploying microservices to production
• Things end users care about but programmers don't: includes colors, formatting, themes, integrations, UX, compatibility, operations.

Feature flags

• Flipping out, Flickr. One of the first articles about feature flags.
• Feature Flags, Toggles, Controls, a website documenting feature flags, from Launch Darkly.
• Feature Toggles (aka Feature Flags), Pete Hodgson, martinFowler.com. Comprehensive article on the topic.
  • Deliver new functionality to users rapidly but safely
  • Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.
  • Experiment Toggles are used to perform multivariate or A/B testing.
  • Ops Toggles control operational aspects of our system's behavior.
  • Permissioning Toggles change the features or product experience that certain users receive.
  • Static vs dynamic toggles
  • Long-lived toggles vs transient toggles
  • Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible.
• Feature Flags Best Practices: Release Management, LaunchDarkly
• How we ship code faster and safer with feature flags, Github.
• Flipr: Making Changes Quickly and Safely at Scale, Uber
• Feature flags are ruining your codebase

Testing in production

• Why We Leverage Multi-tenancy in Uber's Microservice Architecture
• Developing in Production
  • Complex systems have emergent behavior, producing epiphenomenon that only appears with sufficient scale.
  • Wood's theorem: As the complexity of a system increases, the accuracy of any single agent's own model of that system decreases rapidly.
  • The more tools and code that you add to create elements in a system, the harder it is to replicate an environment encompassing those tools and code.
  • At the core of testing in production is the idea of splitting deployments (of artifacts) from releases (of features).
• Testing in Production: the hard parts, Cindy Sridharan
  • The whole point of [actual] distributed systems engineering is you assume you're going to fail at some point in time and you design the system in such a way that the damage, at each point is minimized, that recovery is quick, and that the risk is acceptably balanced with cost.
  • How can you cut the blast radius for a similar event in half?
    • Differentiate between deployment (0 risk) and release
    • Build a deploy-observe-release pipeline
    • Make incremental rollouts the norm (canaries, %-based rollouts, etc.)
    • Test configuration changes just like you test code
    • Default to roll back, avoid fixing forward (slow!)
    • Eliminate gray failures - prefer crashing to degrading in certain cases
    • Prefer loosely coupled services at the expense of latency or correctness
    • Use poison tasters (isolate handling of client input)
    • Implement per-request-class backpressure
    • Have proper visibility from a client/end-user standpoint (client-side metrics)
• Testing in Production, the safe way
• Multi-Tenancy in a Microservice Architecture

信頼性

See also System architecture

本：本：

• Site Reliability Engineering
  • Written by members of Google's SRE team, with a comprehensive analysis of the entire software lifecycle - how to build, deploy, monitor, and maintain large scale systems.

引用：

Quality is a snapshot at the start of life and reliability is a motion picture of the day-by-day operation. – NIST

Reliability is the one feature every customer users. -- An auth0 SRE.

記事：

• I already mentioned the book Release it!その上。 There's also a presentation from the author.
• Service Recovery: Rolling Back vs. Forward Fixing
• How Complex Systems Fail
  • Catastrophe requires multiple failures – single point failures are not enough.
  • Complex systems contain changing mixtures of failures latent within them.
  • Post-accident attribution to a 'root cause' is fundamentally wrong.
  • Hindsight biases post-accident assessments of human performance.
  • Safety is a characteristic of systems and not of their components
  • Failure free operations require experience with failure.
• Systems that defy detailed understanding
  • Focus effort on systems-level failure, instead of the individual component failure.
  • Invest in sophisticated observability tools, aiming to increase the number of questions we can ask without deploying custom code
• Operating a Large, Distributed System in a Reliable Way: Practices I Learned, Gergely Orosz.
  • A good summary of processes to implement.
• Production Oriented Development
  • Code in production is the only code that matters
  • Engineers are the subject matter experts for the code they write and should be responsible for operating it in production.
  • Buy Almost Always Beats Build
  • Make Deploys Easy
  • Trust the People Closest to the Knives
  • QA Gates Make Quality Worse
  • Boring Technology is Great.
  • Non-Production Environments Have Diminishing Returns
  • Things Will Always Break
• ？ High Reliability Infrastructure migrations, Julia Evans.
• Appendix F: Personal Observations on the Reliability of the Shuttle, Richard Feynman
• Lessons learned from two decades of Site Reliability Engineering

リソース：

• ？ dastergon/awesome-sre
• ？ upgundecha/howtheysre: a curated collection of publicly available resources on SRE at technology and tech-savvy organizations

Resiliency

• ？ The Walking Dead - A Survival Guide to Resilient Applications
• ？ Defensive Programming & Resilient systems in Real World (TM)
• ？ Full Stack Fest: Architectural Patterns of Resilient Distributed Systems
• ？ The 7 quests of resilient software design
• ？ Resilience engineering papers: comprehensive list of resources on resilience engineering
• MTTR is more important than MTBF (for most types of F) (also as a presentation)

検索

• What every software engineer should know about search

安全

• Penetration Testing: A Hands-On Introduction to Hacking, Georgia Weidman
• Penetration Testing Tools Cheat Sheet
• A practical guide to securing macOS
• Web Application Security Guide/Checklist
• Reckon you've seen some stupid security things?: everything not to do.
• Checklist of the most important security countermeasures when designing, testing, and releasing your API
• OWASP Cheat Sheet Series: a series of cheat sheets about various security topics.
  • Docker Security
  • How to improve your Docker containers security
• Secure by Design, a book review by Henrik Warne.
  • There is a big overlap between secure code and good software design
  • Every domain value should instead be represented by a domain primitive.
  • External input needs to be validated before it is used in the system, in the following order: origin, size, lexical content, syntax, semantics.
  • Entities should be consistent at creation, have limited operation, shouldn't be sharing mutable objects.
  • Three Rs to do every few hours: rotate secrets automatically, repave servers and applications (redeploy on clean footprint), repair vulnerable.
  • Don't use exceptions for the control flow.
• OWASP Top Ten Web Application Security Risks
  • How to start an AppSec program with the OWASP Top 10
• ukncsc/zero-trust-architecture: Principles to help you design and deploy a zero trust architecture
• ？ Minimum Viable Security
• The Open Software Assurance Maturity Model
• Security by Obscurity is Underrated
• Don't Wanna Pay Ransom Gangs? Test Your Backups, Krebs on Security
• The Beginner's Guide to Passwords
• The Password Game
• Learnings from 5 years of tech startup code audits
• API Tokens: A Tedious Survey: don't use JWT.
• The Six Dumbest Ideas in Computer Security

Training for developers:

• Hacksplaining
• Codebashing
• OWASP Security Knowledge Framework
• PagerDuty Security Training
• Gruyere: Web Application Exploits and Defenses

List of resources:

• ？ meirwah/awesome-incident-response: tools for incident response
• ？ Starting Up Security
• ？ decalage2/awesome-security-hardening: security hardening guides, tools and other resources

Shell (command line)

• The case for bash
• ？ alebcay/awesome-shell
• ？ dylanaraps/pure-bash-bible: pure bash alternatives to external processes.
• The Bash Hackers Wiki provides a gentler way to learn about bash than its manages.
• Awk in 20 Minutes
• ？ Linux Productivity Tools
• jlevy/the-art-of-command-line: master the command line, in one page must read
• Minimal safe Bash script template
• Command Line Interface Guidelines
• The Linux Commands Handbook
• How to write idempotent Bash scripts
• Learn bash by playing an adventure
• Effective Shell
• Computing from the Command Line
• What helps people get comfortable on the command line?, Julia Evans
• 6 Techniques I Use to Create a Great User Experience for Shell Scripts

SQL

• SQL styleguide
• Best practices for writing SQL queries
• Practical SQL for Data Analysis
• Reasons why SELECT * is bad for SQL performance
• Animate SQL
• Lost at SQL, an SQL learning game
• Joins 13 Ways
• spandanb/learndb-py: learn database internals by implementing it from scratch.
• SQL for the Weary

システム管理

• ？ kahun/awesome-sysadmin: a curated list of amazingly awesome open source sysadmin resources

システムアーキテクチャ

See also Reliability, Scalability

Reading lists:

• ？ donnemartin/system-design-primer: learn how to design large scale systems. Prep for the system design interview.
• ？ A Distributed Systems Reading List
• ？ Foundational distributed systems papers
• ？ Services Engineering Reading List
• ？ System Design Cheatsheet
• karanpratapsingh/system-design: learn how to design systems at scale and prepare for system design interviews
• A Distributed Systems Reading List

Blogs:

• High Scalability: great blog about system architecture, its weekly review article are packed with numerous insights and interesting technology reviews. Checkout the all-times favorites.

本：本：

• Building Microservices, Sam Newman (quite complete discussion of microservices)
• Designing Data-Intensive Applications

記事：

• 6 Rules of thumb to build blazing fast web server applications

• The twelve-factor app

• Introduction to architecting systems for scale

• The Log: What every software engineer should know about real-time data's unifying abstraction: one of those classical articles that everyone should read.

• Turning the database outside-out with Apache Samza

• Fallacies of distributed computing, Wikipedia

• The biggest thing Amazon got right: the platform

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Monitoring and QA are the same thing.

• Building Services at Airbnb, part 3

  • Resilience is a Requirement, Not a Feature

• Building Services at Airbnb, part 4

  • Building Schema Based Testing Infrastructure for service development

• Patterns of Distributed Systems, MartinFowler.com

• ConwaysLaw, MartinFowler.com (regarding organization, check out my engineering-management list).

• The C4 model for visualising software architecture

• If Architects had to work like Programmers

Architecture patterns

• BFF (backend for frontend)
  • Backends For Frontends
• Circuit breaker
• Rate limiter algorithms (and their implementation)
• Load Balancing: a visual exploration of load balancing algos
• Good Retry, Bad Retry: An Incident Story: insightful, well-written story about retries, circuit breakers, deadline, etc.

Microservices/splitting a monolith

• Service oriented architecture: scaling the Uber engineering codebase as we grow
• Don't start with microservices in production – monoliths are your friend
• Deep lessons from Google And EBay on building ecosystems of microservices
• Introducing domain-oriented microservice architecture, Uber
  • Instead of orienting around single microservices, we oriented around collections of related microservices. We call these domains.
  • In small organizations, the operational benefit likely does not offset the increase in architectural complexity.
• Best Practices for Building a Microservice Architecture
• ？ Avoid Building a Distributed Monolith
• ？ Breaking down the monolith
• Monoliths are the future
  • "We're gonna break it up and somehow find the engineering discipline we never had in the first place."
• 12 Ways to Prepare your Monolith Before Transitioning to Microservices
• Death by a thousand microservices
  • Microservices

スケーラビリティ

See also: Reliability, System architecture

• Scalable web architecture and distributed systems
• Scalability Rules: 50 Principles for Scaling Web Sites (presentation)
• Scaling to 100k Users, Alex Pareto. The basics of getting from 1 to 100k users.

Site Reliability Engineering (SRE)

See: Reliability

Technical debt

• TechnicalDebt, Martin Fowler.
• Fixing Technical Debt with an Engineering Allocation Framework
  • You don't need to stop shipping features to fix technical debt
  • Communicate the business value
• Ur-Technical Debt
  • Today, any code that a developer dislikes is branded as technical debt.
  • Ward Cunningham invented the debt metaphor to explain to his manager that building iteratively gave them working code faster, much like borrowing money to start a project, but that it was essential to keep paying down the debt, otherwise the interest payments would grind the project to a halt.
  • Ur-technical debt is generally not detectable by static analysis.

テスト

• ️ Testing strategies in a microservices architecture (Martin Fowler) is an awesome resources explaining how to test a service properly.
• ？ Testing Distributed Systems

Why test:

• Why bother writing tests at all?, Dave Cheney. A good intro to the topic.
  • Even if you don't, someone will test your software
  • The majority of testing should be performed by development teams
  • Manual testing should not be the majority of your testing because manual testing is O(n)
  • Tests are the critical component that ensure you can always ship your master branch
  • Tests lock in behaviour
  • Tests give you confidence to change someone else's code

How to test:

• A quick puzzle to test your problem solving... and a great way to learn about confirmation bias and why you're mostly writing positive test cases.
• Testing is not for beginners: why learning to test is hard. This shouldn't demotivate you though!
• Arrange-act-assert: a pattern for writing good tests
• Test smarter, not harder

Test pyramid:

• The test pyramid, Martin Fowler
• Eradicating non-determinism in tests, Martin Fowler
• The practical test pyramid, MartinFowler.com
  • Be clear about the different types of tests that you want to write. Agree on the naming in your team and find consensus on the scope of each type of test.
  • Every single test in your test suite is additional baggage and doesn't come for free.
  • Test code is as important as production code.
• Software testing anti-patterns, Kostis Kapelonis.
• Write tests. Not too many. Mostly integration. for a contrarian take about unit testing
• ？ Unit test 2, Integration test: 0
• Testing in the Twenties
• Google Testing Blog: Test Sizes
• Pyramid or Crab? Find a testing strategy that fits, web.dev

End-to-end tests:

• Just say no to more end-to-end tests, Google Testing Blog
• End-to-end testing considered harmful

ツール

• DevDocs API Documentation: a repository for multiple API docs (see also Dash for macOS).
• DevChecklist: a collaborative space for sharing checklists that help ensure software quality
• ？ Free for developers: list of free tiers for developments tools and services
• Choose Boring Technology
• Ask HN: Best dev tool pitches of all time?
• A list of /uses pages detailing developer setups, gear, software and configs

The future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age — Lindy's Law

タイプシステム

• Counterexamples in Type Systems: a library of runtime issues that weren't caught by the type system

タイポグラフィ

• Butterick's Practical Typography
• Typography for Lawyers
• Quick guide to web typography for developers · OlegWock
• Features of your font you had no idea about

Version control (Git)

Learning Git, courses and books:

• Git Book
• Git from the inside out
• Git Tutorials and Training, Atlassian
• Git Immersion
• A Visual Git Reference (a bit more advanced)
• Think Like (a) Git
• Git's database internals I: packed object store: an insightful deep dive from Github
• Oh My Git!: a game to learn git

Cheat sheets:

• Git Cheat Sheet
• git-tips
• Oh Shit, Git!?!

More specific topics:

• 従来のコミット
• Git Merge vs. Rebase: What's the Diff?
• ？ Story-telling with Git rebase
• ？ Git Rebase vs. Merge
• ？ 10 Git Anti Patterns You Should be Aware of
• Learn Git Branching: an interactive game
• Fix conflicts only once with git rerere
• Monorepo Explained
• How to Write a Git Commit Message
• git-worktree: manage multiple working trees attached to the same repository.

Work ethics, productivity & work/life balance

Check out this section on my list of engineering-management resources, "Personal productivity".

Web開発

In this repository: check training/web-dev/ and ./training/front-end/

Learning guide and resources:

• grab/front-end-guide: a study guide and introduction to the modern front end stack.
• Front-End Developer Handbook 2019, Cody Lindley
• A Directory of design and front-end resources
• ？ codingknite/frontend-development: a list of resources for frontend development

トピック：

• 136 facts every web dev should know
• Maintainable CSS
• Things you forgot (or never knew) because of React
• Checklist - The A11Y Project for accessibility
• DevTools Tips
• 67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
• Client-Side Architecture Basics
• Web Browser Engineering: this book explains how to build a basic but complete web browser, from networking to JavaScript, in a couple thousand lines of Python.

Writing (communication, blogging)

➡️ See also my engineering-management list

• Undervalued Software Engineering Skills: Writing Well
  • From the HN discussion: "Writing a couple of pages of design docs or an Amazon-style 6 pager or whatever might take a few days of work, but can save weeks or more of wasted implementation time when you realise your system design was flawed or it doesn't address any real user needs."
• Sell Yourself Sell Your Work
  • If you've done great work, if you've produced superb software or fixed a fault with an aeroplane or investigated a problem, without telling anyone you may as well not have bothered.
• The Writing Well Handbook
  • Ideas — Identify what to write about
  • First Drafts — Generate insights on your topic
  • Rewriting — Rewrite for clarity, intrigue, and succinctness
  • Style — Rewrite for style and flow
  • Practicing — Improve as a writer
• Write Simply, Paul Graham
• Writing is Thinking: Learning to Write with Confidence
• It's time to start writing explains why Jeff Bezos banned PowerPoint at Amazon.
  • The reason writing a good 4 page memo is harder than "writing" a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what, and how things are related.
  • Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.
• Programming and Writing, Antirez
• Writing one sentence per line
• Ask HN: How to level up your technical writing?. Lots of great resources.
• Patterns in confusing explanations, Julia Evans
• Technical Writing for Developers
• Some blogging myths, Julia Evans
• George Orwell's Six Rules for Writing
  • Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  • Never use a long word where a short one will do.
  • If it is possible to cut a word out, always cut it out.
  • Never use the passive where you can use the active.
  • Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
  • Break any of these rules sooner than say anything outright barbarous.
• Blog Writing for Developers

Guides & classes about technical writing:

• Documentation Guide — Write the Docs
  • 原則
  • Style guides
  • Docs as code
  • Markup languages
  • ツール
• Technical Writing One introduction, Google
  • 文法
  • Active voice
  • Clear & short sentences

If you're overthinking, write. If you're underthinking, read. – @AlexAndBooks_

Resources & inspiration for presentations

• https://twitter.com/devops_borat
• https://speakerdeck.com/
• Dilbert
• Calvin & Hobbes (search engine)
• https://twitter.com/_workchronicles

Keeping up-to-date

Website and RSS feeds (I use Feedly):

• Hacker News ️
• VentureBeat
• High Scalability: see above

安全：

• セキュリティに関するシュナイヤー
• Krebs on Security
• ハッカーニュース

Newsletters:

• Bytes (JavaScript)
• PyCoders (Python)
• ポストログ

Blogs:

• kilimchoi/engineering-blogs

概念

用語集

• bdd
• CAP theorem
• DDD
• ドライ
• EAV
• 把握する
• キス
• Make it run, make it right, make it fast
• OOP
• 固体
• TDD
• Two Generals' Problem
• YAGNI

My other lists

• engineering-management
• entrepreneurship-resources
• professional-programming
• python-education