关于持续无中断工作小时数的影响

1) 为什么需要专注

        - 持续无中断工作时间的长短与最终的产出量之间有什么关系

                如果在某个小时之内你的工作被打断,那么这就不能算作一个工作小时。DeMacro与Lister曾经对此做过研究。他们提出了下面的测量尺段。

        根据自己的编码工作经历,他们记录下在某种情况时的E一因子的变化范围是0.10~0.38。为了完成相同的任务,在前一种环境中人们需要付出的出勤总时数,是后一种环境中的3.8倍。这只不过是对中断产生后果的一种非常粗糙的估算。

        - 而如果要更为精确地对这些信息做出分析,就还需要考虑到每次中断产生的影响的后续作用。为此,DeMacro 和 Lister 引人了“状态恢复时间”的概念

        假设每个打入电话的持续时间为5分钟,而在被打断后，你为了能够重新恢复到接电话之前的状态,需要经过 15 分钟,那么每个电话总共占用的流程时间(工作时间)将是 20分钟这样,哪怕只接十来个电话,你就要为此浪费半个工作日的时间。要是再加上十来次其他形式的打断,另一半的工作日恐怕也将难保。正因为如此,“从上午9点到下午5点之间,你根本就别想做成什么事。”

2）通过了解一下浅显易懂的道理而不是复杂的理论

        - 对专业人士来说,有哪些重要问题

         和其他计算机业内人士一样,Floyd自己也致力于发明新的范式提炼现有的范式,以及将各种范式明白无误地传授给下一代程序员我相信他的这些业绩足以使他获得图灵奖

        我想对那些严肃的程序员这样说:在每个工作日中，花一部分时间来考察、精炼你的工作方法。虽然程序员们总是要赶在最后期限之前完成工作(当然也可能已经过了最后期限还没完成工作),但在方法论上的提取和精炼将是一笔明智的长效投资

        我尤其乐见的是,他利用领奖的机会向大家展示了自己内心的工作机制--也许这能叫做种“元范式”,因为这就是Floyd如何能够创造出这么多饱含智慧的业绩的奥秘。

        1.使用类比，把计算机的处理过程与人类机构中的处理过程联系起来,对比研究

        2.在解决复杂的问题时,并不是仅仅得到一个解法就满足了，而是反复追溯自己的思路

        3.从特殊案例中推出普遍规则，并且利用其他特殊案例检验这些普遍规则;

        4.阅读其他人的范式

        5.阅读别人的程序,尽量扩展自己的理解能力,专门去读懂那些写法奇特”的人的代码，从而在读程序时取得更多的收获

        6.尝试跟别人交流范式，或者把自己的范式教给别人，以此进步澄清自己的思想

        7.积极地调查别人此前的工作成果，而不是重新发明一切

        8.把别人的工作看做一个出发点，就此对自己提问:“我会怎样发明这个东西?”