在邮件里表现聪明的15个技巧

在邮件里表现聪明的15个技巧

如果你不关心在邮件中表现聪明,就不要看本文了。

好吧,我们是孤独的。

在公司环境里,与电子通讯的肥沃土壤相比,没有什么更多产的地方来表现你的聪明了。你的邮件写作、发送和忽略技巧仅仅与打盹技巧一样重要,甚至比你的拷贝粘贴技能还重要。下面是15个小技巧,让你表现得聪明、有激情、专注,最重要的是,聪明。

1.抱怨你收到的邮件太多

邮件数量庞大

总是抱怨你的邮件数量,但是从来没有首次说出具体的数字。我抱怨过一次,因为我有200封未读邮件,我笑着走出了早餐厅。搞清楚其他人都有多少封邮件,然后说成他们的两倍。这就是你的邮件数量。

2.使用“发自我的手机”签名,为打字稿抱歉

使用“发自我的手机”签名,甚至你不是从手机发出的。这让你看起来总是很忙,在路上,还让你免除了校对。

可牺牲的架构

你坐在会议室里,凝视着你的团队在过去数年一直维护的代码。你已经做出了决定,你现在能够做的、最好的选择就是扔掉所有的代码,重建一个全新的架构。对于这些命中注定的代码、你投入其中的时间、此刻之前所做的那些决定,你该作何感想呢?

对于很多人而言,扔掉代码库是失败的象征,鉴于软件开发固有的探索性质而言是可理解的,但是,这仍然是失败。

不过,你现在能够编写的最好代码常常是你在数年之后要抛弃的代码。

架构是有寿命的

我们经常把伟大的代码视作永久的软件。作为一名编辑,我写这篇文章时的身份可追溯到1980年。对于软件架构是 如何减轻某种永久 做了很多思考。然而你的成功可以建立在代码之上,因为被送到了 /dev/null。

想一下网络上最成功的大型商务网站之一的、eBay的故事。它在1995年用了一周时间,从一堆perl脚本开始。在1997年,它推翻一切,在当时的windows工具之上,用C++编写的系统取而代之。然后到了2002年,应用程序用Java重写了。早期的版本因为它们被取代了就成为了错误吗?很难这样说。eBay目前仍然是web上最伟大的一个成功,但是成功的大部分因素是建立在90年代被抛弃的那些软件上。就像很多成功的网站一样,eBay已经看到了指数级的增长,指数级的增长对于架构不是友好的。支持1996年eBay的合适架构,对于2006年eBay来说,就不是合适的了。1996年的架构无法处理2006年的负载,但是2006年的版本太过复杂而难以建立、维护,它是根据1996年的需求演化而来的。

的确,这个原则可以引出工作的一种组织方式。在Google,大家熟知的要求就是设计一个满足当前10倍需求的系统,这暗示着如果需求超过了一个数量级,那么扔掉并从头做起是更好的。每隔几年就被重新设计与抛弃的子系统而言,这是非常普遍的。

的确,我们通常可以看到,刚接手一个成熟代码库的人们诟病架构的性能和可伸缩性。但是在软件系统的早期阶段,你不一定要确保它真正需要做什么,关注灵活性以应付功能改变是十分重要的,而不是性能或可获得性。随着你的用户越来越多,你需要切换优先级了,不过让太多用户处在一个低性能的代码库,通常是优先级较高的问题,而不是优先级低。Jeff Atwood发明了一句话“性能是功能”,一些人把它理解成性能总是第一优先级。但是任何功能只是你不得不从其它功能选出的。这不是说,你应该忽视性能之类的工作——软件可以变慢、不可靠到断送一个业务——但是团队不得不与其它需求做出痛苦的抉择。通常有更多的业务决定,而不是技术上的决定。

那么这意味着要故意选择一个可牺牲的架构吗?本质上它意味着接受,因为若干年后你将(如果顺利的话)扔掉当前创建的东东。这说明了要接受你堆放在一起的、跨功能需求的限制。这也说明了现在需要考虑,当这一刻到来的时候,如何能够让其变得容易——软件设计师很少考虑如何设计他们的创造,以支持将来的优雅替换。这也意味着在相对短的时间内被扔掉的软件,仍然带来了很大的价值。

明白了你的架构是可牺牲的,不代表要放弃软件的内部质量。通常,被牺牲掉的内部质量,将比替代时间更早地伤害到你,除非你已经工作在行将退役的代码库上。良好的模块化是健康代码库的关键部分,模块化通常在替换系统时起到巨大的帮助。对于系统的早期版本,要做的最好的一项工作就是搞清楚什么是最好的模块化结构,为将来的替换做准备。虽说在早期牺牲一整个系统是合理的,但是如果具备良好的边界,随着系统的增长,牺牲单个模块是更有效率的。

处理这个问题时,容易忽略的一个方面就是结算。是的,真的如此——我们已经陷入 人们不情愿替代一个明显的、不可行的系统...

用JavaScript实现数据可视化

现在很难忽略我们生活中数据的重要性了。数据对于人类历史中的最大的社会组织是至关重要的,最不济它能影响到我们的日常决定。它的集合具有世界范围内的地缘政治影响。然而忽略数据本身貌似正变得更加容易了。我们的调查显示,我们系统收集的99.5%的数据被浪费了,从来没人有效地分析过它。

数据可视化是填补这一空白的工具。

有效的可视化澄清;它们把抽象的古董(熟知的数字)转换成浏览者快速领会和理解的形状和图表。事实上,最好的可视化,是在潜意识地传递这个理解。浏览者立即就领会了数据——不用思考。这种呈现把浏览者解放出来,让他们更加专注地考虑数据的意义:它讲述的事实,揭示的见解,甚至提供的警告。当然,它定义了最好的沟通类型。

如果今天你正在开发网站或web应用程序,就有一个表达数据的好机会,这些数据需要良好的可视化。但是,你怎么知道哪种可视化是合适的?甚至更重要的是,你该如何真正创建?这些问题的答案正是本书的核心。在下面的章节里,我们探索了很多可视化、可视化技术与工具集。每个例子讨论了可视化的适用范围(建议了可能的替代产品),并提供了把可视化包含在你自己网页里的、一步一步的操作。

为了让你快速了解这本书,我们对于 这本书是什么、以及不是什么 做了简介。

实现 VS 设计

本书没有教你如何设计数据可视化。老实讲,其他作者比我们更有资格做这项工作。(比如,你一定比Edward Tufte做得差多了)不过,我们关注实现可视化。适当的时候,我们从稍微宏观的视角讨论下具体的可视化策略的适用范围,不过我意识到,有时候老板绝对坚持饼图。

代码 VS...