professional programming

目录

• 专业编程 - 关于此列表
  • 原则
  • 为此列表做出贡献
  • 必须阅读的书
  • 必读文章
  • 其他一般材料和资源清单
    • 其他列表
    • 图书
    • 文章
    • 公理
    • 课程
  • 主题
    • 算法和数据结构
    • API设计与开发
    • 态度，习惯，心态
      • 拖延
    • 身份验证/授权
    • 自动化
    • 最佳实践
    • 超越软件工程和随机
    • 偏见
    • 商业
    • 缓存
    • 职业发展
      • 选择您的下一个/第一个机会
      • 进入员工工程
    • 字符集
    • 棋
    • 云
    • 代码评论
    • 编码和代码质量
    • 沟通
    • 编译器
    • 配置
    • 连续集成（CI）
    • 数据库
      • nosql
      • Postgres
    • 数据格式
    • 数据科学/数据工程
    • 调试
    • 设计（Visual，UX，UI，版式）
    • 设计（OO建模，建筑，模式，反故事等）
      • 设计：数据库模式
      • 设计：图案
      • 设计：简单
    • 开发环境和工具
    • Docker
    • 文档
    • 互联网
    • 编辑和IDE
      • vim
    • 电子邮件
    • 工程管理
    • 练习
    • 实验
    • 功能编程（FP）
    • 游戏开发
    • 图形
    • 硬件
    • http
    • 幽默
    • 事件响应（ONCALL，警报，中断，消防，验尸）
      • 验尸
    • 互联网
    • 采访
    • Kubernetes
    • 大语言模型（LLM）
    • 学习与记忆
    • 许可证（法律）
    • Linux（系统管理）
    • 低代码/无代码
    • 低级，组装
    • 机器学习/AI
    • 数学
    • 营销
    • 网络
    • 可观察性（监视，记录，例外处理）
      • 记录
      • 错误/异常处理
      • 指标
      • 监视
    • 开源
    • 操作系统（OS）
    • 过度工程
    • 表现
    • 个人知识管理（PKM）
    • 个人生产力
    • 看法
    • 隐私
    • 解决问题
    • 软件工程师的产品管理
    • 项目管理
    • 编程语言
      • Python
      • JavaScript
      • 垃圾收集
    • 编程范式
    • 公开演讲（介绍）
    • 阅读
    • 重构
    • 正则
    • 释放和部署
      • 版本控制
      • 清单
      • 功能标志
      • 生产测试
    • 可靠性
      • 弹性
    • 搜索
    • 安全
    • 壳（命令行）
    • SQL
    • 系统管理
    • 系统体系结构
      • 建筑模式
      • 微服务/拆分整体
    • 可伸缩性
    • 站点可靠性工程（SRE）
    • 技术债务
    • 测试
    • 工具
    • 类型系统
    • 排版
    • 版本控制（GIT）
    • 职业道德，生产力与工作/生活平衡
    • 网络开发
    • 写作（沟通，博客）
  • 演讲的资源和灵感
  • 保持最新
  • 概念
  • 我的其他列表

专业编程 - 关于此列表

给我六个小时砍树，我将花在前四个锐化斧头。 （亚伯拉罕·林肯）

为程序员提供的全栈资源集合。

此页面的目的是使您成为更熟练的开发人员。您只会发现我发现真正鼓舞人心或已成为永恒经典的资源。

原则

• 此页面并不意味着全面。我试图保持轻便，而不是太压倒了。
• 文章的选择是有用的。
• 我不一定同意或认可其中每一个资源中每一条行。他们的作者也是如此：我不认可每个作者所说的一切，并且会说的。

项目：

• ？ ：资源清单
• ： 书
• ？ ：视频/电影提取/电影/谈话
• ？ ：幻灯片/演示
• 祖：必须阅读
• ？ ： 纸

为此列表做出贡献

随时开放公关供款！

我不会添加所有内容：如上所述，我试图使列表保持简洁。

必须阅读的书

我发现这些书令人难以置信：

• 务实的程序员：从《旅行者到掌握：动手实践》是我读过的有关编程的最具启发性和有用的书。
• 代码完成：一本实用的软件构建手册：务实程序员的不错的补充，为您提供了谈论代码的必要框架。
• 发布它！：这本书超越了代码，并为您提供了构建可准备生产的软件的最佳实践。它将为您提供大约3年的现实经验。
• 可伸缩性规则：缩放网站的50个原则
• Linux编程接口：Linux和Unix系统编程手册：在教您几乎需要了解的有关Linux的所有信息之外，这本书将为您提供有关软件如何发展的见解，以及具有简单而优雅的接口的价值。
• 计算机程序的结构和解释（免费）：SICP是计算机科学中最有影响力的教科书之一（在麻省理工学院撰写和使用），在CS教育中具有影响力。 Byte建议SICP“对于对自己的职业真正感兴趣的专业程序员”。

有一些免费书籍，包括：

• 专业软件开发：非常完整，是此页面的好伴侣。免费章节主要集中在软件开发过程上：设计，测试，代码编写等 - 而不是技术本身。
• ？ VHF/自由编程书
• ？电子书发现/自由编程书

必读文章

• 新软件工程师的实用建议
• 作为高级工程师
• 在软件开发中汲取的经验教训：其中一篇文章为您提供了多年的来之不易的课程，全部在一篇简短的文章中。必须阅读。
• 我学到的东西很难
  • 首先规格，然后代码
  • 测试可以使API更好
  • 未来的思维是未来的垃圾
  • 文件是给您未来自我的情书
  • 有时，让应用程序崩溃比什么都不做要好
  • 了解并远离货物邪教
  • “工作正确的工具”只是为了推动议程
  • 学习基础功能编程
  • 始终在您的日期使用时区
  • 始终使用UTF-8
  • 创建库
  • 学习监视
  • 明确胜于隐式
  • 公司寻找专家，但要使通才更长
  • 处理用户数据的最佳安全方法不是捕获它
  • 是时候停下来了，该停止了
  • 您负责使用代码
  • 当不是时不要说“完成了”
  • 注意人们对您的反应
  • 当心微侵略
  • 保留“我不知道的事情”列表
• 迹象表明您是一个好程序员（并非这里的所有内容都很棒 - 其中一些要适得其反）
  • 首先实验的本能
  • 与代码和设计的情感分离
  • 渴望修复没有破裂的东西
  • 被难以理解的
  • 被迫教
  • 廉洁的耐心
  • 对完美的破坏性追求
  • 平台的百科全书
  • 思考代码
  • 在罗马时，像罗马人一样
  • 创建自己的工具
  • 对层次结构无动于衷
  • 因失败而兴奋
  • 对情况无动于衷
  • 替代脉动做出承诺
  • 由经验驱动
• 7个绝对真理
  • 在您职业生涯的早期，您可以在1年内在支持团队中学习10倍，而不是自己编码
  • 每个公司都有问题，每个公司都有技术债务。
  • 在您缺乏现实世界经验的主题上过分自以为是，这是非常自大的。
  • 许多会议会议涵盖了概念证明，而不是现实世界中的情况。
  • 处理遗产是完全正常的。
  • 架构比挑剔更重要。
  • 在适当的情况下专注于自动化文档。
  • 拥有一些技术债务是健康的。
  • 高级工程师除了编程外还必须发展许多技能。
  • 我们在某些地区仍然很少。
• 如何构建好软件
  • 基本工程实践的良好高级摘要。
  • 不良软件的根本原因与特定的工程选择无关，而与开发项目的管理方式有关。
  • 没有柏拉图上良好的工程等事情：这取决于您的需求和遇到的实际问题。
  • 软件不应被视为静态产品，而应作为开发团队集体理解的生活体现。
  • 软件项目很少失败，因为它们太小；他们之所以失败，是因为他们太大了。
  • 当心官僚目标将伪装成问题陈述。如果我们的最终目标是使公民的生活变得更好，我们需要明确承认使他们的生活变得更糟的事情。
  • 构建软件不是避免失败；这是关于在战略上尽快失败，以获取构建好东西所需的信息。
• 如何成为-10x工程师
  • 无效10名工程师的输出。
  • 在技​​术讨论中持有10名工程师人质。
  • 浪费10周的云成本工资。
  • 浪费400小时在不良建筑上的工程。
  • 产生400小时的虫子分诊。

其他一般材料和资源清单

其他列表

• Liuchong/Awesome-Road图：路线图的精选清单。

图书

• 冒名顶替者的手册-30美元。从作者那里：“没有CS学位？我也没有 - 这就是为什么我写这本书的原因。”
• 计算机科学书

文章

• MR-MIG/每个程序员都知道：每个软件开发人员都应该知道的（主要是）技术的东西集合
• 著名软件开发法律
• 亚马逊建筑商库
  • 此Twitter线程中有一份最佳文章列表
• kdeldycke/Awesome-Falseoody：虚假程序员相信
• hellerve/编程谈话
• Techyaks：谈话清单
• 谈话改变了我对编程的看法
• 每个计算机科学专业都应该知道的
• Kamranahmedse/开发人员-Road图
• MTDVIO/每个程序员都知道：每个软件开发人员都应该知道的（主要是）技术知识的集合
• 迈克·阿克顿（Mike Acton）对专业软件工程师的期望
• 他们没有教您有关软件工程的事情
  • 领域知识比您的编码技能更重要
  • 代码是次要的。业务价值是首先。
  • 您大多数时候都在不确定性
• 我们高估了我们的短期能力，但低估了我们的长期能力。
  • 专业是针对昆虫的。
• 想要在您的技术职业中有不公平的优势吗？消费内容用于其他角色
  • 跨职能的理解对于现代科技公司至关重要
  • 有助于避免低估其他角色的重要性和困难
  • 帮助您在与该角色的人互动中战略性
• 在十年内教自己编程

公理

• 戒律 - urbit
  • 数据比代码更好。
  • 正确性比性能更重要。
  • 确定性的节奏启发式。
  • 一百条简单性比二十条复杂性更好。
  • 如果您的抽象正在泄漏，那不是由于宇宙的某些法律。您只是吸取抽象。通常，您没有足够狭窄地指定抽象。
  • 如果您避免更改一部分代码，因为他们担心唤醒其中的恶魔，那么您将生活在恐惧中。如果您呆在您编写或熟悉的代码小部分的舒适范围内，您将永远不会编写传奇代码。所有代码都是由人类撰写的，可以由人类掌握。
  • 如果显然有正确的方法做某事和错误的方法，请以正确的方式进行操作。编码需要令人难以置信的纪律。
  • 获得正确答案的最佳方法是以错误的方式尝试。
  • 练习告诉你，事情是好是坏。理论告诉你为什么。
  • 没有资格解决问题的原因没有理由不解决问题。
  • 如果您不了解正在使用的系统，则无法控制它。如果没有人理解系统，则系统正在控制。
• 嵌入式经验规则
• 改变了我生活的50个想法
• 对10,000小时编程的思考
• 我20年以来作为软件工程师学到的20件事

课程

• Google Tech Dev指南
• 麻省理工学院的CS教育学期缺失。包括有关外壳，编辑，数据争吵，git，调试和分析，元编程，安全性和加密的讲座。
• 冒险的自学习者尼尔·塞恩斯伯里（Neil Sainsbury）的数学
• JWASHAM/CODING-INTERVIEW-UNIVERSITY：一个完整​​的计算机科学研究计划，成为一名软件工程师。
• 教自己计算机科学：一组最佳的CS资源。
• OSSU/计算机科学：计算机科学的免费自学教育！

主题

算法和数据结构

• 阅读CLR。您可以在OCW上观看和下载课程 - 还有更新的课程。
• 或算法设计手册
• 在Project Euler上尝试一些算法
• CS 61B 2023春季

其他资源：

• 算法，杰夫·埃里克森（Jeff Erickson）

老实说：算法可能是一个非常干燥的话题。这个Quora问题列出了一些更有趣的学习替代方案，包括：

• Grokking算法
• 基本算法
• 数据结构可视化
• ？ 15个分类算法在6分钟内
• 哈希
• 可视化算法
• B-Trees和数据库索引

示例实现：

• trekhleb/javascript-algorithms：JavaScript中实现的算法和数据结构
• 算法

分布式系统中的算法：

• 筏共识算法

API设计与开发

一般休息内容：

• 建筑风格和基于网络的软件体系结构的设计Roy Fielding（REST的发明者）
• 用于构建Restful HTTP+JSON API的有用资源集合。
• REST API设计的最佳实践，堆栈溢出博客
• 不受干扰的休息：设计完美API的指南：关于Restful API设计的非常完整的书。

示例指南：

• 微软的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 Patch的力量

态度，习惯，心态

• 掌握编程，肯特·贝克（Kent Beck）。
• 熟练的程序员的特征
• 编程的道：一组关于编程的寓言。
• 拥有所有权是获得想要的最有效方法
• 找时间成为更好的开发人员
• 每天十分钟：亚历克斯·艾伦（Alex Allain）如何在不到200个小时的时间里写一本书，每天写10分钟。
• 软件工程师的护理和喂养（或为什么工程师脾气暴躁）
  • 在软件，产品经理，设计师和软件工程师的thriument派中，只有工程师有望关闭其创意思维并只是生产。
  • 工程师和产品经理都倾向于错误地思考产品规格或要求等效于宜家的家具手册。
  • 这是使工程师脾气暴躁的最重要的事情之一：不断变化的优先事项。
  • 即使许多工程师会抱怨产品经理改变主意，但在他们的时间估计中，几乎没有人会考虑到这一点。
  • 计算机科学计划并不是要为您在行业中所面临的任务做好准备。
  • 当工程师比所使用的工程师更多时，工程时间最终会远离发展，并进行计划，同步和协调。
  • 让工程师参与创作过程
  • 为工程师提供创造力的机会。
  • 鼓励时间休息。
  • 让我们代码
  • 明确的感谢
• 产品意识的软件工程师Gergely Orosz
  • 伟大的产品工程师知道，最少可爱的产品需要正确的深度
  • 产品有意识的工程师迅速绘制出边缘案例，并考虑减少对其进行工作的方法：通常带来不需要工程工作的解决方案
  • 参与用户研究和客户支持
  • 将良好的产品建议带到桌子上
  • 提供产品/工程权衡
• 40年的40堂课，史蒂夫·施拉夫曼（Steve Schlafman）
  • 如果您想在最重要的事情上取得进步，则需要决定要让谁失望。这是不可避免的。
  • 您可以进行的最好的投资是自己的教育。永远不要停止学习。您可以进行的第二好投资是通过真实且有意义的互动来建立网络。这是您所知道的，您认识的人。
  • 您将永远不会得到您不要求或积极寻求的东西。大胆试试吧！
  • 这与隧道尽头的光无关。这是隧道。每天出现并享受这个过程。
  • 一个伟大的队友总是将组织及其目标置于自己的自身利益之外。
  • 选择您的位置。我们的时间有限，大脑只能处理太多。焦点是关键。明智地选择。
  • 每个人都可能在挣扎。善良。有帮助。
• 关于编码，自我和注意力
  • 初学者的思想接受了绝对知识是无限的事实，因此保持得分是浪费时间。
  • 掌握只是动量的积累，而不是知识的积累。
  • 处理自我分心已经教会我喜欢解决问题的过程。它教会了我爱和尊重学习过程。结果，我更有生产力。我不太焦虑。我是一个更好的队友。我是一个更好的朋友，也是一个更好的思想家。
• 固定与成长：塑造我们生活的两种基本思维方式
• 一位出色的软件工程师是什么样的？
• 良好的睡眠，良好的学习，美好的生活
• ？史蒂夫·乔布斯（Steve Jobs）：如果您不寻求帮助，您将不会走很远
• 编程行情
• 善良
  • 从根本上讲，善良是要对您对周围人的影响负责。
  • 它要求您注意他们的感受和体贴，以了解您的存在对他们的影响。
• 沃伦·巴菲特（Warren Buffett）说，这个1个简单的习惯将成功的人与其他所有人分开
  • 成功的人和真正成功的人之间的区别在于，真正成功的人几乎对一切都拒绝。
• 如何幸运？
• 程序员应停止庆祝无能，DHH
  • 编程的魔力在很大程度上只是您还不知道的事情。
  • 如果您打算使自己的职业编程，那么认为您不应该走上一些掌握的道路是不好的。
• 没有速度限制
• 不要等待动力，动力
  • 从一项很小的任务开始。然后骑势头。
• 最重要的编码习惯
  • 最重要的编码习惯
  • 每日伸展
  • 定期休息
  • 不要在深夜代码
  • 改善您的编码环境
• 有关阅读所有其他建议论文的新软件开发人员的建议
• 微服务不是问题。无能的人是

冒名顶替综合征被低估了：克服冒名顶替综合症的许多谈话。我说拥抱自我怀疑，每天怀疑自己。在一个快速发展的行业中，您的许多知识每年都会到期，即使您周围的大多数初级人员都在不断地烹饪您所没有的技能；您通过申请新手的决心（甚至恐惧）来保持竞争力。这个跑步机的好处是，每个工程师都在上面：仅仅因为您是冒名顶替者，并不意味着别人比您更应得的，因为他们也冒犯了。您应该为自己提倡，冒险，在事情进展顺利时拍打背部，并在您开始建立解决问题的记录时，相信您的技能和适应性。只要毫无疑问：您只与您解决的最后一个问题一样好。

丹·海勒（Dan Heller），在软件中建立职业

我已经学会了永远不会清空写作的井，但是总是要在井中仍然有东西时停下来，然后在晚上从喂养它的泉水中加入。 - 欧内斯特·海明威（Ernest Hemingway）

• Grug brained开发人员：自我意识程序员的习惯。像编程的道，不同的风格。

良好的判断来自经验。经验来自不良判断。

拖延

• 新闻对您有害 - 放弃阅读会让您更快乐，监护人
  • 新闻误导
  • 新闻无关紧要
  • 新闻没有解释力
  • 新闻对您的身体有毒
  • 新闻增加了认知错误
  • 新闻抑制思维
  • 新闻就像毒品一样
  • 新闻浪费时间
  • 新闻使我们被动
  • 新闻杀死了创造力

身份验证/授权

• 在微服务世界中的授权
• 授权逻辑：规则很难，因为它们会随着时间的流逝而发展
• 哥本哈根书提供了有关在Web应用程序中实施AUTH的一般指南

自动化

• 自动化应该像钢铁侠，而不是Ultron

最佳实践

• 软件工程实践

超越软件工程和随机

• 为什么像木工这样的软件工程师

偏见

偏见不仅适用于招聘。例如，在完全不同的背景下，批评某人的代码写作时，基本归因偏差也适用。

• 认知偏见备忘单。 ＃雇用

商业

• 开发人员的付款101
• 自制计费系统的4个最大问题
• ？建立自己的计费系统的14次痛苦

缓存

• 缓存挑战和策略，亚马逊建筑商图书馆

职业发展

• 高级发展的连接三角形研究了如何定义高级工程师。
• 工程师丹·海勒（Dan Heller）成长的十个原则。
• 不要称自己为程序员帕特里克·麦肯齐（Patrick McKenzie）。
• 担任工程经理
• 我希望我25岁的职业建议
  • 职业是马拉松，而不是冲刺
  • 大多数成功来自重复，而不是新事物
  • 如果工作真的很棒，那么所有有钱人都会有工作
  • 管理是关于人的，而不是事物
  • 真正听别人
  • 认识到员工是具有有限情感能力的人
  • 不要只是与自己年龄的人建立联系
  • 永远不要牺牲自己的道德原因
  • 认识到失败是在学习
• 我希望我小时候会得到职业建议
  • 不要过多地专注于长期计划。
  • 找到好的思想家，并冷笑您最欣赏的人。
  • 在整个寿命中为生产率分配高价值。
  • 不要过度优化的事情，而不是您的重中之重。
  • 阅读很多，阅读周围人没有阅读的东西。
  • 认真思考要确定解决问题的问题。
  • 阅读更多历史。
• 为什么优秀的开发人员被提升为不幸，Rob Walling。或者为什么管理层可能不适合您。
• 利用您的职业来帮助解决世界上最紧迫的问题的指南
• 什么是高级工程师的工作？您不仅要成为个人贡献者。
• 从编码训练营毕业到构建分布式数据库
  • 阅读书籍（和论文），而不是博客文章
  • 对您的职业轨迹负责
• ？圆润的工程师包括许多很棒的书籍建议。
  • Paradigm Polyglot（学习不同的语言和范式）
  • 数据库polyglot
  • 协议Polyglot（最好是TCP/IP和HTTP）
  • 熟练构建工具，包装和分配
  • 调试，可观察性
  • 部署，下文和Devops
  • 软件体系结构和扩展
  • 能够编写玩具编译器，口译员和解析器的能力
  • 写玩具游戏的能力
  • 了解算法分析的能力
• 一些职业建议，威尔·拉尔森。
  • 您得到的建议是某人试图综合他们的经历，而不是关于世界如何运作的准确陈述。
  • 建立声望的水库。
  • 有些人擅长某些事情，以至于他们目前的角色最终无法替代，这会使他们陷入困境，即使他们是更有趣的人的好候选人。
  • 良好的关系将随时随地跟随您。也很糟糕。
  • 在您的职业生涯的早期，请尽可能地在尽可能多的不同类型的公司工作。
• 邪恶提示：避免“简单”的事情
• 终极代码kata
• 高级软件工程师的特征：影响，感知，可见性，影响力，指导
• 软件工程 - 软件
  • 批判性思考并提出良好的论点
  • 掌握基本面
  • 专注于用户，其他所有内容都将遵循
  • 学习如何学习
• 如何拥有软件工程师的成长
• 四十年的程序员
  • 您得到的越好，您看起来像其他人越少
  • 您可以通过做基础知识来学习深刻的原则
  • 查看其他领域，从其他领域学习
  • 小心生产力提示
• 高级工程师将来生活
• 您的职业地图会是什么样？
• 如何在亚马逊（或其他任何大型公司）取得成功

关于高级工程师：

• 虚假的初级开发人员相信成为高级

选择您的下一个/第一个机会

• 职业决定 - 埃拉德·吉尔（Elad Gil） - 埃拉德（Elad）博客

进入员工工程

• 我在5年内成为了Faang的员工工程师。这些是我一路上学到的14堂课。
  • 软件工程不仅仅是编码。实际上，编码是其中的一小部分。
  • 管道你的工作
  • 向反馈开放并听。就像，认真地听着。
  • 很难找到很好的反馈；珍惜它。
  • 密切关注地平线（但不是两者）。
  • 弄清楚什么重要，然后让剩下的一切。
  • 比较确实是喜悦的小偷。
  • 指导是一件美丽的事情。
  • 总的来说，美好的日子不仅要“发生”。
  • 建议和指导就是这样；他们不是规则。
• 指南接触员工加工程角色，威尔·拉尔森（Will Larson）
  • 可见
  • 员工加工程的其他资源

字符集

• 绝对最小的每个软件开发人员绝对，积极地必须了解Unicode和角色集（没有借口！）
• 每个软件开发人员必须了解2023年Unicode的绝对最低限度（仍然没有借口！）

棋

（是的 - 国际象棋有自己的部分:)

• 国际象棋式Wiki
• 压缩国际象棋移动

云

• 开放指导/OG-AWS：AWS实用指南

代码评论

• 如何进行代码审查，Google的工程实践文档。
• 宣传后评论：提高开发人员速度的一个有趣的想法（虽然有一些警告）。
• 如何使您的代码审阅者爱上您
  • 首先查看您自己的代码
  • 写一个清晰的改变主义描述
  • 自动化简单的东西
  • 用代码本身回答问题
  • 范围狭窄的变化
  • 单独的功能和非功能变化
  • 对批评的慷慨回应
  • 巧妙地征求丢失的信息
  • 将所有关系授予您的评论者
  • 最小化审查之间的滞后
• 如何像人类一样进行代码评论
• 问HN：您如何审查代码？：关于黑客的精彩讨论，充满了有趣的想法。
• 马斯洛的代码评论金字塔
  • 同一主题上的另一个：代码评论金字塔
• 远程团队中的代码审查：非常完整的规则集。
• 默认没有代码评论
  • 对惯例的责任

编码和代码质量

• 编写易于删除的代码，不容易扩展
• Egoless编程的十诫
• 清洁代码：敏捷软件手工艺手册，罗伯特·C·马丁（Robert C. Martin）。描述了许多有用的最佳实践。有点长。还有一个干净的代码备忘录。
• 哪种软件工艺是关于
  • 我们厌倦了写废话。
  • 以后，我们不会接受愚蠢的谎言。
  • 我们不会相信快速意味着肮脏的说法。
  • 我们将不允许任何人迫使我们表现非专业。
• 命名布尔变量的提示
  • 有一个约定，将布尔变量和函数名称前缀为“ is”或“ has”。
  • 尝试始终使用的是，即使对于复数（ isEachUserLoggedIn也比areUsersLoggedIn或isUsersLoggedIn更好）
  • 避免自定义前缀（ isPaidFor比wasPaidFor更好）
  • 避免负面因素（ isEnabled比isDisabled更好）
• 如何编写无与伦比的代码
• Kettanaito/naming-cheatsheet ：：综合语言 - 不合稳定指南命名。 A/HC/LC模式的故乡。
• ？优质的工程指南

沟通

另请参见写作部分

• 如何有效地作为开发人员进行交流
  • 短，中和长格式写作的许多具体建议和示例
• 您在编程时可视化什么？

编译器

• 编译器作者资源页面
• Kanaka/Mal：MAL-制作LISP

配置

• JSON的配置文件的缺点，Martin Tournoij。
  • 无法添加评论
  • 引号过多和语法噪音
  • 使用DC（声明配置）来控制逻辑通常不是一个好主意。
• 您的配置很烂？尝试一种真实的编程语言
  • 大多数现代配置格式很烂
  • 使用真实的编程语言

连续集成（CI）

• 持续集成，martinfowler.com

数据库

另请参见SQL部分。

• 简单的英文介绍CAP定理
• PACELC定理：“如果在分布式计算机系统中进行网络分区（P），则必须在可用性（a）和一致性（C）（根据CAP定理）之间进行选择，但是即使系统，也必须在系统之间进行选择在没有分区的情况下正常运行，必须在延迟（L）和一致性（C）之间进行选择。”
• 零停机时间数据库迁移（代码示例正在使用导轨，但这对任何编程语言都非常有用）
• 现代存储系统背后的算法，ACM队列
• 让我们构建一个简单的数据库
• 数据库系统中的读数，第五版
• 比较数据库类型：数据库类型如何发展以满足不同的需求
• 关系数据库如何工作
• 使用索引，卢克
• 课程简介 - 用于开发人员，行星级的MySQL
• 查询引擎如何工作
• 为什么您可能应该使用sqlite | Epic Web开发

nosql

• NOSQL模式
• NOSQL数据库：调查和决策指导
• DynamoDB文档有一些很棒的页面：
  • 阅读一致性
  • 从SQL到NOSQL
  • NOSQL设计DynamoDB
• Redis解释说

Postgres

• 大量PostgreSQL的安全操作（这适用于PostgreSQL，但也适用于其他DBS）。
• 解释说，Postgres的交易隔离
• PostgreSQL练习
• Postgres操作备忘单
• 只需使用Postgres即可
• Postgres就足够了
• Postgres：不要这样做
• PostgreSQL和UUID作为主要密钥

数据格式

• 虚假的程序员相信电话号码，Google的libphonenumber 。
• 自动完成规则：自动完成字段的粗略规格
• 虚假的程序员相信地址
• 虚假的程序员相信名字
• kdeldycke/Awesome-Falseoody：虚假程序员相信
• 了解UUID，ULID和字符串表示
• 虚假的程序员相信虚假列表
• 澳大利亚/lord_howe是最奇怪的时区

数据科学/数据工程

• 肮脏的十二：在线受控实验中的十二个常见的度量解释陷阱
• DataStAckTV/Data-Gradeer-road图：成为数据工程师的路线图
• 很棒的数据工程学习路径
• 现代数据基础架构的新兴体系结构
• 如何超越整体数据湖到分布式数据网格
  • 基于数据湖体系结构的数据平台具有常见的故障模式，从而导致规模未实现的承诺。
  • 我们需要将域作为一流的关注，应用平台思维来创建自助数据基础架构，并将数据视为产品。
• mlops
• Uber的大数据平台：100多个pb具有微小潜伏期
• SQL应该是数据转换逻辑的默认选择

调试

另请参阅此文档中的事件响应部分

• 橡皮鸭问题解决
• 橡皮鸭
• 五个
• 五个谎言分析
  • 当技术成为模板的一部分时，真正的问题会揭示自己。
  • 动作项目可能与根本原因非常遥远。
• 无限的如何批评五种方法，并提倡一组不同的问题，可以从事件中学习最多。
  • 另请参阅：人类错误：模型和管理
  • “这五个方面的问题是，它被隧道视为对工作方式的线性和简单的解释，事件的发展。”
  • “人为错误成为起点，而不是结论。” （Dekker，2009年）
  • “当我们问'如何？'时，我们要叙事。”
  • “在决策和行动方面，我们想知道某人做自己所做的事情是有意义的。”
  • 在每个“为什么”步骤中，将只选择一个答案以进行进一步调查。询问“如何”鼓励更广泛的探索。
  • “在大多数其他人类努力中，在事故调查中，我们属于您对您的视野或wylfiwyf原则的牺牲品。这是一个简单的认识，即对我们所做的假设的事实的一个简单认识将在很大程度上看待（您看起来像是什么样的），将决定我们实际发现的东西（您找到什么）。” （Hollnagel，2009年，第85页）（请参阅Wylfiwyf的图）
  • “可以选择'根本原因'的最终原因是，它在政治上是可以接受的，因为已确定的原因。在政治上是不可接受的。” （南希·莱维森（Nancy Leveson），工程更安全的世界，第20页）
  • 有限的理性：理性个人将选择一个令人满意而不是最佳的决定
  • 本文提供了具体的方法和问题，以征求人们的故事，这将产生更好的见解。
    • 您期望发生什么？
    • 如果您当时必须向同事描述情况，您会告诉您什么？
    • 这种情况适合标准方案吗？
    • 您想实现什么目标？是否同时有多个目标？是否有时间压力或您能做什么？
    • 请参阅此处的模板
• Linux性能分析60,000毫秒
• HubSpot的验尸：我从250个中学到了什么
• 调试杂志，朱利安·埃文斯（Julian Evans）
• 如果您了解一个错误，则可以修复它
• 三十分钟的规则：如果有人陷入了30分钟以上的时间，他们应该寻求帮助
• 如何创建最小，可重复的示例，堆栈溢出
• 朱莉娅·埃文斯（Julia Evans）在调试中变得更好的一些方法
  • 学习代码库
  • 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: 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
• 社会
• 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
  • 记录您的知识
  • Train your replacement
  • 代表
  • By being disposable, you free yourself to work on high-impact projects.
• Write documentation first.然后构建。
• 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

Dotfiles

• ？ 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
• 运动

实验

• 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

幽默

• 杰夫·迪恩事实
  • 编译器不会警告杰夫·迪恩（Jeff Dean）。杰夫·迪恩（Jeff Dean）警告编译器。
  • 杰夫·迪恩（Jeff Dean）对恒定时间不满意，创建了世界上第一种O(1/N)算法。
  • 杰夫·迪恩（Jeff Dean）地雷比特币。在他的脑海。
• 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.

验尸

• 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 Does the Internet Work?
• How the web works
• Advice to young web developers

采访

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
• 在您的面试中问公司的问题
• 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
  • 添加图像。 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 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!)
  • 管理您的时间
  • Take notes in class & rewrite them at home
  • Study hard subjects first & study in a quiet place
  • Read actively & slowly, before & after class
  • 做作业
  • 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 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.他们无需尝试就卖空了自己。 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到。 - 埃隆·马斯克（Elon Musk）

"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. - 苏格拉底

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)
• 将“您”放在CPU中
• x86-64 Assembly Language Programming with Ubuntu

Machine learning/AI

• 从头开始的变压器

数学

• ？ 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 solution
  • 清楚地写

指标

• 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

操作系统（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 have to trust in something — your gut, destiny, life, karma, whatever.这种方法从未让我失望，这使我的生活有所不同。

- 史蒂夫·乔布斯

表现

• Numbers Everyone 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." - 塞内卡

隐私

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

编程语言

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

只有两种语言：人们抱怨的语言，也没有人使用的语言。

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

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.
• ？ 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：构建，测试和调试正则

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.

功能标志

• 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

图书：

• 站点可靠性工程
  • 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

弹性

• ？ 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.准备系统设计采访。
• ？ 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

博客：

• 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)
• 设计数据密集型应用程序

文章：

• 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

建筑模式

• BFF (backend for frontend)
  • Backends For Frontends
• 断路器
• 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
  • 微服务

可伸缩性

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.
• 写测试。不多。 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备忘单
• git-tips
• 哦，该死，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".

网络开发

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
  • 原则
  • 样式指南
  • 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/
• 迪尔伯特
• 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

安全：

• Schneier安全
• 克雷布斯关于安全性
• 黑客新闻

Newsletters:

• Bytes (JavaScript)
• PyCoders (Python)
• POSTHOG

博客：

• kilimchoi/engineering-blogs

概念

词汇表

• BDD
• 盖定理
• 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