The Effective Engineer How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact
目录
[隐藏]采纳正确的Mindsets[编辑]
聚焦于高影响力的活动[编辑]
- Leverage = Impact / Time
- 降低时间(提供个人的技能/开发效率)
- 增加活动的输出(提供更多价值)
- 转移到higher-leverage活动(选择高速发展的行业/优先级)
- 对工程师来说,时间才是最大的成本
- 愈早地改变愈好!(vs我之前的观点:Scale Up & Scale Out)
为学习优化[编辑]
- Adopt a Growth Mindset
- 根据指数增长原理,愈早改变愈好。尽快增长自己的base(人的学习能力在年轻的时候更强,年纪大了学习能力会退化)
- Dedicate Time on the Job to Develop New Skills
- 研究代码库中的核心代码
- 写更多的代码
- 阅读公司内部的技术资料
- 掌握你使用的编程语言
- 主动要求代码review
- 学习网上课程(?)
- 参与你感兴趣项目的设计讨论
- Work on a diversity of projects.(这似乎在外包行业才能做到?哈哈)
- 确保在新团队里你能够向大牛学习(避免那种你就是唯一的大牛那种情况)
- 无畏(勇于接手你不了解的代码,与“跳出舒适区”)
- 评论:跳槽换工作时,找那些能够让自己学到新东西的
- 问题是社招一般看最近3年的工作经验,并且我也不认可换领域就必须减薪(事实上,应该发展的是自己的元学习能力,而不是什么特定领域的知识点/工作经验)
- Always Be Learning
- 怎么走出去参加业内技术会议,认识大牛?
优先级[编辑]
- ToDo List(本周、当天、Working)
- 聚焦于能立即产生价值的(活动)
- 优先级是动态调整的
- 始终关注于“重要,但不紧急”的(那一天总会到来,一点一滴地积累准备,好过事到临头毫无准备)
- 但是人很难有长远的眼光、恒心、长年如一日的坚持(自律)
- 只有你喜欢和感兴趣的事情,你才能一直坚持
- “心流”、频繁中断的坏处
- 限制WIP的数量
- 用If-Then计划(自觉的条件反射?)打败拖延症
- 每天做好工作优先级的安排
执行[编辑]
加速迭代[编辑]
- 连续发布/连续交付
- “一天发布几十次... (当然,这只需要发布过程自动化即可以做到)
- 快速迭代是否只适用于Web系统的开发?如何针对嵌入式系统、或传统中间件做适配???
- CD是否意味着编程实践上需要从一个稳固的核心出发,可靠地增量开发?
- 反思,如果对于一个遗留系统,不可靠的增量只能意味着错误的设计和Bad Smells被慢慢累积... 所以需要逐步的重构?
- Move Fast to Learn Fast(会不会给自己太多压力了?)
- Invest in Time-Saving Tools
- Google的分布式build集群
- 用Python做快速原型,用C++做后期实际开发
- Eclipse这种大型IDE实际上不如Sublime更快速灵活(前提是先构建一个快速的命令行build工具)
- 这里的一个问题是:纯文本写HTML设计Web页面不够方便(尤其是页面布局比较复杂的时候)
- Shorten Your Debugging and Validation Loops(优化工作流)
- 备注:有没有一个可以从JS代码中自动删除log语言的自动化工具?(注意,Android开发下的Gradle支持这么做)
- “One common type of bottleneck is dependency on other people”
度量你想要提高的(正确的metrics!)[编辑]
- Google的搜索质量团队
- 如何衡量用户的快乐?“long click”(后来的社交网络反其道而行)
- “Average response times vs. 95th or 99th percentile response times.”
- “Instrument Everything to Understand What’s Going On”
- “Open-source tools like Graphite, StatsD, InfluxDB, Ganglia, Nagios, and Munin make it easy to monitor systems in near real-time.”
- Internalizing useful numbers(预估单个系统的IO/响应性能/容量上限?)
- Data abuse:Be skeptical
早期&频繁地验证你的想法[编辑]
- Cuil:buggy、slow、pathetic!
- 对产品进行早期验证!
- Optimizing for feedback ASAP
- MVP
- Dropbox:制作一段4分钟的视频
- 新网站UI设计:fake页面有点滥用用户的信任了
- “Obama’s campaign email test”(怎么不担心小样本误差的)
提高你的项目估算技能[编辑]
- 分解为更小粒度的任务
- “Think of estimates as probability distributions, not best-case scenarios.”
- Budget for the Unknown:
- 编写单元测试
- 推行编码规范
- 被客户的高优先级的其他事情打断
- 某些未预期的技术难题的Debug
- 可扩展性问题
- 中途的人员流失
- 为降低二进制尺寸,重写UI而不是直接使用第三方库
- 代码库迁移(可归到管理类问题)
- 定义specific project goals,而不是简单的rewrite(后者很容易又会变成需求泛滥的mess)
- “Even more effective than defining specific goals is outlining measurable milestones to achieve them.”
- Reduce Risk Early
- 降低集成风险:“build end-to-end scaffolding and do system testing earlier”
- Incremental/Phased Rewrite
- e.g 把C#写的Writely移植到Google内部的Java基础架构上,先移植再重构
这部分主要是跟项目管理有关的。
建造长期价值[编辑]
平衡质量与实用主义[编辑]
- Establish a Sustainable Code Review Process
- 早期检出bugs和设计缺陷
- 防止dirty monkey patch
- better code(正向激励)
- 共享代码库知识
- 并不需要强制要求代码在提交之前一定经过review,可以推迟到产品发布后再review也是可以的(review作为接下来的refactor指导)
- “Newly hired engineers may reason incorrectly about code, pattern-match from bad code, or start re-solving similar problems in different ways”
- Manage Complexity through Abstraction
- Map-Reduce框架
- 自动化测试
- “Writing the first test is often the hardest.”(能够节省大量时间浪费的测试!)
- 技术债务
最小化运营负担[编辑]
- Instagram
- Simplicity(or:Do the simple things first):PostgreSQL + Redis/Memcache
- 这里的复杂性指的是实现复杂性?但感觉做好服务隔离理论上应该没有什么问题(除了一点,复杂的技术栈维护代码更高一点)
- 反面教材:Pinterest
- 奇怪,这里的Memcache与Redis为什么要同时使用???难道前者作为KV缓存比后者性能更好???
- Build Systems to Fail Fast(这说的是Erlang设计哲学吧?)
- “Relentlessly Automate Mechanical Tasks”
- e.g Facebook的最大的MySQL shards集群
- Make Batch Processes Idempotent
- 幂等 与 可重入
- Netflix的Chaos Monkey
- Google的灾难恢复测试
- 测试负载不均衡的情况
投资团队成长[编辑]
- On-boarding
- Higher ladder:不仅仅是看个人贡献,而要看对周围人的影响力
- “You’re a staff engineer if you’re making a whole team better than it would be otherwise. You’re a principal engineer if you’re making the whole company better than it would be otherwise. And you’re distinguished if you’re improving the industry.”
- 你的职业生涯的成功依赖于公司和团队的成功
- Make Hiring Everyone’s Responsibility
- interview:“高信噪比”?
- Share Ownership of Code(这是之前极限编程里的一个概念,代码的共享所有权)
- Build Collective Wisdom through Post-Mortems(进行事后原因分析,or 集体内省)
- e.g. NASA astronauts debrief after every simulation,Flight Rules
- 工程师文化
- 持续学习和改善