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

(A collection of full-stack resources for programmers.)

Created at: 2015-11-07 13:07:52
Language: Python
License: MIT

目次

Professional Programming - このリストについて

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

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

このページの目標は、あなたをより熟練した開発者にすることです。私が本当に刺激的だと思ったリソース、または不朽の名作となったリソースのみを見つけることができます。

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

アイテム:

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

このリストへの貢献

気軽に PR を開いて貢献してください! すべてを追加するわけではありません。上で述べたように、リストを簡潔にしようとしています。

必読の本

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

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

必読の記事

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

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

公理のリスト:

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

コース

トピック

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

その他のリソース:

正直に言うと、アルゴリズムはかなり無味乾燥なトピックになる可能性があります。This quora questionには、次のような面白い学習の代替案がリストされています。

実装例:

API の設計と開発

一般的な REST コンテンツ:

ガイドラインの例:

より具体的なトピック:

態度、習慣、考え方

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

インポスター症候群は過小評価されています。インポスター症候群の克服については、多くのことが語られています。私は、自己懐疑を受け入れ、毎日自分自身を疑うように言います. 毎年多くの知識が失効する急速に変化する業界では、あなたの周りの最も若い人でさえ、あなたが持っていないスキルを常に作り上げています。初心者の決意(そして恐れさえも)を持って応募することで、競争力を維持できます。このトレッドミルの利点は、すべてのエンジニアがそれに取り組んでいるということです。あなたが詐欺師だからといって、他の人があなたよりも価値があるとは限りません。彼らも詐欺師だからです。自分自身を擁護し、リスクを冒し、物事がうまくいったときは自分を後押しし、問題解決の実績を築き始めたら、自分のスキルと適応力を信頼する必要があります。間違えないでください。最後に解いた問題が、あなたの良さです。

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

私は自分の書いた井戸を決して空にしないで、井戸の深い部分にまだ何かが残っているときはいつも止めて、それを養う泉から夜に再び満たすようにすることをすでに学んだ. - アーネスト・ヘミングウェイ

  • The Grug Brained Developer : 自己認識プログラマーの習慣。プログラミングのタオのように、スタイルが違います。

認証・認可

オートメーション

バイアス

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

キャッシュ

キャリアアップ

文字セット

コードレビュー

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

コンパイラ

構成

データベース

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

演習:

NoSQL:

データ形式

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

デバッグ

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

The Non-Designer's Design Bookを読むことを強くお勧めします。これは、非常に実用的なデザインのアドバイスを提供するかなり短い本です。

記事 :

資力:

設計 (OO モデリング、アーキテクチャ、パターン、アンチパターンなど)

良い本のリストは次のとおりです。

アーキテクチャに関する絶対的な参考文献の 1 つは、Martin Fowler です。彼のSoftware Architecture Guideを参照してください。

記事:

製図台で消しゴムを使用したり、建設現場でスレッジ ハンマーを使用したりできます。(フランク・ロイド・ライト)

資力:

設計: データベース スキーマ

  • データベース スキーマ設計の謙虚なガイド、Mike Alche
    • 少なくとも第 3 正規形を使用する
    • 制約のある最後の防衛線を作成する
    • 単一のフィールドに完全な住所を保存しない
    • 姓と名を同じフィールドに格納しない
    • テーブル名とフィールド名の規則を確立します。

デザインパターン

デザイン: シンプル

  • シンプルで簡単 🎞、リッチ・ヒッキー。これは、シンプルさ、使いやすさ、複雑さを再定義し、簡単に見える解決策が実際にはデザインに害を及ぼす可能性があることを示す、信じられないほど刺激的なトークです。

開発環境とツール

ツール

ツールに関する記事:

  • ファンシーツールの復活
    • シンプルなツールでもう少し考えさせられます
    • ドラッカー:「後で思い出すために書き留めているのではなく、今思い出せるように書き留めているのです。」
    • 摩擦のないメモ取りはメモを作成しますが、記憶は作成しません。

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

私の管理リソースのリストをチェックしてください。

ドッカー

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

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

ドキュメンテーション

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

Dotfiles

Articles

Editors & IDE

About Vim specifically:

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

Email

Engineering management

Checkout my list of management resources.

Exercises

The best way to learn is to learn by doing.

練習:

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

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

ハードウェア

HTTP

ユーモア

  • ジェフ・ディーンの事実
    • コンパイラは Jeff Dean に警告しません。Jeff Dean はコンパイラに警告します。
    • 一定時間に満足できなかったジェフ・ディーンは、世界初の
      O(1/N)
      アルゴリズムを作成しました。
    • ジェフ・ディーンはビットコインをマイニングします。彼の頭の中で。

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

  • Heroku でのインシデント対応
  • アラートに関する私の哲学
    • ページは、緊急性、重要性、実用性、現実性を備えている必要があります。
    • ノイズの多いアラートを削除するのは間違っています。オーバー モニタリングは、アンダー モニタリングよりも解決が難しい問題です。
    • 症状は、少ない労力でより多くの問題をより包括的かつ確実に把握するための優れた方法です。
    • 症状ベースのページまたはダッシュボードに原因ベースの情報を含めますが、原因に関する直接のアラートは避けてください。
    • サービング スタックが上に行くほど、1 つのルールで検出できる問題が明確になります。しかし、何が起こっているのかを十分に区別できないほど遠くまで行かないでください。
    • 静かなオンコールローテーションが必要な場合は、タイムリーな対応が必要であるが差し迫った重要ではないことを処理するためのシステムを用意することが不可欠です。
  • オンコールに関するGoogle SRE ブックの
  • 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

Postmortem

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

– Dan Milstein

Example outline for a postmortem:

  • Executive Summary
    • Impact
    • Root cause
  • Impact
    • Number of impacted users
    • Lost revenue
    • Duration
    • Team impact
  • Timeline
    • Detection
    • Resolution
  • Root cause analysis
    • E.g. 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)

Internet

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.

See also the exercises section in this document.

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
  • 知性を高めることができます: 認知の可能性を最大化する 5 つの方法: クリックベイトのタイトルを許してください。これは実際には良い記事です。
  • 良い質問の仕方, Julia Evans.
  • 学習フレームワークの停止
  • 学習方法の学習: 難しい科目を習得するのに役立つ強力な精神的ツール
  • 本がうまくいかない理由, アンディ・マトゥシャク.
    • 「媒体としての本は驚くほど知識を伝えるのが苦手で、読者はほとんどそれを認識していません。」
    • 「学習科学では、このモデルを「伝達主義」と呼んでいます。テキストをあるページから別のページに転記するように、知識を教師から生徒に直接伝達できるという概念です。
    • 「間隔を広げて学んだことを再テストすることで、膨大な量の情報を安価かつ確実に長期記憶にコミットできます。」
  • Anki の戦略、ヒント、コツ: これらのアドバイスは、実際にはどのツールにも有効です。
    • 画像を追加します。私たちの脳は視覚的に配線されているため、これは保持に役立ちます.
    • わからないことを追加しないでください。
    • リスト全体を暗記するカードを追加しないでください。
    • それを書いてください。間違った答えは、紙に書きます。書く行為は瞑想的です。私はこれを本当に楽しんでいます。
    • 理由を自問し続けますか?なぜこれが機能するのですか?なぜこのように機能するのですか?トピックの根源を理解するように努めてください。
    • コーネル法: トピックを読んでいるときに、余白に質問を書き込んで、自分自身にクイズを出します。
    • 教えなければならないふりをする
    • リストやその他の覚えにくいトピックには、PEMDAS などのニーモニック フレーズを使用します。
    • 意味をなさない、またはもう覚えたくないカードを削除します。
  • 効果的な学習: 知識を定式化するための 20 のルール
    • 基本に基づいて構築する
    • 最小限の情報原則に固執する: 学習する内容は、できるだけシンプルな方法で定式化する必要があります
    • Cloze の削除は簡単で効果的です: Kaleida の使命は、スクリプト X と呼ばれるものを作成することでした。しかし、それには 3 年かかりました。
    • グラフィックの削除は、クローズ削除と同じくらい良い
    • セットを避ける
    • 列挙を避ける
    • 干渉と戦う - 最も単純なアイテムでさえ、他のアイテムに似ている場合、完全に手に負えなくなる可能性があります. 例、文脈の手がかり、鮮やかなイラストを使用し、感情に言及し、あなたの個人的な生活に言及する
    • パーソナライズして例を提供する - パーソナライズは、他の記憶を構築する最も効果的な方法かもしれません。あなたの私生活は、参照すべき事実と出来事の宝庫です。自分用のコレクションを構築している限り、パーソナライズを十分に活用して、確立された思い出を構築してください
    • ソースを提供する - ソースは、学習プロセスの管理、知識の更新、その信頼性または重要性の判断に役立ちます
    • 優先順位を付ける - 効果的な学習は優先順位付けがすべてです。
  • 科学に裏打ちされた、本当に覚えたいことを思い出す方法
    • 自分でクイズ
    • 要約して他の人と共有します。
    • 今学んだことを以前の経験に結び付けます。
  • 永遠に何かを覚える方法: 学習についてのコミック
  • 物事の仕組みを学ぶことでプログラミングが上達する
  • 難しいことを自分に教える方法
  • 独自の個人学習カリキュラムを構築する
  • 常にエクストラを行う
    • Extra はこれら 2 つの画面を完成させようとしていますが、定型コードを削減できるフォーム検証用の新しいライブラリを研究しています。
    • エクストラは通常の作業とバランスを取る必要があります。
    • エクストラは通常の作業と一致している必要があります。
  • 3倍速に対して
    • 講義は、教室での経験の一部にすぎない場合に最も効果的です
    • 学習とは間隔をあけて繰り返すことであり、本をむちゃくちゃ読むことではありません
  • 意図的な練習の問題点

Zettelkasten と PKM (個人知識管理) について:

リチャード・ファインマンの学習戦略:

  1. ステップ 1: 継続的に「なぜ?」と尋ねる
  2. ステップ 2: 何かを学ぶときは、子供に説明できるところまで学びます。
  3. ステップ 3: 恣意的に物事を暗記する代わりに、それを明確にする説明を探します。

ほとんどの人は、1 年でできることを過大評価し、10 年でできることを過小評価しています。- ビルゲイツ

率直に言って、ほとんどの人は自分が思っている以上に多くを学ぶことができると思います。彼らはしようとせずに自分自身を空売りします。ちょっとしたアドバイス: 知識を一種のセマンティック ツリーとして見ることが重要です。詳細/葉に入る前に、基本原則、つまり幹と大きな枝を理解していることを確認してください。に。— イーロン・マスク

「経験は、必要になってからしか得られないものです。」― スティーブン・ライト

教えてください、そして私は忘れます。私に教えて、私は覚えています。私を巻き込んで、私は学びます。- ベンジャミンフランクリン

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

Low-level, assembly

Network

  • 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. E.g.
      mailto:billg@microsoft.com
      .
    • A URN is a string of characters that uniquely identifies a resource. Its syntax is
      urn:<namespace identifier>:<namespace specific string>
      . E.g.
      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

Perspective

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.

Programming paradigm

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

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

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.

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:

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

アマゾンのように書く

考え過ぎなら書いてください。考えが浅い場合は、読んでください。– @AlexAndBooks_

パフォーマンスのために書く

プレゼンテーションのリソースとインスピレーション

最新の状態に保つ

ウェブサイトと RSS フィード (私はFeedlyを使用しています):

安全:

ニュースレター:

コンセプト

用語集