彼得德鲁克的经典之作《卓有成效的管理者》里提到，知识管理者必须学会自我驱动、自我管理，而动力取决于工作是否卓越有效，是否有所成就。程序员就是典型的知识工作者，本文就是细数一下程序员的生存之道，或者说自驱之道。
03 提问的艺术
程序员骨子里的孤傲时常会把自己定位成一个问题终结者，提问题似乎与此格格不入。我到现在都没太想明白这种孤傲源自于哪里，也可能是知识工作者特有的清高。其实吧，大家日不离手的搜索引擎，不就是一种另类的提问么？
卜学良 子曰
亮子的中心思想是个Why，Why的表现是，搞不懂就问人，搞得懂就答人，没有人懂还可以问神...要懂得推理要心存怀疑，要充满好奇要巨细靡遗，要打破砂锅问到底。
Come on everybody!
全套流程建议的第一步是先把自己的问题明确化，并耗费一定的精力去研究琢磨，直到卡滞；第二步是不耻上问/不耻下问, 敢于开口去提问，不要怕丢人，面子相对于知识不值一提；第三步将自己的问题、自己研究的发现等等一并列出，给解答者一个完整的上下文和尽可能多的线索，以节省双方的大量时间；第四步，不管最终是否解决，可以基于解答者给出的方案或者方向，自己在想其他办法去深挖，补齐自己的只是短板。That's it.
心理专家亚瑟·阿伦有个著名的让陌生人快速熟悉的“36问”，就是好问题的模板，节选几个：
1、如果可以跟世上任何人共进晚餐，你会选择谁？
2、你会想出名吗？以什么样方式出名呢？
3、在打一通电话之前，你会先排演要在电话中说什么吗？为什么？
4、你心中最完美的一天是做哪些事呢？
5、你上一次唱歌给自己听是什么时候？上一次唱给别人听又是何时？
12、如果你明早一觉醒来发现自己获得了某种能力，你希望是什么能力？
30、你上一次在别人面前哭是什么时候？上一次自己哭是什么时候？
36. 说一个个人问题并询问对方的处理意见，让对方向你反馈，你对这个问题所表现出的态度。
DàYé啰嗦
以下的反面教材大家耳熟能详：
# 以他的能力和水平完全可以帮我解答这个问题，为什么他不肯帮我？
帮你是情分，不帮是本分，没有什么理所应当。程序员群体大部分时候是和谐互助的，当然前提是你的问题问到点上、足够清楚、有挑战、礼数到位或者红包打头阵，否则参见下面的细分场景。
# “大神救命啊，我用这个框架老是启动不起来。我可是严格按照手册一步一步来的！”
然后就没有然后了。你的详细线索呢，你怎么排障的呢，你有初步的怀疑对象么？这种卖惨式发问只会给人一种感觉：你自己压根没分析过！我的时间可不是浪费来解决你分内事情的。
#“字符集是UTF8的Mysql5可以存储emoji表情么？”
这种简单的问题要不自己去试，要不去搜，顺便把这块相关的知识点都去阅读一下。你指望某个人给你个答复的同时，还能把整个知识点给你解释一番？
#劈头盖脸的一堆问题怼出来，没有停顿、没有组织、没有循序渐进。
散弹枪式的发问极容易引起他人的反感，因为你把别人当成了答题人，而不是有来有往的虚心求教。适度且有节奏的发问才是王道。
# 发问前礼貌性的确认对方是否有时间帮忙，发问后不管是否解决都要表示感谢，礼数一定要到位。不要整成一次性买卖，毕竟因为一次不礼貌导致未来可能再难得到帮助，得不偿失。
# 有些人眼花缭乱的问题描述完全不在点子上，解答人若善于引导和抽丝剥茧，能从源头上帮忙解决，若只是纯粹的一问一答，那答案可能压根帮不上忙，因为问题本身的方向就错了。这种体现逻辑洞察能力或者沟通能力，下面会提到，要做到“直抒胸臆”不简单。类似的场景在程序员和产品经理之间也时常发生，聊的牛头不对马嘴，双方都找不到中间的那个契合点，冲突也就难免。
04 逻辑推理
程序员日常编码80%的工作除了想变量的命名，就是在写逻辑分支。而日常非编码80%的工作就是理解需求或设计架构，都需较要强的逻辑思维。
先玩个游戏：估算下中国有多少程序员(不严格定义边界)？
ttps://octoverse.github.com
基于GitHub的2018年度数据报告，目前一共3100万注册用户，20%美国本土用户，中国是仅次于美国的GitHub大户，打个八折，算出中国注册用户500万(无视不同程度的水分)。
https://www.idc.com/getdoc.jsp?containerId=US44363318
再按照IDC估算的全世界2200万左右软件工程师，按比例折算下中国码农群体 500万/1.4≈350万。
本人宣称对中国码农群体350万这个虚数负责到2019年年底。
参考链接：
世界人口(77亿)：https://www.worldometers.info/cn/
中国人数(13亿，就业人数7.7亿)：
https://www.ceicdata.com/zh-hans/country/china
以上是个典型的考察逻辑推理能力的小例子。《超级思维》这本书里面有更多奇奇怪怪的逻辑题目，都是让你感觉无从下手的。
其实，在拿到一个即使简单如APP登录的需求时，作为知识工作者的程序员就也需要展现出自身强大的逻辑推演能力，抽丝剥茧，将需求抽象为领域模型或者转化为系统设计。这方面有大量的方法论，比如奥卡姆剃刀，比如WBS，都不重要。重要的是你一定要沉心静气，不能是闷头苍蝇似的一通乱撞。要找到最适合自己、最适用当下的那个方法。是砍掉枝叶先看主干，还是抽丝剥茧层层拆解，都是逻辑推理的一种体现罢了。
DàYé啰嗦
APP登录过程究竟发生了什么，或者应该发生什么，是我面试时经常用来考察一个人逻辑思维能力的题目。除了是人都知道的用户名密码校验还有什么呢？
# 用户名的长度区间是什么？
# 用户名支持的字符集是什么？存储会乱码么？
# 密码的长度区间是什么？字符组合是什么？
# 密码的加密方式是什么？如何确保传输通道不会被中间人劫持？
# 用户名/密码是否含有非法字符(代码注入)、政治敏感、低俗不雅的文字？
# 密码最多可以输错多少次？超过后账户禁用多久？
# 是否支持用户多终端登陆？如果支持的话，账户在A终端被禁用后，在B终端的已登入态是否被踢出？
# 用户在终端的登录有效时长如何考虑的？
# 登录的错误提示有很多种，用户名不存在、密码错误、账户禁用，还有哪些？
还有很多没展开，如手机号/邮箱绑定，短信/邮件验证码验证，常用设备管理等等，可以继续推演下去，但是如果能在面试的压力环境下，有条不紊的罗列出用户名、密码、安全、状态、话术、用户体验面等等这些维度上的思考，那基本上没毛病。真实情况是不少人在这些维度上跳来跳去，没有条理性、延续性，想到哪儿是哪儿，只能说明逻辑推理上有所欠缺。
05 时间规划, 要事优先
我们身边不乏这种人：每日忙忙活活，勤勤恳恳，乐于助人，看起来是公司里最敬业爱岗的那个。实情却是大量任务一旦堆积到他手里就失去了进度，甚至因为同时赶很多任务，导致高优先级任务的质量不达标。这类人的典型问题就是做不好时间规划，分不清轻重缓急。
爱因斯坦老头的相对论告诉我们，时间是相对的。同样的每天8小时，有序、有效和高效的使用了这8小时的产出，可以比无序、无效和低效的产出高出2倍不止。核心点是什么呢？
DàYé啰嗦
# 让时间的无效流逝产生罪恶感
理解前先举个栗子。小时候暑假的前半段基本都是瞎玩，最后一周疯狂的写作业，连吃饭都觉得在浪费时间，如果吃饭的时候还在看电视，那时的罪恶感爆棚，时刻觉得我的作业还在等着我...所以明白了么，产生罪恶感的前提是我的任务是有优先级的，加上自己的责任感，一旦高优先级任务阻滞了，而我还在浪费时间在某个无意义的事务上，就会及时叫醒自己，阻止自己的继续浪费。
# 好记性不如烂笔头
曾几何时公司里的笔记本还是用来记事的，现在好像成了用来涂鸦的了。一般开会我都会要求大家都带笔记本，无他，我就是不信你的脑子记得住会议上的所有要点或者决议；而日常项目中有些重要的事项或者节点也都应该记录下来，项目上线前翻一翻确认自己没有遗漏；等等。当然上面说的这些你可能有其他的工具来实现，殊途同归罢了。
# 请学会拒绝
烂好人这种事情在职场基本是行不通的。因为你好，你的事情就会多而杂；因为你好，你的事情就都是高优先级；因为你好，流程规范就容易违反；因为你好，时间一长就成了理所当然，这事将永远粘着你；因为你好，任务积压到你手里，任务最终延期交付，你得背锅；因为你好，你就再也拒绝不了别人了，因为“雷锋”是不会也不该拒绝他人，会一直被道德绑架在十字架上。
06 心向自由, 遵纪守法
人是生而自由的，却无往不在枷锁之中。
- 卢梭 《社会契约论》
人生而自由，清高的程序员更加的心向自由。不喜欢西装革履，不喜欢一板一眼，不喜欢上班打卡，不喜欢规章制度...
每家公司都制定了各种各样的制度、规范、流程，这些东西经常被视为洪水猛兽，枷锁镣铐。只有不成熟的人才会把自由放在嘴边，成熟的人怎么会不知道
自由是要付出代价的！
* 上班时间是自由弹性的，结果可能是开敏捷站会的时候少一个人更新进度，因为你没来，这个代价谁来支付？
* 生产上线可以随意发挥，上挂了再上一次呗。如果一个面向C端用户的产品，你确定要让用户承担无法使用、公司承担损失用户的代价么？
* 数据权限是自由的，这样查数据方便多了，谁来承担数据被导出打包卖的代价？
* 开发私接需求，不走那套评审、设计和进入迭代的繁琐流程，测试不知道这块的回归内容，上线后出问题才发现，这个代价谁承担？
选择了自由，必须承担代价，也同时选择了责任。没有责任的自由只是小孩子过家家。所以在感觉自已被约束了之前，先扪心自问，自己是否有能力消解跳出框架的风险，是否有担当承担自由之后的代价。
