keywords: Book CJKmainfont: KaiTi –-
A result then, is an artivact of direct business value. Working code, documentation, and definitive statements are all results. Anything else must be understood as fundamentally different.
然后是Focus，作者描述了工作中一个常见的场景：回邮件。阐述了为什么持续focus在当前的工作上要好于立即回复邮件（1. Distraction 2. We can forward to others 3. Keep promises to a minimum）。
最后是 deliver smaller results more often，也是软件开发里常提到的一个概念，至于优点嘛：
First, it turns a boring progress report into working, usable software. You won't have to merely tell the rest of the company how far along you are, you can show them. Secondly, promises of smaller value over shorter time are easier to keep. You are much more likely to accurately estimate one week's worth of work than you are one month's.
- Understand the problem.
- Write tests that fail (because the problem has yet to be solved).
- Solve the problem as quickly as you can, using your tests to know when you've solved it.
- Modify your solution for readability, conciseness, and safety by suing your tests to make sure you haven't broken anything.
- Commit your changes.
简单来说，就是test driven development 。核心思想就两点：
- Thinking before coding
- Separating "getting it to work" from "doing it right". It's hard to do both at the same time.
自我反思下，大多时候只做到了"getting it to work"，尬。越是到了项目后期，"doing it right"的代价也越来越大。当然，也不能走极端了（Don't over-engineer and know when to quit），然后引用了《重构》中的一句话：
[Refactoring is] restructuring an existing body of code, altering its internal structure without changing its external behavior.
这部分内容中，自认为需要改进的应当是 Plan your implementation 这部分。列清楚 TODO list，找人交流讨论实现，然后预估每部分的大致时间。
Whatever you produce here is for your internal use only and is designed to capture your thinking at a high level about how to solve the problem and what bases need covering. Once you dive into the code, you will focus on much smaller concerns. Your "plan" here is for those moments when you get done with something and stick your head up to see where you are.
Translating your work to non-technical people is a skill that can be more valuable than any specific technical knowledge you have. It's what makes a senior developer in the eyes of others.
- Empathize with your audience.
- Distill what you know in a way your audience can understand.
- Adapt Terms
- Avoid technical jargon of your own.
- Listen carefully to the words people use and ask questions if you aren't 100% sure what they mean.
- Don't "talk down". The other person is likely a highly intelligent person who is capable of understanding what you're explaining. Treating them like a child will only make things worse. (这点确实在太常见了)
- Don't be afraid to use longer descriptive phrases in place of acronyms or other jargon.
- Abstract Cepts to Simplify Them
- Avoid technical details
- Explain things using analogies; don't worry about precision
- Use diagrams, visual aids, or demonstrations where possible.
- Always offer to provide more details (这点已经听许多人说过了，挺受益的)
- If a question has taken you off course, spend a few seconds re-establishing the context of your discussion. (这个需要反复练习，一是得清醒地意识到off course了，二是根据问题重新澄清讨论主题)
- Be prepared to "justify" your position if challenged.
- **Remember, it's not the other person's job to understand you, it's your job to make sure they understand.
- Don't be afraid to stop and re-group if things are going poorly. Find a colleague you trust or respect who can (or already does) understand the technical information in question and ask how they would handle it.
- Identify Facts
注意区分 Facts 和 Opinions
- Identify Priorities
If someone remains unconvinced by your arguments, rather than assume the person is "not getting it", take a moment to consider if your argument really is lacking. Give everyone the benefit of the doubt. Is there a fact you got wrong? A priority ou haven't identified? **Your mission isn't to prove that you are right, it's to deliver the best results you can **.
还有一点非常值得学习：Document the decision-making process.
A document like this is useful for two reasons. First, it can prevent someone else from going through the trouble that you've just gone through. Second, it keeps you from having to remember the details whe, sixmonths from now, a new team member asks why things are done a certain way.
Three steps to better writing:
- Get it down
An outline, then each section.
- Revise it
- Instead of using demonstratives "this" and "that" or pronouns like "it" or "they", use the specific names of things, enven if it seems slightly redundant.
- Name objects, concepts and procedures as specifically as you can.
- Avoid acronyms, shorthand, jargon unless you are absolutely sure the reader will understand it. (这个必须吐槽，OneNote上各种缩写满天飞)
- Organize thoughts into paragraphs. (一段表达一个意思，避免所有内容都杂糅在一段里)
- Write as if the readers are getting more and more rushed for time as they read. 尽量开门见山
- Polish it
Visibility 除了体现在代码上之外，还体现在 Responsiveness。学会处理各种interruption。