读程序员的README笔记01_学习如何学习
发布时间 2023-12-05 06:53:42作者: 躺柒
1. 核心领域中所需要的能力
1.1. 技术知识
1.1.1. 技术知识
1.2. 执行力
1.2.1. 过用代码解决问题来创造价值，并且你了解你的工作和业务之间的联系
1.3. 沟通能力
1.3.1. 能同时以书面和口头的形式进行清晰的沟通
1.3.2. 能以建设性的方式提出问题和定义课题
1.3.3. 文档化你的工作
1.3.4. 撰写清晰的设计文档并征求反馈意见
1.3.5. 与他人打交道时，你富有耐心和同理心
1.4. 领导力
1.4.1. 能在指定的工作范围内独立地完成工作
1.4.2. 能迅速地从错误中学习
1.4.3. 能很好地处理变动和模糊的问题
1.4.4. 积极参与到项目和季度的规划中
1.4.5. 能帮助新的成员融入团队
1.4.6. 可以向你的管理者提供有意义的反馈
2. 能力的4个阶段
2.1. “无意识的无能力”
2.1.1. unconscious incompetence
2.1.2. 意味着你无法胜任某项任务，并且没有意识到这种差距
2.2. “有意识的无能力”
2.2.1. conscious incompetence
2.2.2. 意味着你虽然无法胜任某项任务，但其实已经意识到了其中的差距
2.3. “有意识的有能力”
2.3.1. conscious competence
2.3.2. 意味着你有能力通过努力完成某项任务
2.4. “无意识的有能力”
2.4.1. unconscious competence
2.4.2. 意味着你可以很轻松地胜任某项任务
3. 坎宁安定律
3.1. 定律认为：在互联网上获得正确答案的最好方法并不是提出问题，而是发布错误的答案。
3.2. 建议你在团队中用文档记录下会议的内容、入职流程和其他口口相传的东西
3.3. 重点并不是要写一份完美的文档，而是要写得足够多，以引发讨论，充实细节
4. “自行车棚”(bike-shedding)效应
4.1. 过度集中在细枝末节上的讨论总是会很冗长，这种现象被称为“自行车棚”(bike-shedding)效应
4.2. 是西里尔·诺思科特·帕金森的一则寓言故事
4.3. 该寓言描述了一个被指派到发电厂对该发电厂的设计方案进行评审的委员会的故事
4.4. 对该委员会来说，因为发电厂的设计方案过于复杂，以至于无法讨论出什么实际的内容，所以他们花了几分钟就批准了这些计划
4.5. 他们又花了45分钟来讨论发电厂旁边的自行车棚的材料问题
5. 试炼
5.1. 大多数新入行的工程师在开始时都有技术基础，但没有什么实质上的经验
5.2. 在你的成长过程中，持续学习是至关重要的
5.3. 多报名参加技术讲座、午餐会、阅读小组、导师计划
5.4. 你着手开发大一些的任务和特性就意味着你进入了“贡献者之角”
5.4.1. 团队会信任你能更独立地完成工作
5.4.2. 参与到代码评审中去，做好队友会询问你的想法和反馈的准备
5.5. 当你参与到更大的任务中时，你将会学到如何向客户交付代码
5.5.1. 当你参与到更大的任务中时，你将会学到如何向客户交付代码
5.5.2. 你需要使用监控指标、日志和跟踪工具来实时调试软件
5.5.3. 你也可能需要参与轮流的On-Call
5.6. 你的团队现在将依靠你来负责一个小项目
5.6.1. 需要撰写一份技术设计文档并帮助团队进行项目规划
6. 学习如何学习
6.1. 自觉阶段
6.1.1. 校外学习是一种技能
6.1.2. 万事都求人”和“独行侠”之间取得平衡
6.2. 学习将帮助你成为一名合格的工程师，并在未来的日子里持续进步
6.2.1. 如果你不学习，你就会落后。
6.3. 前置学习并不意味着要整天坐在那里阅读文档
6.3.1. 在实践中学到的东西要比只坐在那里单纯地阅读学到的多出许多
6.3.2. 你应该上手编写并且发布代码
6.3.2.1. 错误是不可避免的。成为一名软件工程师的路途艰辛，我们有时会失败
6.4. 运行实例代码可以真正地了解代码的工作原理
6.4.1. 调试器是你运行实例代码时最好的朋友
6.4.2. 可以用它来暂停正在运行的代码，然后查看运行中的线程、堆栈信息和变量的实际值
6.4.3. “谜之行为”通常都是由正在被调用的程序是旧版且你修改的内容没有生效造成的
6.5. 请每周都花一部分时间去阅读
6.5.1. 团队文档
6.5.2. 设计文档
6.5.3. 请从团队文档和设计文档入手
6.5.4. 代码
6.5.4.1. 代码从不说谎。注释有时却会。
6.5.4.1.2. 去读源代码，因为它并不总是与设计文档相吻合
6.5.4.1.3. 不要只读你自己的代码库，还要去阅读高质量的开源项目，特别是那些你使用的类库
6.5.4.1.4. 请利用你的IDE来浏览代码
6.5.4.1.5. 为关键的操作绘制控制流和状态图。仔细研究代码的数据结构和算法
6.5.4.1.6. 留意那些惯用写法和风格，也就是去学习“本地方言”(local dialect)
6.5.5. 积压的任务票
6.5.5.1. 旧的任务票大概分为三大类
6.5.5.1.1. 不再相关的
6.5.5.1.2. 有用但次要的
6.5.5.1.3. 过于重大且无法立刻解决的
6.5.6. 论文
6.5.7. 书籍
6.5.8. 技术网站
6.5.9. 出版物和在线资源是互补关系
6.5.9.1. 出版物大多很可靠，只是有些过时
6.5.9.2. 在线资源则正好相反，不那么可靠，但很能跟上潮流
6.5.9.3. 采用保守一些的技术选型是有益处的
6.5.10. 这些文档会就事情是如何组合在一起的给你一个整体的概念
6.5.10.1. 不要试图一下子把所有东西都读完
6.6. 观看讲座
6.6.1. 可以用1.5倍速甚至2倍速观看视频，以节省时间，但不要被动地观看
6.7. 适度地参加会议和聚会
6.7.1. 会议和聚会非常有利于建立联系和发现新的想法
6.7.2. 那些有价值的内容与所有内容的比例——也就是信噪比，通常都很低
6.7.3. 学术会议有很棒的内容，但阅读论文和参加小型的、更有针对性的聚会通常会更好
6.7.4. 对于想获得实用技巧和想会见有经验的从业者的人来说，那些基于兴趣的聚会非常好，可以找几个这样的聚会去参加一下
6.7.5. 供应商展示会一般是较大和较吸引眼球的。它们是大型科技公司的营销工具，但不适合学习
6.8. 如果你开始觉得你不再有学习进展了，可以去当地大学看看
6.8.1. 他们有大量向公众开放的项目
6.8.2. 扩大你的圈子，接触新的想法
6.8.3. 去上研究生是一个可选项
6.9. 跟班学习并同有经验的工程师结对
6.9.1. 跟班学习并同有经验的工程师结对
6.9.1.1. 跟随者是一个积极的参与者
6.9.1.1.1. 他做笔记并提出问题
6.9.1.2. 随一名高级工程师是学习新技能的好方法
6.9.2. 结对编程(pair programming)也是一种很好的学习方式
6.9.2.1. 两名工程师一起写代码，轮流打字
6.9.2.2. 这需要一些时间来适应，但这是相互学习最快的方式之一
6.9.2.3. 结对编程也不仅仅是针对初级工程师的，所有级别的队友都可以从中受益
6.10. 用副业项目实践
6.10.1. 从事副业项目会让你接触新的技术和想法
6.10.2. 当你只有自己工作时，你可以跳过那些被称为“软件工程”的环节（测试、运维、代码评审等）
6.10.3. 忽略这些方面可以让你快速地学习新技术，只是不要忘记在工作中还有那些“真实的”环节
6.10.4. 可以参与开源项目。大多数开源项目欢迎所有人贡献力量。这是一种学习和建立职业联系的好方法
6.10.5. 不要根据你认为你需要学习的领域来选择项目
6.10.5.1. 找到你有兴趣去解决的问题，并使用你想学习的工具来解决这些问题