原文地址:Mental Heuristics 启迪是经验法则，它通过指示思考的方向来帮助人工智能程序或人类更有效地进行思考和行动。它们有些是古老的智慧，虽有陈词滥调之嫌，但实际上大部分是有帮助的。 如果你想完成什么事情，那么就亲自去做 注：这是很明显的道理，亲自去做对你的自尊很有好处。有相当数量的工作可以通过这种方式来完成，而不必总是依靠专家。然而，事必躬亲是应该避免的－－毕竟我们都还需要其他人的帮助。 永远不要拖延任何你能够马上做的事情 注：很好很强大。有许多事情不费吹灰之力就能搞定，但却往往被我们推到不重要的一边。遗憾的是，他们不会自动消失，我们很快会为没有完成它们而感到内疚，这种情绪令我们更加不可能解决问题。 当你有几件事情可以做，却不知道做哪一件时：拿起其中任何一件做就是了！ 注：如果你在两个或更多的可能性之间不定主意，那么此时它们之间的差异无关紧要。然而，大多数人在这种情况下会犹豫不决（弗里德金悖论，译注：两个可选方案越是具有同等吸引力，二者选一的抉择就越困难，尽管在相同程度上，这种选择的影响也越是微不足道）。如果你意识到这一点，你只要随机地或按照某种标准方法任选一个就行了。 总是假定你会成功 注：如果你不渴求成功，那么就不会尽自己最大的努力，并且注意不到可能的解决方案。而假如你感觉自己终将成功，那么就会倾注全力解决难题。当然，尝试去做那些你做不到的事情是不可取的，一定的自知之明必不可少。 如果你解决不了，那么就改变规则。 注：记住，没有分不出输赢的局面。 如果你对某事无能为力，那么大可不必去担心它。 注：担忧是一种负担，而且在大多数情况下于事无补-只不过浪费精力罢了。与其为某事担忧，倒不如去做点什么或者是找出解决问题的方法。面对这种情况的一个有用的办法是，在纸条上写下你的忧虑之事，然后丢进一个盒子。每到一周左右，打开盒子看看，那些忧虑之事能否解决。 为了快速解决问题，不要依赖有意识的决定 – 只管去做 注：有意识的大脑慢得出奇，有意识的选择和行动有巨大的延迟时间（本能反应只要数十毫秒，无意识的条件反射大约需要100毫秒，有意识的选择需要几秒钟）。清醒大脑的职责，通常是抑制而不是开始行动。在紧张的条件下，如果你对自己所做的事过于清醒，你就会犹豫不决或行动缓慢。 学会依靠您的非清醒大脑是个好主意，因为清醒的大脑是缓慢的，而且带宽很低。而我们头脑中的其他系统具有巨大处理能力，它们实际上在做着大部分的真实工作。 不要为自己的行为开脱 注：有时，由于害怕难堪、愤怒或有损形象，我们不愿意当众说明我们做某些事情的真正动机。尽管如此，我们也不应该自欺欺人地粉饰真实动机。这种故意误导只会减少对自我的认识，而了解自己的真实动机往往价值非凡（哪怕你不喜欢，甚至永远也不公开承认它们）。 听从你的直觉，但不要无条件地相信它 注：直觉或感情用事，类似“直接感受”或“灵光乍现”有时能给我们新奇的见解或从一个新的方向显示出问题。可惜这种方式并非总是可靠，而且经常完全错误！这样的见解不应该被接受，因为你欣赏它们的美丽，抑或是它们的直观，只是因为它们与现实情况相符。
正在浏览 翻译 里的文章
原文地址: How To Avoid Coding Yourself To Death 你的老板是否为你抠腚抠到死而感谢你？一文反映了在软件行业频繁发生的“过劳”现象日益严重。我的经验表明，以下几点把“按时交付软件”和“增加软件开发者的工作负荷”二者给弄混了。不幸的是，它伴随着许多项目在一直不断地发生，直到我们感觉似曾相识。 预估不切实际 某天你收到一封email说道：“嗨，我们的产品需要X、Y、Z功能，我们相信你能够在月底之前搞定，因为这是客户所期望的。谢谢。”虽然我可能是夸张了一点，问题就是，估算和许诺你不了解的工作是很荒谬的。软件估算是一件艰难的事情，唯一能够尽可能接近实际的人是那些从事该工作的开发者。不切实际的预估只能增加开发者身上的压力，他们最终要加班 。 对于任何一个需要按时交付的软件项目，必须应由开发者来进行估算，而估算需要一些思考（基于证据的进度安排）。 交流鸿沟 业务团队和客户之间的沟通必须要明确需求。而这往往是不可能的，因为在很多时候，客户自己并不清楚他们需要什么。在其他时候，双方之间存在着一个交流鸿沟，真实意图往往不能被理解。这意味着，需求有可能会变化。这种沟通鸿沟将增加开发者的待办事项，他们最终要加班 。 为了避免这种情况，随着项目进展，开发者可以试着确保需求得以明确。这可能意味着要对已开发的软件做出修改，但现在改变总比产品开发完了再改要好。聪明的开发人员还会尽力做出一个非常灵活的设计，以便能够轻易经受改变。 如果你处在一个离岸外包模式下，为了避免进度差错，在海外团队和现场团队之间的沟通也很重要。问题要尽可能快地解决。在这种情况下，不同的时区也会发挥作用。 开发死板 开发者一旦得到需求，他们就开始在产品中创建那些功能。“啊”，开发者会说，“我们有充裕的时间。我们得小心地确保完成所有的需求。”这听起来确实不错，而唯一的问题是，需求是不固定的。所以，你所做的并非他们想要的。当需求变化（在大多数情况下如此）时，你必须从头开始。言归正传，这种僵化的开发方式，给你和你的团队带来了额外的工作时间 。 避免这种情况的一个好办法是，使用类似跟踪子弹技术的方法，尽可能快速地交付功能。这有助于客户检验一些东西，指明其是否符合他们的要求，并提供反馈意见。不过要小心，必须向客户说明，这只是一个不完整的版本，并且有可能包含Bug。而你怎么能在如此之短的时间内开发项目呢？你做不到，不过也许你可以一次提交一小部分功能。良好的开发人员可以使这一切成为可能，并确保他们不会在项目后期加班。 测试不当 你的软件的第一个版本已经开始让测试人员进行测试。但是，只有一个测试人员，而这个可怜的家伙正在加班 。不好，他刚才错过了一些用例。目前一切正常，产品交付到客户手中。一天，客户的荣誉侦察——一直运行的网站突然down机了。开发人员被电话通知前来查明生产系统上的问题，这是一项耗时的工作，他们被迫加班 。终于他们找到了问题所在，但这本来是一个可以在系统测试过程中发现的问题。 良好的测试很重要，甚至比软件开发还重要。如果测试不当，会延误Bug的检测，并且增加在项目晚期修正他们的困难。重大Bug应该立即报告并加以修正，甚至不惜以限制开发进度为代价，直到问题解决。如同优秀的开发人员一样，优秀的测试人员同样需要在项目开始阶段，识别和检测出重大问题，这对整个团队是件好事。因为它减少了在项目后期加班的可能性，特别是由于修改Bug而加班的情况。
订阅
更多阅读器 >>
最新评论