coding之外的3个日常：开会、提问和读书

对工程师思维习惯和工作方式的建议有很多，但在思维和行动之间往往存在着鸿沟，以至于很多方式被某些人视为原则，而被另一些人视为有用的废话。

例如 面向全栈的技术管理 ，这是我在一次中生代技术论坛的分享，其中的核心思想之一是全栈思维的时空观——

有些人称之为玄学，这可能就是抽象的缺陷。

“大道易得，小术难求”，这也是无可厚非的。对程序员来说，除了coding之外，可能还有3个日常活动：开会、提问和读书。这里记下老码农对这三个日常的一些理解，时光消蚀，聊胜于无。

关于开会

工作会议非常常见，如何开好一个会呢？

想要弄清为什么要开这个会？不要开务虚的会，务虚的会可以在酒桌上解决，会议室里都应该是务实的会。每个会要有明确的目标，围绕目标来促成具体的行动，每件事都要是明确的责任人和时间点，即schedule，会议的第一个输出结果就是会议既要（meeting minutes）。

开会之前，无论自己是参与者还是决策者，都要有所准备，对会议的内容有标注、点评、规划更好，至少要有个腹稿。作为召集人，要对会场的硬件设施负责，不论是投影、视频、会议电话，都要正常工作，不要浪费大家的时间。

作为参会者，绝对不能迟到，抱歉没有任何意义。会议中，不要使用手机，调到静音。没有必要的话，尽量少使用电脑，眼睛多看发言人，保持专注。

发言的时候，要有新的信息和洞见，有用的废话浪费时间。用建设性的态度发表不同意见，no solution，no comments，不做意气之争。用鼓励的语句和引导性建议来把问题展开，并落实到行动，例如“这件事我们一起来讨论一些具体的做法”等等。

会议的时间最好控制在一个小时，如果“三个月就是一年”的话，那么一个小时就相当于0.5天了，一般的问题都可以在时间内解决。如果2～3人的小会，最好控制在半个小时以内。不要开大会，也就是哪些多主题的会，本着“单一职责”的原则，理想状态是一个会解决一个具体问题，完成一个具体的目标，约取实得。

会议要选择一个仲裁者，一般是召集者或主持者，控制整个会议的进程，避免被某些人带偏，会议的目标被扰乱。不要总是头脑风暴，没有对事情负责的头脑风暴也是浪费时间。但是，会议结束前的闲扯是必要的，这往往是涌现创新灵感的时候。

总之，在会议中值得称赞的是，“这个事情由我负责。”

关于提问

问题总会遇到，碰到了问题，先要尝试自己解决，做一些调研，百度或者google或者stackoverflow....., 有时用一些高级一点的搜索选项，会提高一点效率。过于低级的问题，容易引起高手的不快。

选择能够帮助自己的人很重要，这需要一些自己对当前团队成员的了解，以及对相关团队成员的了解，简单的方式是问自己的mentor 或者manager。

然而，提出问题寻求帮助也不是一个容易的事。

当需要向别人寻求帮助的时候，先要明确一下时间，包括两部分，明确解决这个问题大概需要的时间以及对方什么时候有时间可以帮助自己解决问题，例如“午饭前或者午饭后，您是否可以抽出15分钟给我讲一下这个地方为什么要用动态代理呢？”

在具体提问的时候，要陈述清楚自己已经知道的背景信息，如果能够提出1～3个可能的解决方案或方向，可能更好一点。提问时不要有太多的感情色彩，尽量陈述事实，基于事实提问，提问的角度可以考虑5W1H或者5WHY。

在对方解答之后，要明确地表达自己学会了什么，进而表示感谢，刻意的恭维会让对方不舒服的。

关于读书

学无止境或者终身性学习，对于程序员而言更是如此。如今的学习工具和途径有很多，kindle/Pad 都可以浏览电子书。在开车的时候，可以考虑播客进行学习。

尽管视频教程和电子书有较为丰富的表现和较好形式，但个人还是喜欢读纸质书。阅读时间是最大的难题，大块的阅读时间是奢侈的。对个人而言，一天中有3个小时的时间都在上下班的路上，于是我这些时间称为地铁阅读时光。

虽然本着学以致用的原则，但是开卷有益。不论不是电子资料还是纸质书籍，有一个原则个人觉得是大有裨益的，那就是“不动笔墨不读书”。如果不能把一件事情讲清楚，说明自己没有真正的弄明白。如果有机会，团队内的分享是一个比较好的方式。如果没有这样的机会，当自己把理解的内容转化为文字的时候，同样可以帮助自己加深理解，同时还可能提出疑问，以及创新的思路。

对于精读而言，如果是外文原版，可以考虑把它翻译成文，收获会很大。但翻译实际上是一个技术活，真正能够让译文及格，要花费大量的时间和精力。去年翻译了一本关于计算机网络方面的书，个人感觉是经典，于是大半年的地铁阅读时光和若干个有限的周末都投入到了这本书的翻译上，这还是两个译者合作的结果。

动笔的克星是“懒癌”，治疗懒癌的方式可能是规律性强制要求，例如，每周至少写500字以上。

“业精于勤，荒于嬉。行成于思，毁于随”，让优秀成为一种习惯。