professional-programming - 好奇心旺盛なソフトウェアエンジニアのための学習リソースのコレクション

(A collection of learning resources for curious software engineers)

Created at: 2015-11-07 13:07:52
Language: Python
URL: https://github.com/charlax/professional-programming
License: MIT

目次

プロフェッショナルプログラミング - このリストについて

木を切り倒すのに6時間与えてください、そして私は最初の4時間を斧を研ぐのに費やします。(エイブラハムリンカーン)

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

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

このページは包括的なものではありません。私はそれを軽く保ち、圧倒しすぎないようにしています。記事の選択は意見があります。

項目：

  • 🧰 : リソースのリスト
  • 📖：本
  • 🎞 : 映像/動画抽出/動画/トーク
  • 🏙 : スライド/プレゼンテーション
  • ⭐️ : 必読

このリストへの貢献

PRを開いて貢献してください!私はすべてを追加するつもりはありません:上記のように、私はリストを簡潔に保とうとしています。

必読の本

私はこれらの本が信じられないほど刺激的であることに気づきました:

次のような無料の本がいくつかあります。

必読の記事

  • 新しいソフトウェアエンジニアのための実用的なアドバイス
  • シニアエンジニアであることについて
  • ソフトウェア開発で学んだ教訓:何年にもわたる苦労して得た教訓をすべて1つの短い記事で提供する記事の1つ。必読。
  • 私が苦労して学んだこと
    • 最初に仕様、次にコード
    • テストはより良いAPIを作る
    • 未来思考は未来のゴミです
    • ドキュメンテーションはあなたの未来の自分へのラブレターです
    • 何もしないよりもアプリケーションをクラッシュさせる方が良い場合があります
    • カーゴカルトを理解し、近づかないでください
    • 「仕事に適したツール」は、議題を推進することだけです
    • 基本的な関数型プログラミングを学ぶ
    • 常に日付にタイムゾーンを使用する
    • 常にUTF-8を使用する
    • ライブラリの作成
    • 監視することを学ぶ
    • 明示的は暗黙的よりも優れています
    • 企業はスペシャリストを探していますが、ジェネラリストをより長く維持します
    • ユーザーデータを処理する最も安全な方法は、それをキャプチャしないことです
    • 停止する時間になったら、停止する時間です
    • コードの使用には責任があります
    • そうでないときに「完了しました」と言わないでください
    • 人々があなたにどのように反応するかに注意を払う
    • マイクロアグレッションに注意してください
    • 「私が知らないこと」のリストを保持する
  • あなたが優れたプログラマーであることのしるし
  • あなたが悪いプログラマーであるという兆候
  • ジュニア開発者として学ばなかった7つの絶対的な真実
    • キャリアの早い段階で、自分でコーディングするよりも、1年間で支援チームで10倍多く学ぶことができます
    • すべての企業に問題があり、すべての企業に技術的負債があります。
    • 実際の経験が不足しているトピックについて過度に意見を述べることはかなり傲慢です。
    • 多くの会議の講演では、実際のシナリオではなく概念実証が取り上げられています。
    • レガシーを扱うことは完全に正常です。
    • アーキテクチャは、つまらないことよりも重要です。
    • 必要に応じて、ドキュメントよりも自動化に焦点を当てます。
    • 技術的負債があることは健全です。
    • シニアエンジニアは、プログラミング以外にも多くのスキルを身に付ける必要があります。
    • 私たちは皆、いくつかの分野ではまだジュニアです。
  • 優れたソフトウェアを構築する方法
    • 基本的なエンジニアリングプラクティスの優れた高レベルの要約。
    • 悪いソフトウェアの根本原因は、特定のエンジニアリングの選択とはあまり関係がなく、開発プロジェクトの管理方法に関係しています。
    • プラトニックに良いエンジニアリングのようなものはありません:それはあなたのニーズとあなたが遭遇する実際的な問題に依存します。
    • ソフトウェアは静的な製品としてではなく、開発チームの集合的な理解の生きた現れとして扱われるべきです。
    • ソフトウェアプロジェクトは、小さすぎるために失敗することはめったにありません。彼らは大きくなりすぎるので失敗します。
    • 問題文を装った官僚的な目標に注意してください。私たちの最終目標が市民の生活をより良くすることであるならば、私たちは彼らの生活を悪化させているものを明確に認識する必要があります。
    • ソフトウェアの構築は、障害を回避することではありません。それは、良いものを構築するために必要な情報を取得するために、できるだけ早く戦略的に失敗することです。

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

公理のリスト:

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

コース

トピック

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

その他のリソース:

正直に言うと、アルゴリズムはかなりドライなトピックになる可能性があります。このクォーラの質問には、次のようなおかしな学習の選択肢がリストされています。

実装例:

API設計と開発

一般的な REST コンテンツ:

ガイドラインの例:

より具体的なトピック:

態度、習慣、考え方

  • マスタリングプログラミング、ケントベック。
  • 熟練したプログラマーの特徴
  • プログラミングのタオ:プログラミングに関する一連のたとえ話。
  • 所有権を取得することは、あなたが望むものを手に入れるための最も効果的な方法です
  • より良い開発者になるための時間を見つける
  • 1日10分:アレックス・アレインが毎日10分書くことで、200時間以内に本を書いた方法。
  • ソフトウェアエンジニアの世話と給餌(または、エンジニアが不機嫌になる理由)
    • ソフトウェア、プロダクトマネージャー、デザイナー、ソフトウェアエンジニアの三位一体では、エンジニアだけが創造的な心をオフにして、ただ生産することが期待されています。
    • エンジニアとプロダクトマネージャーの両方が、製品の仕様や要件がイケアの家具マニュアルと同等であると誤って考える傾向があります。
    • これは、エンジニアを不機嫌にする最大のことの1つであり、常に優先順位がシフトしています。
    • 多くのエンジニアは、プロダクトマネージャーが気が変わったと不平を言うでしょうが、時間の見積もりでそれを説明する人はほとんどいません。
    • コンピュータサイエンスプログラムは、業界で直面するタスクに備えるためのものではありません。
    • 使用できる数を超えるエンジニアがいる場合、エンジニアリング時間は開発から離れ、計画、同期、および調整に費やされます。
    • クリエイティブなプロセスにエンジニアを巻き込む
    • エンジニアに創造性を発揮する機会を与えます。
    • 休暇を奨励する。
    • コードを作成しましょう
    • 感謝の気持ちを表す
  • 製品志向のソフトウェアエンジニア、ゲルゲリー・オロシュ
    • 優れた製品エンジニアは、最小限の愛すべき製品には適切な深さが必要であることを知っています
    • 製品志向のエンジニアは、エッジケースを迅速にマッピングし、それらの作業を削減する方法を考えます。
    • ユーザー調査とカスタマーサポートに従事する
    • 十分に裏付けられた製品の提案をテーブルに持ち込む
    • 製品/エンジニアリングのトレードオフを提供
  • 40年からの40の教訓、スティーブ・シュラフマン
    • 最も重要なことを進歩させたいのなら、誰を失望させるかを決める必要があります。それは避けられません。
    • あなたができる最善の投資はあなた自身の教育です。学習をやめないでください。あなたができる2番目に良い投資は、本物で有意義な相互作用を通じてネットワークを構築することです。それはあなたが知っていることであり、あなたが知っている人です。
    • 求めていないものや積極的に求めていないものは決して得られません。頑張れ!
    • それはトンネルの終わりの光についてではありません。トンネルです。毎日現れて、プロセスを楽しんでください。
    • 優れたチームメイトは、常に自分の利益よりも組織とその目的を優先します。
    • あなたのスポットを選んでください。私たちには限られた時間があり、私たちの脳はそれほど多くを処理することができません。焦点が重要です。賢明に選択してください。
    • すべての人が何かに苦労している可能性があります。親切にしてください。力になる。
  • コーディング、エゴ、注意について
    • 初心者の心は絶対的な知識が無限であり、したがってスコアを維持することは時間の無駄であるという事実を受け入れます。
    • 習熟とは、知識の蓄積ではなく、単に勢いの蓄積です。
    • エゴの気晴らしに対処することで、問題解決プロセスを愛することを学びました。それは私に学習プロセスを愛し、尊重することを教えてくれました。その結果、私はより生産的です。私はあまり不安ではありません。僕はより良いチームメイトだ。私はより良い友人であり、より良い思想家です。
  • 固定と成長:私たちの生活を形作る2つの基本的な考え方
  • 優れたソフトウェアエンジニアはどのように見えますか?
  • 良い睡眠、良い学習、良い生活
  • 🎞スティーブ・ジョブズ:助けを求めなければ、それほど遠くまでは行けません
  • プログラミングの引用
  • 親切に
    • 親切であることは、基本的にあなたの周りの人々への影響に責任を持つことです。
    • それはあなたが彼らの気持ちに注意を払い、あなたの存在が彼らにどのように影響するかに配慮する必要があります。
  • ウォーレンバフェットは、この1つの単純な習慣が成功した人々を他のすべての人から分離すると言います
    • 成功した人と本当に成功した人の違いは、本当に成功した人はほとんどすべてにノーと言うということです。
  • ラッキーになるには?
  • プログラマーは無能を祝うのをやめるべきです、DHH
    • プログラミングの魔法は、主にあなたがまだ知らないことです。
    • プログラミングをキャリアにしようとするのであれば、習得への道を歩むべきではないと考えるのは問題ありません。
  • 制限速度はありません

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

ダン・ヘラー、ソフトウェアのキャリアを築く

私はすでに自分の執筆の井戸を空にすることは決してないことを学びましたが、井戸の深い部分にまだ何かがあるときはいつも立ち止まり、夜にそれを供給した泉から補充するようにしました。--アーネストヘミングウェイ

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

認証/承認

オートメーション

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

バイアス

バイアスは採用だけに当てはまるわけではありません。たとえば、基本的な帰属バイアスは、まったく異なるコンテキストで、ずっと前に書かれた誰かのコードを批判する場合にも当てはまります。

キャッシュ

キャリア成長

スタッフ工学への行き方

文字セット

雲

コードレビュー

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

コンパイラ

構成

データベース

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

演習：

NoSQL:

データ形式

データサイエンス/データ工学

デバッグ

デザイン(ビジュアル、UX、UI、タイポグラフィ)

非デザイナーのデザインブックを読むことを強くお勧めします。これはかなり短い本で、非常に実用的な設計アドバイスを提供します。

記事：

リソース：

  • 🧰開発者向けのデザインリソース:ストックフォト、Webテンプレート、CSSフレームワーク、UIライブラリ、ツールからのデザインとUIリソース...

デザイン(オブジェクト指向モデリング、アーキテクチャ、パターン、アンチパターンなど)

ここに良い本のリストがあります:

アーキテクチャに関する絶対的な参考文献の1つはMartin Fowlerです:彼のソフトウェアアーキテクチャガイドをチェックしてください。

記事：

製図台で消しゴムを使用するか、建設現場でそりハンマーを使用できます。(フランクロイドライト)

リソース：

デザイン: データベース スキーマ

  • データベーススキーマ設計の謙虚なガイド、マイク・アルチェ
    • 少なくとも第 3 正規形を使用する
    • 制約のある最後の防衛線を作成する
    • 完全なアドレスを 1 つのフィールドに保存しない
    • 名と姓を同じフィールドに保存しない
    • テーブル名とフィールド名の規則を確立します。

デザイン:パターン

デザイン:シンプルさ

  • シンプルに簡単に🎞、リッチなヒッキー。これは、シンプルさ、使いやすさ、複雑さを再定義し、簡単に見えるソリューションが実際に設計に害を及ぼす可能性があることを示す、信じられないほど刺激的な講演です。

Dev environment & tools

ツール

ツールに関する記事:

  • 派手な道具の復活
    • シンプルなツールはあなたにもう少し考えさせます
    • ドラッカー:「後で思い出すために書き留めているのではなく、今思い出すために書き留めているのです。」
    • 摩擦のないメモ取りはメモを生成しますが、メモリは生成しません。

ダイバーシティ&インクルージョン

私の経営資源リストをチェックしてください。

港湾労働者

charlax/python-education の Python 固有のセクションも参照してください。

  • Docker Composeを使用した本番環境対応のWebアプリに関するベストプラクティス
    • オーバーライドファイルを使用してdevとprodの2つの作成ファイルを回避する
    • エイリアスとアンカーによるサービスの重複の削減
    • あなたのドッカーファイルではなく、あなたのドッカー作成を定義する
      HEALTHCHECK
    • 環境変数を最大限に活用する
    • マルチステージビルドを使用してイメージサイズを最適化する
    • 非ルートユーザーとしてのコンテナの実行
  • Python開発者のためのDockerのベストプラクティス
    • マルチステージ ビルドを使用する
    • レイヤーキャッシュを活用するためのDockerfileコマンドの順序に細心の注意を払ってください
    • 小さいDockerイメージはよりモジュール化され、安全です(ただし、Alpineに注意してください)
    • レイヤーの数を最小限に抑えます(、、
      RUN
      COPY
      ADD
      )
    • 特権のないコンテナーを使用する
    • 優先
      COPY
      ADD
    • Python パッケージを Docker ホストにキャッシュする
    • 文字列構文よりも配列を優先する
    • との違いを理解する
      ENTRYPOINT
      CMD
    • 指示を含める
      HEALTHCHECK
    • 可能な限り、タグの使用を避けてください。
      latest
    • シークレットをイメージに保存しない
    • ファイルを使用する(インクルードなど)
      .dockerignore
      **/.git
    • Dockerファイルとイメージをリントしてスキャンします(例:
      hadolint
      )
    • 標準出力または標準エラーへのログ
  • ドッカーコンテナのセキュリティ

ドキュメンテーション

最も薄いインクは、最も強力なメモリよりも信頼性があります。 -- 中国のことわざ

ドットファイル

記事

Editors & IDE

特にVimについて:

私のvim構成と私のvimチートシートを自由にチェックしてください。

電子メール

エンジニアリング管理

管理リストをチェックアウトする リソース。

演習

学ぶための最良の方法は、実践することによって学ぶことです。

練習：

関数型プログラミング (FP)

  • さようなら、オブジェクト指向プログラミング
  • Functional Programming & Haskell🎞: FP を学ぶ理由!
  • 関数型プログラミングの基礎:FPとその利点の簡単な紹介。
  • OO vs FP、ロバートC.マーティン、クリーンコードブログ。OOPの専門家からのOOPとFPの違いについての非常に興味深い見方。
    • オブジェクト指向は状態に関するものではありません。オブジェクトは関数のバッグであり、データのバッグではありません。
    • 機能プログラムは、オブジェクト指向プログラムと同様に、データを操作する関数で構成されています。
    • FPは割り当て時に規律を課します。
    • オブジェクト指向は、関数ポインタに規律を課します。
    • ソフトウェア設計の原則は、プログラミングスタイルに関係なく適用されます。代入演算子を持たない言語を使用することにしたからといって、単一責任の原則を無視できるわけではありません。
  • 解析、検証しない
    • 不正な状態を表現できないようにするデータ構造を使用する
    • 立証責任を可能な限り押し上げるが、それ以上は押し上げない
    • データ型をコードに通知させ、コードにデータ型を制御させないでください
    • 複数のパスでデータを解析することを恐れないでください
    • データの非正規化表現を避ける (特に変更可能な場合)
    • 抽象データ型を使用して、バリデータをパーサーのように「見せる」
  • 🏙関数型プログラミング
  • 15分でモナド
  • ヘマンス/関数型プログラミング専門用語:関数型プログラミングの世界からの専門用語を簡単な言葉で

ハードウェア

ティッカー

ユーモア

インシデント対応 (オンコール、アラート、停止、消火、事後分析)

  • Heroku でのインシデント対応
  • アラートに関する私の哲学
    • ページは、緊急で、重要で、実用的で、現実的である必要があります。
    • ノイズの多いアラートを削除する側の誤り–過剰監視は、監視不足よりも解決が難しい問題です。
    • 症状は、より少ない労力でより多くの問題をより包括的かつ堅牢にキャプチャするためのより良い方法です。
    • 症状ベースのページまたはダッシュボードに原因ベースの情報を含めますが、原因を直接警告することは避けてください。
    • サービングスタックが上に行くほど、1つのルールでより明確な問題をキャッチできます。しかし、何が起こっているのかを十分に区別できないほど遠くまで行かないでください。
    • 静かなオンコールローテーションが必要な場合は、タイムリーな対応が必要であるが、差し迫って重要ではないものに対処するためのシステムを用意することが不可欠です。
    • この古典的な記事は、現在、GoogleのSREブックの章になっています。
  • オンコールに関する Google SRE ブックの章
  • SRE の場合のランブックドキュメントの作成
    • プレイブックは「ストレス、平均修復時間(MTTR)、人為的ミスのリスクを軽減します」。
    • 空白のドキュメントから始めるのは非常に難しいため、テンプレートを使用すると便利です。
    • 知識の呪いは、誰かが他の人とコミュニケーションをとっていて、無意識のうちに彼らがコミュニケーションを取っている人々の知識のレベルを想定しているときに発生する認知バイアスです。
    • コンテンツを一目で見やすくします。
    • スクリプトが 1 行より長い場合は、コードのように扱い、リポジトリにチェックインしてソース管理し、テストする可能性があります。
  • インシデントレビューと事後分析のベストプラクティス、Gergely Orosz

死後

「私たち全員が今日と同じように愚かである未来を計画しましょう。」

- ダン・ミルスタイン

事後分析の概要の例:

  • エグゼクティブサマリー
    • インパクト
    • 根本原因
  • インパクト
    • 影響を受けるユーザーの数
    • 収益の損失
    • 期間
    • チームへの影響
  • タイムライン
    • 検出
    • 解決
  • 根本原因分析
    • 例:5つのなぜメソッド
  • 教訓
    • うまくいったこと
    • うまくいかなかったこと
  • アクションアイテム(タスク追跡ツールへの直接リンクを含む)
    • 予防改善のための業務(研修含む)
    • 検出を改善するためのタスク (監視とアラートを含む)
    • 緩和策を改善するためのタスク(緊急対応を含む)

インターネット

インタビュー

注:これはインタビュアーとしてではなく、インタビュイーとしてのあなたについてです。インタビュアー向けのリソースのリストを確認するには、エンジニアリング管理リポジトリにアクセスしてください。

このドキュメントの「演習」セクションも参照してください。

Kubernetes

学習と暗記

学ぶ方法を学びましょう!

  • 数学に堪能になるために脳を再配線した方法:字幕付き理解の構成要素は暗記と繰り返しです。
  • コーディングを改善する確実な方法の1つは、コードを読むことです。
  • プログラミングを学ぶためのヒント
  • あなたはあなたの知性を高めることができます:あなたの認知の可能性を最大化する5つの方法:クリックベイトのタイトルを許してください、それは実際には良い記事です。
  • 良い質問をする方法、ジュリア・エヴァンス。
  • フレームワークの学習を停止する
  • 学ぶ方法を学ぶ:難しい科目をマスターするのに役立つ強力なメンタルツール
  • なぜ本がうまくいかないのか、アンディ・マトゥシャク。
    • 「メディアとして、本は知識を伝えるのが驚くほど苦手で、読者はほとんどそれに気づいていません。」
    • 「学習科学では、このモデルを「伝達主義」と呼んでいます。これは、あるページから別のページにテキストを書き写すように、知識を教師から生徒に直接伝えることができるという概念です。もしそうなら!」
    • 「拡張間隔で学習した資料で自分自身を再テストすることで、大量の情報を安価かつ確実に長期記憶にコミットできます。」
  • Ankiの戦略、ヒント、コツ:これらのアドバイスは、実際にはどのツールでも機能します
    • 画像を追加します。私たちの脳は視覚的に配線されているので、これは保持に役立ちます。
    • わからないことは追加しないでください。
    • リスト全体を記憶するカードを追加しないでください。
    • それを書き留めてください。間違った答えのために、私はそれを紙に書きます。書くという行為は瞑想的です。私はこれを本当に楽しんでいます。
    • なぜ自問し続けてください。なぜこれが機能するのですか?なぜこのように機能するのですか?トピックの根本を理解するように強制します。
    • コーネル法:トピックを読むときは、余白に質問を書いて自分をクイズします。
    • あなたがそれを教えなければならないふりをする
    • PEMDASのようなニーモニックフレーズは、リストやその他の覚えにくいトピックに使用します。
    • 意味をなさないカードや、もう覚えたくないカードを削除します。
  • 効果的な学習:知識を定式化するための20のルール
    • 基本に基づいて構築する
    • 最小限の情報の原則に固執する:あなたが学ぶ資料は、それと同じくらい簡単な方法で定式化されなければなりません
    • 削除を閉じることは簡単で効果的です:Kaleidaの使命は作成することでした...それは最終的にスクリプトXと呼ばれるものを生み出しました。しかし、それは3年かかりました
    • グラフィックの削除は、削除を閉じるのと同じくらい良いです
    • セットを避ける
    • 列挙を避ける
    • 戦闘干渉-最も単純なアイテムでさえ、他のアイテムと類似している場合、完全に扱いにくい場合があります。例、文脈の手がかり、鮮やかなイラストを使用し、感情を参照し、私生活に言及します
    • パーソナライズして例を提供する-パーソナライズは、他の記憶に基づいて構築する最も効果的な方法かもしれません。あなたの個人的な生活は、参照する事実と出来事の金鉱です。自分でコレクションを作成する限り、パーソナライゼーションを豊富に使用して、確立された思い出に基づいて構築します
    • 情報源を提供する-情報源は、学習プロセスの管理、知識の更新、その信頼性または重要性の判断に役立ちます
    • 優先順位を付ける - 効果的な学習とは、優先順位を付けることです。
  • 科学に裏打ちされた、本当に覚えておきたいことを覚える方法
    • 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

About Zettelkasten and PKM (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 to. — Elon Musk

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

Tell me and I forget. Teach me and I remember. Involve me and I learn. – 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)

Linux (system management)

Low-level, assembly

Math

Network

  • The Great Confusion About URIs
    • A URI is a string of characters that identifies a resource. Its syntax is , where only and are mandatory. URL and URN are URIs.
      <scheme>:<authority><path>?<query>#<fragment>
      <scheme>
      <path>
    • A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. E.g. .
      mailto:billg@microsoft.com
    • A URN is a string of characters that uniquely identifies a resource. Its syntax is . E.g. 
      urn:<namespace identifier>:<namespace specific string>
      urn:isbn:9780062301239

Observability (monitoring, logging, exception handling)

Logging

  • 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

Error/exception handling

Monitoring

Operating system

Over-engineering

“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.

— Steve Jobs

Performance

Personal productivity

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

Perspective

  • 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

Problem solving

Project management

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++...).
  • 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:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

-- Bjarne Stroustrup (C++ creator)

Python

For Python feel free to checkout my professional Python education repository.

JavaScript

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.

Garbage collection

Programming paradigm

Reading

Refactoring

  • 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

Regex

Releasing & deploying

Versioning:

Checklists:

Feature flags:

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

Search

Security

Training for developers:

List of resources:

Shell (command line)

SQL

System administration

System architecture

Reading lists:

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.

Books:

Articles:

Microservices/splitting a monolith:

Scalability

Reliability

  • I already mentioned the book Release it! above. 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.
  • 🧰 Testing Distributed Systems

Resiliency

Site Reliability Engineering (SRE)

Note: this section is only about SRE as a role. Checkout the System Architecture for more content related to reliability.

Books:

  • 📖 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.

Articles:

  • Graduating from Bootcamp and interested in becoming a Site Reliability Engineer?: a great collection of resources to learn about SRE.
  • 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
  • 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…
  • 🏙 High Reliability Infrastructure migrations, Julia Evans.
  • 🏙 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.

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

Resources:

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

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:

Test pyramid:

End-to-end tests:

Tools

Version control (Git)

Learning Git, courses and books:

Cheat sheets:

More specific topics:

Work ethics, productivity & work/life balance

  • Your non-linear problem of 90% utilization, Jason Cohen: why constantly running at 90% utilization is actually counter-productive.
  • Evidence-based advice on how to be successful in any jobs: most self-help advices are not research-based. The ones listed in this article are.
  • The Complete Guide to Deep Work
    • The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy.
    • Choose Your Deep Work Strategy
    • Build a Deep Work Routine
    • Discipline #1: Focus on the Wildly Important
    • Discipline #2: Act on the Lead Measures
    • Discipline #4: Create a Cadence of Accountability
    • Our Ability for Deep Work is Finite
    • The Craftsman Approach to Tool Selection
    • Stop Using Social Media
    • Get Your Boss on Board With Deep Work
  • Every productivity thought I've ever had, as concisely as possible
    • Context intentionality as the key difference between home and every other place on planet earth
    • Rules are about exceptions
  • Makers, Don't Let Yourself Be Forced Into the 'Manager Schedule'
    • Research shows that it takes as long as 30 minutes for makers to get into the flow
    • Use maker-manager office hours
    • Communication can happen at a quieter asynchronous frequency in the form of thoughtful, written discussions rather than soul-sucking meetings or erratic one-line-at-a-time chat messages
    • Build a team knowledge base to minimize repetitive questions and allow self-onboarding.
  • 100 Tips for a Better Life
    • Deficiencies do not make you special. The older you get, the more your inability to cook will be a red flag for people.
    • History remembers those who got to market first. Getting your creation out into the world is more important than getting it perfect.
    • Discipline is superior to motivation. The former can be trained, the latter is fleeting. You won’t be able to accomplish great things if you’re only relying on motivation.
    • You do not live in a video game. There are no pop-up warnings if you’re about to do something foolish, or if you’ve been going in the wrong direction for too long. You have to create your own warnings.
    • Cultivate a reputation for being dependable. Good reputations are valuable because they’re rare (easily destroyed and hard to rebuild). You don’t have to brew the most amazing coffee if your customers know the coffee will always be hot.
    • Compliment people more. Many people have trouble thinking of themselves as smart, or pretty, or kind, unless told by someone else. You can help them out.
  • 🏙 2011 GTD Getting Things Done
  • Build tools around workflows, not workflows around tools
  • Rethinking Best Practices
  • The Cult of Done Manifesto

"Do what you love until you love to Do" I often think about the “Read what you love until you love to read” comment from @naval, and this is a good generalization. My experience has been that it is easier to educate a Do-er than to motivate the educated; you have to believe you can Do before you embark on an effort. – John Carmack

Web development

Writing (communication, blogging)

➡️ See also my engineering-management list

Write like an Amazonian

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

Resources & inspiration for presentations

Keeping up-to-date

Website and RSS feeds (I use Feedly):

安全：

ニュースレター：

概念

用語集

About

Author：charlax

Watch
Star
Fork