与其选择一个无趣的专家,不如选择一个富有激情的业余爱好者

标签: 选择 专家 选择 | 发表时间:2011-09-16 10:46 | 作者:36氪 熊
出处:http://dongxi.net/

任何一个故事之所以有趣都是因为激情。没有激情的故事只能沦为枯燥。我可以一连数小时听人谈论沙子、灰尘或马路,只要他们对这些东西富有激情。

记得孩提时代我曾见过一名歌手唱歌。她给我留下的印象非常深刻,我目不转睛。妈妈看到以后问我喜不喜欢那音乐。我说:“不怎么喜欢,但她有一种东西吸引我,让我离不开她。”

妈妈笑了笑告诉我:“是她的激情。她全神贯注,充满激情。这是她出类拔萃的原因。”

妈妈说得很对,此后我一直看到激情。在任何时候,与其选择一个无趣的专家,我更愿意选择一个富有激情的业余选手。

对你所做的事情充满激情会让你与众不同,这一点在商界也不例外。我感觉不到我在工作,因为我对我的工作充满激情。当午夜服务器宕机时我不会抱怨,而是想方设法把它修好。这是因为我满怀激情要把我们的服务提供给我们的用户。

在与人初次见面时,我想知道的第一件事是对方对什么富有激情。如果对方是创业者,我希望他们在谈到自己的公司时,我可以从他们眼里看到激情。

我曾在葡萄牙和职业单人帆船选手Ricardo Diniz一起吃饭。他现在对自己所做的每一件事情都充满激情。他很少把目光停留在吃的东西上,因为他不是满怀激情地谈论自己的旅程,就是hold不住、欲盖弥彰地表达如何爱坐在旁边的女友。显然,我只是备胎,只是灯泡。不过没关系,因为看到有人如此富有激情地生活是件好事。

有人认为激情让人尴尬,或者应该把激情埋在心底,甚至因激情而自责。完全没必要。把你的激情展示给你的合作伙伴、朋友、读者和客户,你将赢得他们的欢心。

拿出你的激情吧,就像个海盗

作者: Boris

除非注明,本站文章均为原创或编译,转载请注明: 文章来自36氪

  查看评论

相关 [选择 专家 选择] 推荐:

与其选择一个无趣的专家,不如选择一个富有激情的业余爱好者

- 地安门城管 - 36氪
任何一个故事之所以有趣都是因为激情. 我可以一连数小时听人谈论沙子、灰尘或马路,只要他们对这些东西富有激情. 记得孩提时代我曾见过一名歌手唱歌. 她给我留下的印象非常深刻,我目不转睛. 妈妈看到以后问我喜不喜欢那音乐. 我说:“不怎么喜欢,但她有一种东西吸引我,让我离不开她. 妈妈笑了笑告诉我:“是她的激情.

转载 选择

- bravusliu - caowumao的博客

CSS4 选择器

- iVane - 幸福收藏夹
CSS3 还没完全用上,CSS4 已经提上日程. 官方发布了 update to the working Selectors Level 4 spec,对选择器做了一些升级. 前端最大的优点就是技术更新快,可以经常学到新东西;最大的缺点也是技术更新快,要跟上潮流还真不是那么简单. 不过,这次更新有像“父选择器”这样让人兴奋的内容,让我们先睹为快,了解一下吧:.

JQuery 选择器

- - CSDN博客Web前端推荐文章
}

点击我

.    像上面这样把JavaSript代码和HTML代码混杂在一起的做法同样也非常不妥,因为它并没有将网页内容和行为分离,所以才有JQuery选择器的学习.

点击我

. //给class为demo的元素添加行为.

选择性闭嘴

- 蓓 - 土摩托日记
除了熟人之外,文青博客我追看的不多,总数不会超过10个,因为大多数这类博客的营养都欠奉. 一个是连岳,他的感情QA还是挺好看的,某些政论文字也还不错. 但这厮喜欢掺和科学的事儿,不止一次误导过读者. 就拿地震预报来说吧,他哪有资格评论. 看看这个报道,今天距离这则报道正好过去了两个月,可预报的地震仍然没有发生.

mysql选择索引

- - CSDN博客数据库推荐文章
1、尽量为用来搜索、分类或分组的数据列编制索引,不要为作为输出显示的数据列编制索引. 最适合有索引的数据列是那些在where子句中数据列,在联结子句中出现的数据列,或者是在Group by 、Order by子句中出现的数据列. select 后的数据列最好不要用索引. 2、综合考虑各数据列的维度.

jsoup select 选择器

- - 编程语言 - ITeye博客
采用CSS或类似jquery 选择器(selector)语法来处理HTML文档中的数据. 利用方法: Element.select(String selector)和 Elements.select(String selector). Jsoup的元素支持类似CSS或(jquery)的选择器语法的查找匹配的元素,可实现功能强大且鲁棒性好的查询.

我为什么选择MongoDB

- Caiwangqin - 超群.com的博客
我在选用一些技术的时候大多考虑这些方面:. 新的方案能不能解决目前项目中难以忍受的问题. 见过很多的项目为了解决一个稍显复杂的问题引入一个更加复杂的方案,着实累人. 新的方案能不能很平滑的应用到项目中去. 在mongodb之前,我碰到的问题是:. 项目的需求不断变化,数据库表结构需要不断调整来满足新的需求,FriendFeed用的是schema-less方法来解决这种问题,但是schema-less也有一些问题,在设计时候需要考虑动静分离,要不然为了更新某个小数据需要频繁的更新整个大数据块会比较烦躁,数据的一致性和有效性需要在代码中特别注意.

MVC就是个选择题

- Dash - Becomin' Charles
由于采用了Web开发框架来开发项目,所以我首次在真正的项目中采用MVC的开发模式. 随着项目的不断深入,我也在不断反思,MVC设计模式到底给项目带来了什么. 听起来都很难听对吗,但是确实如此. 清晰的代码结构,易于维护,易于扩展. 当然,我不是在批判MVC,只是觉得,在使用MVC过程中,还是需要投入更深入的思考,到底怎样才能用好这个设计模式.