https://medium.com/swlh/my-productivity-life-mega-list-29-strategies-243f1b017600
https://major.io/2018/05/09/how-to-thrive-at-a-tech-conference/
https://www.yegor256.com/2018/10/16/dont-make-me-guess.html
Put yourself in the shoes of a new hire at your company. A new hire doesn’t walk in automatically knowing your culture. They walk in—filled with anxiety—hoping for success, fearing failure, and they look around. They observe their environment. They see who is succeeding, and they try to emulate that behavior. They see who is failing, and they try to avoid that behavior. They ask the question: what makes someone successful here?
The people around you shape who you are. They shape your behavior, your habits, your thoughts, your opinions, your worldview. Culture is really a feedback loop, and we all contribute to it.
In my opinion, a strong engineering culture is comprised of three parts: the right people, the right processes, and the right priorities. The right people means people that align with and protect your values. Processes are how you execute—how you communicate, develop, deliver, etc. And priorities are your values—the skills or behaviors you value in fellow employees. It’s also your vision. These help you to make decisions—what gets done today and what goes to the bottom of the list
An effective way to build rapport between teams is genuinelycelebrating the successes of other teams.
Equally important to understanding communication impact is understanding decision impact.
your decisions impact others. How does adopting X affect Operations? Does our dev tooling support this? Is this architecture supported by our current infrastructure? What are the compliance or security implications of this? Will this scale in production? Doing something might save you time, but does it create work or slow others down?
Empathy is being able to look at something through someone else’s perspective, and this requires removing your functional hat from time to time.
Part of being an effective communicator is being able to extract information from people and getting help without being a mental and emotional drain. This is especially true when it comes to debugging. I often see this “murder-mystery debugging” where someone basically tries to push off the blame for something that’s wrong with their code onto someone or something else. This flies in the face of the principle discussed earlier—be quick to take responsibility and slow to assign it. The first step when it comes to debugging anything is assume it’s your fault by default.
We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way. This learning and sharing is how organizations become more stable and more scalable over time.
As engineers, we need to be curious. We need to have a “let’s go see!” attitude. When someone comes to you with a question—and hopefully it’s a well-formulated question based on the earlier discussion—your first reaction should be, “let’s go see!” Use it as an opportunity for both of you to learn. Even if you know the answer, sometimes it’s better to show, not tell, and as the person asking the question, you should be eager to learn.
Being an engineer should mean having an innate curiosity. It’s not throwing up your hands at the first sign of an API boundary and saying, “not my problem!” It’s a willingness to roll up your sleeves and dig in to a problem but also a capacity for knowing how and when to involve others. Figure out what you don’t know and push beyond it.
The Psychology of Computer Programming
10 Commandments of Egoless Programming
http://xyproblem.info/
http://www.10tiao.com/html/680/201802/2655163209/1.html
主题先行
细节
http://www.10tiao.com/html/680/201802/2655163096/1.html
Keep the talking going
How about you?
Ask why?
Just ask
29. Make your communications clear and conciseEspecially being true for emails. Dot points are a life saver and allow people to quickly decipher what’s being said or requested. Beating around the bush or being overtly kind never helps. Conveying urgency, being firm and clear will get things done faster than going back and forth until the email chain is 30 emails long.
Yes, this does mean that you must do something to come out of your shell and start a conversation. This is still difficult for me. Here are some good ways to start a conversation with someone around you:
- “Hello, my name is Major” (put out your hand for a handshake)
- “Where do you work?”
- “What do you work on?”
- “Man, this line is really long.”
- “vim or emacs?” (just kidding)
The secret is to find something that makes you and the other person feel comfortable. There are situations where you might be met with a cold shoulder, and that’s okay. I’ve found that sometimes people need some space or the issue could be a language barrier. Making the attempt is what matters.
Evening events at conferences are a great way to keep the hallway track going while taking some time to relax as well. Some of the best conversations I’ve had at conferences were during evening events or vendor parties. People are more candid since the conference demands are often reduced.
Paul simply doesn’t know how to deliver information together with its context. And this is where we get serious.
This is the mistake so many programmers make, in my experience of dealing with them. When they deliver the question they have, they think that I, their listener, am right inside the same context as they are at the very same moment. They think that I’m sitting right now reading exactly the same blog post trying to open the same broken link. That’s why it’s a good moment to just tell me: “Hey, it’s broken!”
Is it a mental disorder or just negligence and lack of respect for the listener?
Honestly, I think it’s a bit of both.
I wrote some time ago that if I don’t understand you, it’s your fault. However, sometimes this “verbal terrorism” (isn’t that what it is?) has to be punished. Here is my short list of countermeasures:
http://xyproblem.info/
The XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help.
- Always include information about a broader picture along with any attempted solution.
- If someone asks for more information, do provide details.
- If there are other solutions you've already ruled out, share why you've ruled them out. This gives more information about your requirements.
Remember that if your diagnostic theories were accurate, you wouldn't be asking for help right?
https://bravenewgeek.com/engineering-empathy/Put yourself in the shoes of a new hire at your company. A new hire doesn’t walk in automatically knowing your culture. They walk in—filled with anxiety—hoping for success, fearing failure, and they look around. They observe their environment. They see who is succeeding, and they try to emulate that behavior. They see who is failing, and they try to avoid that behavior. They ask the question: what makes someone successful here?
The people around you shape who you are. They shape your behavior, your habits, your thoughts, your opinions, your worldview. Culture is really a feedback loop, and we all contribute to it.
In my opinion, a strong engineering culture is comprised of three parts: the right people, the right processes, and the right priorities. The right people means people that align with and protect your values. Processes are how you execute—how you communicate, develop, deliver, etc. And priorities are your values—the skills or behaviors you value in fellow employees. It’s also your vision. These help you to make decisions—what gets done today and what goes to the bottom of the list
An effective way to build rapport between teams is genuinelycelebrating the successes of other teams.
Equally important to understanding communication impact is understanding decision impact.
your decisions impact others. How does adopting X affect Operations? Does our dev tooling support this? Is this architecture supported by our current infrastructure? What are the compliance or security implications of this? Will this scale in production? Doing something might save you time, but does it create work or slow others down?
Empathy is being able to look at something through someone else’s perspective, and this requires removing your functional hat from time to time.
Pull communication is pretty much just how to ask questions without making people hate you, a skill that is very important to be an effective and empathetic communicator.
The single most common communication issue I see in engineering organizations is The XY Problem. It’s when someone focuses on a particular solution to their problem instead of describing the problem itself.
- User wants to do X.
- User doesn’t know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
- User doesn’t know how to do Y either.
- User asks for help with Y.
- Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
- After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn’t even a suitable solution for X.
And when you do need to seek help from others—just like with The XY Problem—provide as much context as possible. So much of what I see is this sort of information trickle, where the person seeking help drips information to the people trying to provide it. Don’t make it an interrogation. Lastly, provide a minimal working example that reproduces the problem. Don’t make people build a massive project with 20 dependencies just to reproduce your bug. It’s such a common problem for Stack Overflow that they actually have a name for it: MCVE—Minimal, Complete, Verifiable Example. Do your due diligence before taking time out of someone else’s day because the only thing worse than a bug report is a poorly described, hastily written accusation.
First, it’s important to have an appropriate sense of urgency. If you’re not willing to hop on a Hangout to work through a problem or provide additional information, it’s probably not that important, especially if you can’t even take the time to follow up. With few exceptions, it’s not fair to expect a team to drop everything they’re doing to help you at a moment’s notice, but if they do, you need to meet them halfway. It’s essential to realize that if you’re piling onto a team, others probably are too. If you submit a ticket with another team and then turn around and immediately call it a blocker, that just means you failed to plan accordingly. Having empathy is being cognizant that every team has its own set of priorities, commitments, and work that it’s juggling. By creating that ticket and calling it a blocker, you’re basically saying none of that stuff matters as much. Empathy is understanding that shit rolls downhill. For those who find themselves facing drive-by questions: document everything and be proactive about communicating.
when you ask a question, you’re not entitled to an answer, you earn the answer. Hasty sounding questions get hasty answers. As engineers, we should not operate like a tech support hotline that Grandma calls when her internet stops working. We need to put in a higher level of effort. We need to apply our technical and problem-solving aptitude as engineers
Avoid being a Help Vampire. Before asking a question, do your due diligence. Think carefully about where to ask your question. If it’s on HipChat, what is the appropriate room in which to ask? Also be mindful of doing things like @all or @here in a large room. Doing that is like walking into a crowded room, throwing your hands up in the air, and shouting at everyone to look at you. Be precise and informative about your problem, but also keep in mind that volume is not precision. Just dumping a bunch of log messages is noise. Don’t rush to claim that you’ve found a bug. As a first step, take responsibility. And just like with The XY Problem, describe the goal, not the step you took—describe vs. prescribe. Lastly, follow up on the solution. Everyone has been in this situation: you’ve found someone that asked the exact same question as you only to find they never followed up with how they fixed it. Even if it’s just in HipChat or Slack, drop a note indicating the issue was resolved and what the fix was so others can find it. This also helps close the loop when you’ve asked a question to a team and they are actively investigating it. Don’t leave them hanging.
In many ways, being an empathetic communicator just comes down to having self-awareness.
Process is about repeatability and error correction.
We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way. This learning and sharing is how organizations become more stable and more scalable over time.
As engineers, we need to be curious. We need to have a “let’s go see!” attitude. When someone comes to you with a question—and hopefully it’s a well-formulated question based on the earlier discussion—your first reaction should be, “let’s go see!” Use it as an opportunity for both of you to learn. Even if you know the answer, sometimes it’s better to show, not tell, and as the person asking the question, you should be eager to learn.
Being an engineer should mean having an innate curiosity. It’s not throwing up your hands at the first sign of an API boundary and saying, “not my problem!” It’s a willingness to roll up your sleeves and dig in to a problem but also a capacity for knowing how and when to involve others. Figure out what you don’t know and push beyond it.
The Psychology of Computer Programming
10 Commandments of Egoless Programming
- Understand and accept that you will make mistakes.
- You are not your code.
- No matter how much “karate” you know, someone else will always know more.
- Don’t rewrite code without consultation.
- Treat people who know less than you with respect, deference, and patience.
- The only constant in the world is change. Be open to it and accept it with a smile.
- The only true authority stems from knowledge, not from position.
- Fight for what you believe, but gracefully accept defeat.
- Don’t be “the coder in the corner.”
- Critique code instead of people—be kind to the coder, not to the code.
Part of being a humble engineer is giving away all the credit. This is especially true for leaders or managers. A manager I once had put it this way: “As a manager, you should never say ‘I’ during a review unless shit went wrong and you’re in the process of taking responsibility for it.” A good leader gives away all the credit and takes all of the blame.
Be engaged. Coding is actually a very small part of our job as software engineers. Our job is to be engaged with the organization. Engage with stakeholder meetings and reviews. Engage with cross-trainings and workshops. Engage with your company’s engineering blog. Engage with other teams. Engage with recruiting and company outreach through conferences or meetups. People dramatically underestimate the value of developing their network, both to their employer and to themselves. You don’t have to do all of these things, but my point is engineers get overly fixated on coding and deliverables. Code is just the byproduct. We’re not paid to write code, we’re paid to add value to the business, and a big part of that is being engaged with the organization.
Empathy is having a deep understanding of what problems someone is trying to solve.
Changing your perspective is a powerful way to deepen your relationships.http://xyproblem.info/
http://www.10tiao.com/html/680/201802/2655163209/1.html
有简洁是不够的。简洁并不是我们沟通的目的，而只是方式。
沟通的目的是什么呢？是将信息高效地传达给对方，并在这过程中，保证信息不会「失真」，确保双方对信息的理解一致。
这就是「明确」的定义。那么，今天我们来聊聊第二个原则：明确，Specific。
我想，你一定见过这样的人：
- 把那份报告赶紧做一下，6 点给我；
- 那个客户的资料好了吗？赶紧发我一下；
- 你还不明白？你自己想想怎么回事。
还没等你回过神来「哪份报告？」、「哪个客户？」、「究竟怎么回事？」对方已经急匆匆地走远了。
我管这种现象叫做「知识的诅咒」：当你已经「知道」一个东西时，你就很难站在「不知道」的前提下，去思考问题了。
简而言之：当你在脑子里，将两个概念进行了联结 —— 比如将「张老板」称呼为「那个客户」—— 你就会下意识地认为：别人也会这样想。
你脱口而出「那个客户」的时候，你期望对方也在脑子里同步进行翻译：将「那个客户」转换成「张老板」。这是人天生的弱点之一。我自己也犯过同样的错误。
反馈，是确认信息传达无误最简单、也最有效的方法。原因很简单
所以，为了确保信息被正确无误地传递，最简单的办法，就是多加一个「反馈」环节，让 A 知道，B 所理解的信息，跟 A 心里所想的内容，是基本一致的。
最简单的反馈，就是用自己的话，概括和复述一遍信息。
所以，我在工作中，每次交代完一个任务之后，都会要求对方立刻用最简单的话概括：
- 我要你做什么；
- 为什么要做这个事情；
- 你需要怎么去做。
同样，一场会议开下来，每个人被分配到了任务，在会议结束前，我一定会让每个人站起来，用一句话简单讲一下「我要做什么」。
交接工作的时候，也要养成这个习惯：对方跟你说了什么，记下来之后，立刻问他：「我复述一遍，你听听看对不对。」
然后，结合第一篇「简洁」的内容，简要复述要点，这可以快速让双方建立共识。
有些讲沟通模式的书，可能会告诉你「结论先行」 —— 这其实不太准确。更严格的表述应该是「主题先行」。
主题是什么？其实，就是沟通过程中最关键的信息。它可能是结论，可能是讨论的话题，可能是核心问题，也可能是某个特别重要的消息，诸如此类。
跟我聊过的朋友，可能会知道，我是一个特别追求高效的人。所以，我跟别人交流的时候，一定会先思考：
- 我们这次要讨论的核心主题是什么？
- 有哪些话题是跟这个主题有关系的？
然后，再从这个核心主题，慢慢延伸、发散、演绎。譬如说：跟朋友探讨合作，我会这样说：我想跟你聊聊合作的事情。我这边呢，看法是……我希望从你这边得到的信息是……
然后，如果话题延伸向其他地方，比如背景，经历，故事，案例，等等，再顺藤摸瓜转移过去。
在这个过程中，时刻注意「核心主题」，时刻思考「现在讨论的内容，跟核心主题有什么关联？」那么，就可以掌控好整个沟
那么，先明确核心主题，再围绕主题进行讨论，就相当于给整场沟通，划下了一个边界和方向：对于每一句话，我们不但能够知道「它说的是什么」，还可以知道「为什么要说这句话」「这句话起到什么作用」。
这样，我们就可以更好地知道，我们应该如何理解每一条信息。举个例子：当你迷路了，看地图的时候，第一时间是找什么？肯定是找「你现在所在的位置」，对不对？
只有知道了现在身处的位置，再找到目的地，你才能建立起一整条路径，知道应该怎么走过去。
「主题先行」起到的就是这么一个作用：通过明确主题，为整场沟通定下基调，打下一颗楔子，从而，为后面所有的信息传达，找到一个有效的依托点。
这可以大大地节省沟通双方的认知资源。
为什么我们会觉得有些人说话缺乏逻辑？一部分原因，是因为过于发散，没有紧扣沟通的主题，所以信息会显得非常「零碎」。这时，就需要对方耗费大量的认知资源，将零散的信息拼凑起来，尝试着去理解。
请尽量避免这种情况。
下次沟通时，试一试，先直接抛出主题，再通过主题，去延伸到其他信息和话题上，并始终围绕主题进行。
这样，你能够更有目的性地传递信息，对方也能更好地知道，应该把这条信息，放在认知里的哪个位置。
这个法则，主要用在提问上。什么是封闭？举一个简单的例子：同样是问职业规划，对比这两个提问：
- L 先生，请问我适合做新媒体运营吗？
- L 先生，请问无任何经验能进互联网公司做新媒体运营吗？
显而易见，第二个提问非常明确、具体，我用一句话就可以回复他，他也可以得到满意的答复。
但第一个提问呢？我可能需要反复问他好几句话，花上十几分钟，才能大致了解，他究竟想问什么。
如果把一个问题，看成一个开口，那么，开口越大，意味着问题越模糊、越开放，这时，对方能够给到你满意答复的可能性，也就相应更低。
反之，问题的开口越小，就意味着问题越明确、越封闭，这时，对方只需要提供「你所需要的信息」就可以了。
显然，第二种情况下，你获得想要的信息的可能性，比第一种高得多。所以，当你向别人进行提问的时候，不妨参考 SPI 表达模型：
- S：我的背景（ Situation ）是什么？
- P：我所面临的问题（ Problem ）是什么？
- I：我需要获得的信息（ Information ）是什么？
然后，再用一个问题，将这三者结合起来。比如：
L先生，您好，我是某某专业毕业，无工作经验，但对互联网很感兴趣（ S ），我想进入互联网行业（ P ），请问哪些岗位比较适合零基础、无专业背景的人呢（ I ）？
这相对来说，就是一个比较明确、更好回答的问题。当然，如果能针对每一个要素，描述得更加完整，回答起来会更有针对性。很多时候，沟通的模式，其实就反映了一个人思维的模式。
提问、表达时过于模糊，不够封闭，很多时候，其实就意味着：你自己也没有好好思考，而是把这个思考的责任，甩给了对方。
沟通的场合，无论是批评还是褒奖，尽量落实到细节，这样可以减少不确定性。不仅仅是职业场合，平时沟通的时候，注意这一点，也能解决和避免许多问题。
如何落实到细节呢？可以参考 SBI 表达模型：
- S：在一个什么样的背景（ Situation ）下；
- B：你做了一件什么样的事情（ Behavior ）；
- I：这件事情给我造成了什么感受（ Impact ）。
譬如说，你想表达对一个人的批评，可以这样说：
- 小李，上周五的报告里面，你犯了一个错误，虽然不严重，但会显得你很马虎大意，下次请注意；
- 小张，上周末的会议中，轮到你作报告时，你讲错了一个数据，这令我感到你并没有特别用心地在准备报告，下次请务必注意。
这样，就非常清晰、明确地将你的感受，传达给了对方。同样，在日常生活中，这个模型也非常好用。
尤其是跟朋友、情侣闹矛盾的时候，如果能够不吵架、不诉诸人身，而是心平气和地将问题摊开来，告诉对方：你在什么时候，做的什么事情，使我产生了不好的情绪 —— 大多数的问题，都可以迎刃而解。
解决误会和矛盾的最好方法，就是把问题完全摊开来，展示在面前，再去寻求一致共识。
http://www.10tiao.com/html/680/201802/2655163096/1.html
那么，在你表达之前，不妨先问问自己：我要传达给对方的核心信息点，是什么？
你会发现，其实，把大量的篇幅和语言去掉，也不会影响这个核心信息点的表达。
所以，你会发现，关键不在于「只传达信息点」，而是在于：我所讲的每一句话，对传达核心信息点，能起到什么作用？
如果没有用，那就是冗余的句子，删掉。
养成这样的习惯：在讲话之前，先想一下：我要说的下一句话，跟我们讨论的主题有没有关系？会不会模糊了主题的核心？它是能加强对方对主题的理解，还是反过来，会让对方感到迷惑、无所适从？
这是一个艰难的过程，但请试着，把这个习惯内化，让它成为下意识的自动化思维。
你会发现，一旦你将思维切换成「信息点」，你所说出的每一句话，都是「重点」。不会再有大范围的偏差，也不会再有「讲重点」的情况发生。
为什么有些人，思维总是特别敏捷，讲话总是能紧扣重点、毫无废话？
并不是他们更加聪明，无非只是因为，他们时时刻刻在心里装着「信息点」，并围绕信息点去组织语言而已。
这里的前提是：在 30 秒钟内讲清楚一件事，包括前因后果，并且令别人产生兴趣 —— 这其实已经非常不容易了。
Keep the talking going
How about you?
Ask why?
Just ask
