每一个人都有精彩的故事

原载:https://knewone.com/entries/55a35b6031302d78e8ea0200?from=groupmessage&isappinstalled=0

冒志鸿

自我介绍

我是冒志鸿,是互联网和社交领域的连续创业者和研究者。目前我在美国创业之中,我们公司( PixoMobile )的产品Pixotale ( 图话 )是一个新一代的移动社交网络,她让用户能方便地通过手机阅读或发表图文并茂的富媒体内容, 用每个人生活中的点滴故事来构建一个更真实、更直观的社交网络。 Pixotale 一经发布就引起了社交媒体的强烈反响,被科技媒体广泛报道,在用户成长、内容创建和社区育成各方面均发展迅速。

从很早期就断断续续地看 KnewOne ,一来 KnewOne 有很多新奇的产品介绍和使用体验,作为喜欢尝试新鲜事物的我而言,这是非常好的媒体; 二来常常在上面看到熟人或者仰慕已久的网红们,格外有亲切感。 我尤其喜欢 KnewOne 把用户、评价、文章按照产品线索聚合的设计, 这是一种媒体形式上的创新。

从微软研究院到创立 Pixomobile 公司

 

创办PixoMobile之前,我在微软美国研究院的未来社交体验实验室(FUSE Labs)工作了几年时间,专注于社会化计算相关的一些实验和研究性的项目。微软研究院提供了一流的办公和协作环境,我觉得最大的优势是拥有一群非常优秀的同事,在很多领域都有可以学习和讨论的对象,有可以一起讨论的同伴,这对在未知领域里的探索者来说是最大的幸运之一,否则你就只能在黑暗中孤独地摸索。

          我觉得研究和创业其实有一个相当类似的地方:就是需要不断开拓未知领域,不断地尝试失败,在近乎盲目乐观的假设基础上,通过尝试和失败来取得小概率的成功。 然 而研究院环境小取得的成功主要是通过发表论文,研究成果能被其他人所采用来体现的,这就使得我每个研究项目都有一种意犹未尽的感觉,有时甚至会觉得很沮 丧,因为你必需放下已经投入很久取得初步成果的东西,没有办法把这些变成真正能改变成千上万人的生活的实实在在的东西。这就使得在机会合适的时候,离开研 究院来创业变成非常顺理成章的事情,不仅我自己,我在我同事身上看到了很多这样的例子。

  PixoMobile 的组建故事非常简单: 当我费尽“千辛万苦”拿到了绿卡批准 -- 我这绿卡的确很难拿,是我自己以“杰出人才”身份( Extraordinary Ability )取得的,而不是通过给微软工作而获得的 -- 即将获得“自由身”的时候,也刚好是我在微软的一个研究项目即将终结的阶段,无论如何选择都需要开始一个新的旅程,选择再次创业变成一个非常明显的事情。

Pixotale(图话)诞生记

         自我表达是人类的基本需求,就如同吃饭、睡觉、沟通一样,都属于持久不变的需求。 然而,虽然这些需求的类型恒久未变,但其形式却始终处于不断的变化演进之中,有些时候这些演变是螺旋曲折的,是带有流行和跟风成分的。过去的有些流行的表达方式是受历史、环境以及技术等因素局限而产生的。 Pixotale 试图提供一个非常容易使用的工具,让人们在移动时代自我表达和传播变得更为容易。

从另外一个角度而言,“故事”是一个非常重要的沟通、表达和传播形式。 事实上我们今天每一个人都是从故事中长大的,我们从小时候开始最爱听的就是故事, 故事,而不是说教、唠叨和冗长的理论。 Pixotale 就是试图通过提供一个革新的移动创作工具和传播网络,让人们找回自己喜爱的表达方式,而不是变成因为过去的技术局限导致的120字符内的絮絮叨叨,或者被动在所谓的 “ 朋友圈 ” 内接受大量鸡汤文的刷屏。 Pixotale 和她的一些竞争同行其实代表的是一群先行者在这个领域的一种大胆尝试,我们仍然在探索和寻找最佳的方式和体验,但我们代表着未来。

 

 PixoMobile 产品介绍

我们在 PixoMobile 的创业初期采用快速迭代,快速发布的方式开发了好几个和照片、视频相关的 app ,其实这是我们自己在摸索、学习研究的过程中的产品,但比较幸运的是,好几个app都取得了不俗的表现,被 Apple 多次推荐,并且多次上榜并较长时间停留。 除了我们的主产品 Pixotale ,最有趣的就是 Levitagram 这个漂浮照的 app ,我们是第一个漂浮照片的app,这么简单的想法,在我们之前居然没有人做我们自己都很惊讶

这个 app 的第一版我们只花了两星期就推出了,推出第一周就上了榜,在美国榜单上呆了一年之久。 ( 不过最近大量的copycat已经杀了进来 )

几个我最喜欢的别家的 app :

Same - 很早就注意到了这个相当棒相当原创的 app

Hyperlapse - Facebook 的那款消除抖动的 app 真的效果很棒。

工作装备

 

作为果粉,多年来使用全套的苹果装备,工作需要也使得自己有借口在任何新苹果装备出现的时候去购买一台,最近的是Apple Watch

9fe30499c40c8487ac9e7a60120d9814
Apple Watch

40911219

即便在微软的时候,作为微软研究院的特权之一,我们可以自由选择各家的装备,因此我在微软时的主力笔记本电脑也是Macbook Pro

苹果产品中 Time Capsule 是我很喜欢的一个产品,这么多年它就一直呆在家里一个黑暗的角落里不知疲倦地备份数据和提供无线网络,属于一个使用体验好得可以被被遗忘的产品。

Uplift 900 我自己相信站立办公是对 IT 从业者健康非常有益的东西,因此我自己的工作台是 Uplift 900 自动升降桌。这是 Lifehaker 读者评价第一位的升级桌,我自己用下来两年觉得非常棒。 现在配合 Apple Watch 的站立提醒,感觉非常给力。

我的创业公司里,每人都配备自动升降的工作台,这虽然成本有些高但一来创业团队中每个人的健康都非常重要,二来我们就不需要买昂贵的人体工学的椅子了, 时髦的 Aeron 在我们 team 就省了。:)

钟爱的产品

喜欢各种新鲜的电子产品,不过也谈不上装备和钟爱,因为电子产品总是不断地推陈出新的。

Amazon Echo ,这是最近一段时间拥有的最棒的电子产品了。

从 Amazon 去年宣布就打听如何能及早拿到,年初预定到几周前拿到几乎等了半年, 但 Echo 的表现绝对超出了预期。 Echo 是一个由亚马逊背后的云服务支撑着的智能音箱,能“听懂” 人话。通过 Echo 可以轻松听音乐,广播,设闹钟,查天气交通,还可以用她控制智能家电(比如开关灯等)。 Echo 的使用体验远远超出我的预期,主要是随时随地的语音控制非常方便。

耳机是 BOSE QC – 15 降噪耳 ,用 BOSE QC 系列耳机已经超过 10 年时间,这耳机对出差在飞机上,吵闹环境下办公有神奇效果,强烈推荐。

Plantronics Backbeat FIT 运动型蓝牙耳机,是我的新宠。非常轻便小巧,功能强大,而且音质也相当不错。

Soundblaster Roar + 网易云音乐下载。 Sound Blaster Roar 是一个功能强大的便携蓝牙音箱,最喜欢的功能是她能直接插一个 Micro SD 卡,这样不需要任何音乐源就能自己连续播放几个小时的音乐, 配合上网易云音乐的离线下载,这个字典大小的盒子已经成为家里厨房和餐厅里的主要音乐设备。

说了半天,看来我最喜欢的原来都是音乐有关的装备,不过我不是发烧友,对音乐欣赏也是门外汉,只是随便听些东西。

近期想要或正在关注的产品

本来的几个期望产品,由于我的拖延症原因都已经变成拥有的产品了。由于生活在一个总是可以不满意就轻松退货的环境之中,我经常购入各种有兴趣的东西,觉得不满意就退了( 相当多很期待的东西到手玩几天发现失望就退了哦 )。:P 希望不久的将来国内也能变成这个样子就好啦。

这些是我在关注和想要的产品:

Philips Hue:

智能多彩的灯泡,虽然好想尝试一下,但觉得 $200就买3个能变色的灯泡实在有点过不去,因此一直没有下手。最近因为入手了Amazon Echo可以声控Hue,让我重新考虑是否要买回来看看。

Apple Thunderbolt Display 5K:

这产品并不存在,但估计不久的未来一定会出现。 相信很多苹果粉丝和我一样在翘首等待苹果推出这款升级的产品。

Google无人驾驶汽车

 

算法的力量

李开复写于 2006 年

算法是计算机科学领域最重要的基石之一,但却受到了国内一些程序员的冷落。许多学生看到一些公司在招聘时要求的编程语言五花八门就产生了一种误解,认为学计算机就是学各种编程语言,或者认为,学习最新的语言、技术、标准就是最好的铺路方法。其实大家都被这些公司误导了。编程语言虽然该学,但是学习计算机算法和理论更重要,因为计算机算法和理论更重要,因为计算机语言和开发平台日新月异,但万变不离其宗的是那些算法和理论,例如数据结构、算法、编译原理、计算机体系结构、关系型数据库原理等等。在“开复学生网”上,有位同学生动地把这些基础课程比拟为“内功”,把新的语言、技术、标准比拟为“外功”。整天赶时髦的人最后只懂得招式,没有功力,是不可能成为高手的。

算法与我

当我在1980年转入计算机科学系时,还没有多少人的专业方向是计算机科学。有许多其他系的人嘲笑我们说:“知道为什么只有你们系要加一个‘科学’,而没有‘物理科学系’或‘化学科学系’吗?因为人家是真的科学,不需要画蛇添足,而你们自己心虚,生怕不‘科学’,才这样欲盖弥彰。”其实,这点他们彻底弄错了。真正学懂计算机的人(不只是“编程匠”)都对数学有相当的造诣,既能用科学家的严谨思维来求证,也能用工程师的务实手段来解决问题——而这种思维和手段的最佳演绎就是“算法”。

记得我读博时写的Othello对弈软件获得了世界冠军。当时,得第二名的人认为我是靠侥幸才打赢他,不服气地问我的程序平均每秒能搜索多少步棋,当他发现我的软件在搜索效率上比他快60多倍时,才彻底服输。为什么在同样的机器上,我可以多做60倍的工作呢?这是因为我用了一个最新的算法,能够把一个指数函数转换成四个近似的表,只要用常数时间就可得到近似的答案。在这个例子中,是否用对算法才是能否赢得世界冠军的关键。

还记得1988年贝尔实验室副总裁亲自来访问我的学校,目的就是为了想了解为什么他们的语音识别系统比我开发的慢几十倍,而且,在扩大至大词汇系统后,速度差异更有几百倍之多。他们虽然买了几台超级计算机,勉强让系统跑了起来,但这么贵的计算资源让他们的产品部门很反感,因为“昂贵”的技术是没有应用前景的。在与他们探讨的过程中,我惊讶地发现一个O(n*m)的动态规划(dynamic programming)居然被他们做成了O (n*n*m)。更惊讶的是,他们还为此发表了不少文章,甚至为自己的算法起了一个很特别的名字,并将算法提名到一个科学会议里,希望能得到大奖。当时,贝尔实验室的研究员当然绝顶聪明,但他们全都是学数学、物理或电机出身,从未学过计算机科学或算法,才犯了这么基本的错误。我想那些人以后再也不会嘲笑学计算机科学的人了吧!

网络时代的算法

有人也许会说:“今天计算机这么快,算法还重要吗?”其实永远不会有太快的计算机,因为我们总会想出新的应用。虽然在摩尔定律的作用下,计算机的计算能力每年都在飞快增长,价格也在不断下降。可我们不要忘记,需要处理的信息量更是呈指数级的增长。现在每人每天都会创造出大量数据(照片,视频,语音,文本等等)。日益先进的纪录和存储手段使我们每个人的信息量都在爆炸式的增长。互联网的信息流量和日志容量也在飞快增长。在科学研究方面,随着研究手段的进步,数据量更是达到了前所未有的程度。无论是三维图形、海量数据处理、机器学习、语音识别,都需要极大的计算量。在网络时代,越来越多的挑战需要靠卓越的算法来解决。

再举另一个网络时代的例子。在互联网和手机搜索,如果要找附近的咖啡店,那么搜索引擎该怎么处理这个请求呢?最简单的办法就是把整个城市的咖啡馆都找出来,然后计算出它们的所在位置与你之间的距离,再进行排序,然后返回最近的结果。但该如何计算距离呢?图论里有不少算法可以解决这个问题。

这么做也许是最直观的,但绝对不是最迅速的。如果一个城市只有为数不多的咖啡馆,那么这么做应该没什么问题,反正计算量不大。但如果一个城市里有很多咖啡馆,又有很多用户都需要类似的搜索,那么服务器所承受的压力就大多了。在这种情况下,我们该怎样优化算法呢?

首先,我们可以把整个城市的咖啡馆做一次“预处理”。比如,把一个城市分成若干个“格子(grid)”,然后根据用户所在的位置把他放到某一个格子里,只对格子里的咖啡馆进行距离排序。

问题又来了,如果格子大小一样,那么绝大多数结果都可能出现在市中心的一个格子里,而郊区的格子里只有极少的结果。在这种情况下,我们应该把市中心多分出几个格子。更进一步,格子应该是一个“树结构”,最顶层是一个大格——整个城市,然后逐层下降,格子越来越小,这样有利于用户进行精确搜索——如果在最底层的格子里搜索结果不多,用户可以逐级上升,放大搜索范围。

上述算法对咖啡馆的例子很实用,但是它具有通用性吗?答案是否定的。把咖啡馆抽象一下,它是一个“点”,如果要搜索一个“面”该怎么办呢?比如,用户想去一个水库玩,而一个水库有好几个入口,那么哪一个离用户最近呢?这个时候,上述“树结构”就要改成“r-tree”,因为树中间的每一个节点都是一个范围,一个有边界的范围(参考:http://www.cs.umd.edu/~hjs/rtrees/index.html)。

通过这个小例子,我们看到,应用程序的要求千变万化,很多时候需要把一个复杂的问题分解成若干简单的小问题,然后再选用合适的算法和数据结构。

并行算法:Google的核心优势

上面的例子在Google里就要算是小case了!每天Google的网站要处理十亿个以上的搜索,GMail要储存几千万用户的2G邮箱, Google Earth要让数十万用户同时在整个地球上遨游,并将合适的图片经过互联网提交给每个用户。如果没有好的算法,这些应用都无法成为现实。

在这些的应用中,哪怕是最基本的问题都会给传统的计算带来很大的挑战。例如,每天都有十亿以上的用户访问Google的网站,使用Google的服务,也产生很多很多的日志(Log)。因为Log每份每秒都在飞速增加,我们必须有聪明的办法来进行处理。我曾经在面试中问过关于如何对Log进行一些分析处理的问题,有很多面试者的回答虽然在逻辑上正确,但是实际应用中是几乎不可行的。按照它们的算法,即便用上几万台机器,我们的处理速度都根不上数据产生的速度。

那么Google是如何解决这些问题的?

首先,在网络时代,就算有最好的算法,也要能在并行计算的环境下执行。在Google的数据中心,我们使用的是超大的并行计算机。但传统的并行算法运行时,效率会在增加机器数量后迅速降低,也就是说,十台机器如果有五倍的效果,增加到一千台时也许就只有几十倍的效果。这种事倍功半的代价是没有哪家公司可以负担得起的。而且,在许多并行算法中,只要一个结点犯错误,所有计算都会前功尽弃。

那么Google是如何开发出既有效率又能容错的并行计算的呢?

Google最资深的计算机科学家Jeff Dean认识到,Google所需的绝大部分数据处理都可以归结为一个简单的并行算法:MapReduce。这个算法能够在很多种计算中达到相当高的效率,而且是可扩展的(也就是说,一千台机器就算不能达到一千倍的效果,至少也可以达到几百倍的效果)。 MapReduce的另外一大特色是它可以利用大批廉价的机器组成功能强大的server farm。最后,它的容错性能异常出色,就算一个 server farm宕掉一半,整个fram依然能够运行。正是因为这个天才的认识,才有了MapReduce算法。借助该算法, Google几乎能无限地增加计算量,与日新月异的互联网应用一同成长。

算法并不局限于计算机和网络

举一个计算机领域外的例子:在高能物理研究方面,很多实验每秒钟都能几个TB的数据量。但因为处理能力和存储能力的不足,科学家不得不把绝大部分未经处理的数据丢弃掉。可大家要知道,新元素的信息很有可能就藏在我们来不及处理的数据里面。同样的,在其他任何领域里,算法可以改变人类的生活。例如人类基因的研究,就可能因为算法而发明新的医疗方式。在国家安全领域,有效的算法可能避免下一个911的发生。在气象方面,算法可以更好地预测未来天灾的发生,以拯救生命。

所以,如果你把计算机的发展放到应用和数据飞速增长的大环境下,你一定会发现;算法的重要性不是在日益减小,而是在日益加强。

Inside The Mind That Built Google Brain: On Life, Creativity, And Failure

Source: The Huffington Post

(Photo: Jemal Countess/Getty)

Here’s a list of universities with arguably the greatest computer science programs: Carnegie Mellon, MIT, UC Berkeley, and Stanford. These are the same places, respectively, where Andrew Ng received his bachelor’s degree, his master’s, his Ph.D., and has taught for 12 years.

Ng is an icon of the artificial intelligence world with the pedigree to match, and he is not yet 40 years old. In 2011, he founded Google Brain, a deep-learning research project supercharged by Google’s vast stores of computing power and data. Delightfully, one of its most important achievements came when computers analyzing scores of YouTube screenshots were able to recognize a cat. (The New York Timesheadline: “How Many Computers to Identify a Cat? 16,000.”) As Ng explained, “The remarkable thing was that [the system] had discovered the concept of a cat itself. No one had ever told it what a cat is. That was a milestone in machine learning.”

Ng exudes a cheerful but profound calm. He happily discusses the various mistakes and failures of his career, the papers he read but didn’t understand. He wears identical blue oxford shirts each and every day. He is blushing but proud when a colleague mentions his adorable robot-themed engagement photo shoot with his now-wife, a surgical roboticist named Carol Reiley (note his shirt in the photo).

One-on-one, he speaks with a softer voice than anyone you know, though this has not hindered his popularity as a lecturer. In 2011, when he posted videos from his own Stanford machine learning course on the web, over 100,000 people registered. Within a year, Ng had co-founded Coursera, which is today the largest provider of open online courses. Its partners include Princeton and Yale, top schools in China and across Europe. It is a for-profit venture, though all classes are accessible for free. “Charging for content would be a tragedy,” Ng has said.

(Photo: Colson Griffith)

Then, last spring, a shock. Ng announced he was departing Google and stepping away from day-to-day involvement at Coursera. The Chinese tech giant Baidu was establishing an ambitious $300 million research lab devoted to artificial intelligence just down the road from Google’s Silicon Valley headquarters, and Andrew Ng would head it up.

At Baidu, as before, Ng is trying to help computers identify audio and images with incredible accuracy, in realtime. (On Tuesday, Baidu announced it had achieved the world’s best results on a key artificial intelligence benchmark related to image identification, besting Google and Microsoft.) Ng believes speech recognition with 99 percent accuracy will spur revolutionary changes to how humans interact with computers, and how operating systems are designed. Simultaneously, he must help Baidu work well for the millions of search users who are brand new to digital life. “You get queries [in China] that you just wouldn’t get in the United States,” Ng explained. “For example, we get queries like, ‘Hi Baidu, how are you? I ate noodles at a corner store last week and they were delicious. Do you think they’re on sale this weekend?’ That’s the query.” Ng added: “I think we make a good attempt at answering.”

Elon Musk and Stephen Hawking have been sounding alarms over the potential threat to humanity from advanced artificial intelligence. Andrew Ng has not. “I don’t work on preventing AI from turning evil for the same reason that I don’t work on combating overpopulation on the planet Mars,” he has said. AI is many decades away (if not longer) from achieving something akin to consciousness, according to Ng. In the meantime, there’s a far more urgent problem. Computers enhanced by machine learning are eliminating jobs long done by humans. The trend is only accelerating, and Ng frequently calls on policymakers to prepare for the socioeconomic consequences.

At Baidu’s new lab in Sunnyvale, Calif., we spoke to Andrew Ng for Sophia, a HuffPost project to collect life lessons from fascinating people. He explained why he thinks “follow your passion” is terrible career advice and he shared his strategy for teaching creativity; Ng discussed his failures and his helpful habits, the most influential books he’s read, and his latest thoughts on the frontiers of AI.

You recently said, “I’ve seen people learn to be more creative.” Can you explain?

The question is, how does one create new ideas? Is it those unpredictable lone acts of genius, people like Steve Jobs, who are special in some way? Or is it something that can be taught and that one can be systematic about?

I believe that the ability to innovate and to be creative are teachable processes. There are ways by which people can systematically innovate or systematically become creative. One thing I’ve been doing at Baidu is running a workshop on the strategy of innovation. The idea is that innovation is not these random unpredictable acts of genius, but that instead one can be very systematic in creating things that have never been created before.

In my own life, I found that whenever I wasn’t sure what to do next, I would go and learn a lot, read a lot, talk to experts. I don’t know how the human brain works but it’s almost magical: when you read enough or talk to enough experts, when you have enough inputs, new ideas start appearing. This seems to happen for a lot of people that I know.

When you become sufficiently expert in the state of the art, you stop picking ideas at random. You are thoughtful in how to select ideas, and how to combine ideas. You are thoughtful about when you should be generating many ideas versus pruning down ideas.

Now there is a challenge still — what do you do with the new ideas, how can you be strategic in how to advance the ideas to build useful things? That’s another whole piece.

Can you talk about your information diet, how you approach learning?

I read a lot and I also spend time talking to people a fair amount. I think two of the most efficient ways to learn, to get information, are reading and talking to experts. So I spend quite a bit of time doing both of them. I think I have just shy of a thousand books on my Kindle. And I’ve probably read about two-thirds of them.

At Baidu, we have a reading group where we read about half a book a week. I’m actually part of two reading groups at Baidu, each of which reads about half a book a week. I think I’m the only one who’s in both of those groups [laughter]. And my favorite Saturday afternoon activity is sitting by myself at home reading.

 

 

Let me ask about your early influences. Is there something your parents did for you that many parents don’t do that you feel had a lasting impact on your life?

I think when I was about six, my father bought a computer and helped me learn to program. A lot of computer scientists learned to program from an early age, so it’s probably not that unique, but I think I was one of the ones that was fortunate to have had a computer and could learn to start to program from a very young age.

Unlike the stereotypical Asian parents, my parents were very laid back. Whenever I got good grades in school, my parents would make a fuss, and I actually found that slightly embarrassing. So I used to hide them. [Laughter] I didn’t like showing my report card to my parents, not because I was doing badly but because of their reaction.

I was also fortunate to have gotten to live and work in many different places. I was born in the U.K., raised in Hong Kong and Singapore, and came to the U.S. for college. Then for my own studies, I have degrees from Carnegie Mellon, MIT, and Berkeley, and then I was at Stanford.

I was very fortunate to have moved to all these places and gotten to meet some of the top people. I interned at AT&T Bell Labs when it existed, one of the top labs, and then at Microsoft Research. I got to see a huge diversity of points of view.

Is there anything about your education or your early career that you would have done differently? Any lessons you’ve learned that people could benefit from?

I wish we as a society gave better career advice to young adults. I think that “follow your passion” is not good career advice. It’s actually one of the most terrible pieces of career advice we give people.

If you are passionate about driving your car, it doesn’t necessarily mean you should aspire to be a race car driver. In real life, “follow your passion” actually gets amended to, “Follow your passion of all the things that happen to be a major at the university you’re attending.”

But often, you first become good at something, and then you become passionate about it. And I think most people can become good at almost anything.

So when I think about what to do with my own life, what I want to work on, I look at two criteria. The first is whether it’s an opportunity to learn. Does the work on this project allow me to learn new and interesting and useful things? The second is the potential impact. The world has an infinite supply of interesting problems. The world also has an infinite supply of important problems. I would love for people to focus on the latter.

I’ve been fortunate to have repeatedly been able to find opportunities that had a lot of potential for impact and also gave me fantastic opportunities to learn. I think young people optimizing for these two things will often have the best careers.

Our team here has a mission of developing hard AI technologies, advanced AI technologies that let us impact hundreds of millions of users. That’s a mission I’m genuinely excited about.

 

 

Do you define importance primarily by the number of people who are impacted?

No, I don’t think the number is the only thing that’s important. Changing hundreds of millions of people’s lives in a significant way, I think that’s the level of impact that we can reasonably aspire to. That is one way of making sure we do work that isn’t just interesting, but that also has an impact.

You’ve talked previously about projects of yours that have failed. How do you respond to failure?

Well, it happens all the time, so it’s a long story. [Laughter] A few years ago, I made a list in Evernote and tried to remember all the projects I had started that didn’t work out, for whatever reason. Sometimes I was lucky and it worked out in a totally unexpected direction, through luck rather than skill.

But I made a list of all the projects I had worked on that didn’t go anywhere, or that didn’t succeed, or that had much less to show for it relative to the effort that we put into it. Then I tried to categorize them in terms of what went wrong and tried to do a pretty rigorous post mortem on them.

So, one of these failures was at Stanford. For a while we were trying to get aircraft to fly in formation to realize fuel savings, inspired by geese flying in a V-shaped formation. The aerodynamics are actually pretty solid. So we spent about a year working on making these aircraft fly autonomously. Then we tried to get the airplanes to fly in formation.

But after a year of work, we realized that there is no way that we could control the aircraft with sufficient accuracy to realize fuel savings. Now, if at the start of the project we had thought through the position requirements, we would have realized that with the small aircraft we were using, there is just no way we could do it. Wind gusts will blow you around far more than the precision needed to fly the aircraft in formation.

So one pattern of mistakes I’ve made in the past, hopefully much less now, is doing projects where you do step one, you do step two, you do step three, and then you realize that step four has been impossible all along. I talk about this specific example in the strategy innovation workshop I talked about. The lesson is to de-risk projects early.

I’ve become much better at identifying risks and assessing them earlier on. Now when I say things like, “We should de-risk a project early,” everyone will nod their head because it’s just so obviously true. But the problem is when you’re actually in this situation and facing a novel project, it’s much harder to apply that to the specific project you are working on.

The reason is these sorts of research projects, they’re a strategic skill. In our educational system we’re pretty good at teaching facts and procedures, like recipes. How do you cook spaghetti bolognese? You follow the recipe. We’re pretty good at teaching facts and recipes.

But innovation or creativity is a strategic skill where every day you wake up and it’s a totally unique context that no one’s ever been in, and you need to make good decisions in your completely unique environment. So as far as I can tell, the only was we know way to teach strategic skills is by example, by seeing tons of examples. The human brain, when you see enough examples, learns to internalize those rules and guidelines for making good strategic decisions.

Very often, what I find is that for people doing research, it takes years to see enough examples and to learn to internalize those guidelines. So what I’ve been experimenting with here is to build a flight simulator for innovation strategy. Instead of having everyone spend five years before you see enough examples, to deliver many examples in a much more compressed time frame.

Just as in a flight simulator, if you want to learn to fly a 747, you need to fly for years, maybe decades, before you see any emergencies. But in a flight simulator, we can show you tons of emergencies in a very compressed period of time and allow you to learn much faster. Those are the sorts of things we’ve been experimenting with.

When this lab first opened, you noted that for much of your career you hadn’t seen the importance of team culture, but that you had come to realize its value. Several months in, is there anything you’ve learned about establishing the right culture?

A lot of organizations have cultural documents like, “We empower each other,” or whatever. When you say it, everyone nods their heads, because who wouldn’t want to empower your teammates. But when they go back to their desks five minutes later, do they actually do it? It’s difficult for people to bridge the abstract and the concrete.

At Baidu, we did one thing for the culture that I think is rare. I don’t know of any organization that has done this. We created a quiz that describes to employees specific scenarios — it says, “You’re in this situation and this happens. What do you do: A, B, C, or D?”

No one has ever gotten full marks on this quiz the first time out. I think the quiz interactivity, asking team members to apply specifics to hypothetical scenarios, has been our way of trying to connect the abstract culture with the concrete; what do you actually do when a teammate comes to you and does this thing?

What are some books that had a substantial impact on your intellectual development?

Recently I’ve been thinking about the set of books I’d recommend to someone wanting to do something innovative, to create something new.

The first is “Zero to One“ by Peter Thiel, a very good book that gives an overview of entrepreneurship and innovation.

We often break down entrepreneurship into B2B (“business to business,” i.e., businesses whose customers are other businesses) and B2C (“business to consumer”). For B2B, I recommend “Crossing the Chasm.” For B2C, one of my favorite books is “The Lean Startup,” which takes a narrower view but it gives one specific tactic for innovating quickly. It’s a little narrow but it’s very good in the area that it covers.

Then to break B2C down even further, two of my favorites are “Talking to Humans,” which is a very short book that teaches you how to develop empathy for users you want to serve by talking to them. Also, “Rocket Surgery Made Easy.” If you want to build products that are important, that users care about, this teaches you different tactics for learning about users, either through user studies or by interviews.

Then finally there is “The Hard Thing about Hard Things.“ It’s a bit dark but it does cover a lot of useful territory on what building an organization is like.

For people who are trying to figure out career decisions, there’s a very interesting one: “So Good They Can’t Ignore You.” That gives a valuable perspective on how to select a path for one’s career.

Do you have any helpful habits or routines?

I wear blue shirts every day, I don’t know if you know that. [laughter] Yes. One of the biggest levers on your own life is your ability to form useful habits.

When I talk to researchers, when I talk to people wanting to engage in entrepreneurship, I tell them that if you read research papers consistently, if you seriously study half a dozen papers a week and you do that for two years, after those two years you will have learned a lot. This is a fantastic investment in your own long term development.

But that sort of investment, if you spend a whole Saturday studying rather than watching TV, there’s no one there to pat you on the back or tell you you did a good job. Chances are what you learned studying all Saturday won’t make you that much better at your job the following Monday. There are very few, almost no short-term rewards for these things. But it’s a fantastic long-term investment. This is really how you become a great researcher, you have to read a lot.

People that count on willpower to do these things, it almost never works because willpower peters out. Instead I think people that are into creating habits — you know, studying every week, working hard every week — those are the most important. Those are the people most likely to succeed.

For myself, one of the habits I have is working out every morning for seven minutes with an app. I find it much easier to do the same thing every morning because it’s one less decision that you have to make. It’s the same reason that my closet is full of blue shirts. I used to have two color shirts actually, blue and magenta. I thought that’s just too many decisions. [Laughter] So now I only wear blue shirts.

 

You’ve urged policymakers to spend time thinking about a future where computing and robotics have eliminated some substantial portion of the jobs people have now. Do you have any ideas about possible solutions?

It’s a really tough question. Computers are good at routine repetitive tasks. Thus far, the main things that computers have been good at automating are tasks where you kind of do the same thing day after day.

Now this can be at multiple points on the spectrum. Humans work on an assembly line, making the same motion for months on end, and now robots are doing some of that work. A midrange challenge might be truck-driving. Truck drivers do very similar things day after day, so computers are trying to do that too. It’s harder than most people think, but automated driving might happen in the next decade or so, we don’t know. Then, even higher-end things, like some radiologists read the same types of x-rays over and over each day. Again, computers may have traction in those areas.

But for the social tasks which are non-routine and non-repetitive, those are the tasks that humans will be better at than computers for quite a period of time, I think. In many of our jobs we do different things every day. We meet different people, we have to arrange different things, solve problems differently. Those things are relatively difficult for computers to do, for now.

The challenge that faces us is that, when the U.S. transformed from an agricultural to a manufacturing and services economy, we had people move from one routine task, such as farming, to a different routine task, such as manufacturing or working call service centers. A large fraction of the population has made that transition, so they’ve been okay, they’ve found other jobs. But many of their jobs are still routine and repetitive.

The challenge that faces us is to find a way to scalably teach people to do non-routine non-repetitive work. Our education system, historically, has not been good at doing that at scale. The top universities are good at doing that for a relatively modest fraction of the population. But a lot of our population ends up doing work that is important but also routine and repetitive. That’s a challenge that faces our educational system.

I think it can be solved. That’s one of the reasons why I’ve been thinking about teaching innovation strategy, teaching creativity strategy. We need to enable a lot of people to do non-routine, non-repetitive tasks. These tactics for teaching innovation and creativity, these flight simulators for innovation, could be one way to get there. I don’t think we’ve figured out yet how to do it, but I’m optimistic it can be done.

You’ve said, “Engineers in China work much harder than the average Silicon Valley engineer. Engineers in Silicon Valley at startups work really hard. At mature companies, I don’t see the same intensity as you do in startups and at Baidu.” Why do you think that is?

I don’t know. I think the individual engineers in China are great. The individual engineers in Silicon Valley are great. The difference I think is the company. The teams of engineers at Baidu tend to be incredibly nimble.

There is much less appreciation for the status quo in the Chinese internet economy and I think there’s a much bigger sense that all assumptions can be challenged and everything is up for grabs. The Chinese internet ecosystem is very dynamic. Everyone sees huge opportunity, everyone sees massive competition. Stuff changes all the time. New inventions arise, and large companies will one day suddenly jump into a totally new business sector.

To give you an idea, here in the United States, if Facebook were to start a brand new web search engine, that might feel like a slightly strange thing to do. Why would Facebook build a search engine? It’s really difficult. But that sort of thing is much more thinkable in China, where there is more of an assumption that there will be new creative business models.

 

 

This seems to suggests a different management culture, where you can make important decisions quickly and have them be intelligent and efficient and not chaotic. Is Baidu operating in a unique way that you feel is particularly helpful to its growth?

Gosh, that’s a good question. I’m trying to think what to point to. I think decision making is pushed very far down in the organization at Baidu. People have a lot of autonomy, and they are very strategic. One of the things I really appreciate about the company, especially the executives, is there’s a very clear-eyed view of the world and of the competition.

When executives meet, and the way we speak with the whole company, there is a refreshing absence of bravado. The statements that are made internally — they say, “We did a great job on that. We’re not so happy with those things. This is going well. This is not going well. These are the things we think we should emphasize. And let’s do a post-mortem on the mistakes we made.” There’s just a remarkable lack of bravado, and I think this gives the organization great context on the areas to innovate and focus on.

You’re very focused on speech recognition, among other problems. What are the challenges you’re facing that, when solved, will lead to a significant jump in the accuracy of speech recognition technology?

We’re building machine learning systems for speech recognition. Some of the machine learning technologies we’re using now have been around for decades. It was only in the last several years that they’ve really taken off.

Why is that? I often make an analogy to building a rocket ship. A rocket ship is a giant engine together with a ton of fuel. Both need to be really big. If you have a lot of fuel and a tiny engine, you won’t get off the ground. If you have a huge engine and a tiny amount of fuel, you can lift up, but you probably won’t make it to orbit. So you need a big engine and a lot of fuel.

The reason that machine learning is really taking off now is that we finally have the tools to build the big rocket engine — that is giant computers, that’s our rocket engine. And the fuel is the data. We finally are getting the data that we need.

The digitization of society creates a lot of data and we’ve been creating data for a long time now. But it was just in the last several years we’ve been finally able to build big enough rocket engines to absorb the fuel. So part of our approach, not the whole thing, but a lot of our approach to speech recognition is finding ways to build bigger engines and get more rocket fuel.

For example, here is one thing we did, a little technical. Where do you get a lot of data for speech recognition? One of the things we did was we would take audio data. Other groups use maybe a couple thousand hours of data. We use a hundred thousand hours of data. That is much more rocket fuel than what you see in academic literature.

Then one of the things we did was, if we have an audio clip of you saying something, we would take that audio clip of you and add background noise to it, like a clip recorded in a cafe. So we synthesize an audio clip of what you would sound like if you were speaking in a cafe. By synthesizing your voice against lots of backgrounds, we just multiply the amount of data that we have. We use tactics like that to create more data to feed to our machines, to feed to our rocket engines.

One thing about speech recognition: most people don’t understand the difference between 95 and 99 percent accurate. Ninety-five percent means you get one-in-20 words wrong. That’s just annoying, it’s painful to go back and correct it on your cell phone.

Ninety-nine percent is game changing. If there’s 99 percent, it becomes reliable. It just works and you use it all the time. So this is not just a four percent incremental improvement, this is the difference between people rarely using it and people using it all the time.

So what is the hurdle to 99 percent at this point?

We need even bigger rocket engines and we still need even more rocket fuel. Both are still constrained and the two have to grow together. We’re still working on pushing that boundary.

如何快速在一个陌生领域达到优秀水平?

2016-04-30 TalentGuide

优秀是投入20%精力得到80分;

顶尖是投入80%的精力去打磨那超越众人的20分。

来源:咪喵

ID:mimiao_mao

授权 TalentGuide 发布

许多事情无需做到顶尖,做到优秀已经足够。
下厨做菜,不用做到五星级饭店主厨水平,不用将洋葱切成0.1cm见方的均匀小块,只需会做几个拿手菜,可为心爱之人下厨,可招呼三五知己来家吃饭,已足够应付日常生活,若还会做几样甜点糖水,更是加分项。
做PPT,无需专业设计功底,能做到配色和谐、风格统一、排版整齐、图表清晰,已足够秒杀90%混乱驳杂、惨不忍睹的PPT。
日常服饰搭配,不必有时尚总监的品味,不必紧追每季潮流细节,能在各种场合着装都妥帖恰当,已足够让人心生敬意。

优秀和顶尖的区别,可以用80/20法则来解释:优秀是投入20%精力得到80分,顶尖是投入80%的精力去打磨那超越众人的20分。高手相争,看似只在毫厘之间,其实如果按边际效应计算,为获得那毫厘之差所投入的努力又何止数倍。

这篇文章不讨论如何做到顶尖,通往顶尖的路是没有捷径的,要靠天赋和时间堆积出来的。通向优秀的路则不同,短时间内有限的投入就能带来可见的有效产出。这篇文章只讨论如何才能快速在一个陌生领域到达优秀水平。

1
大量搜集资料

如果你在做一个紧急的任务,这个任务涉及的领域你很陌生。最快速上手一个新领域的方式,就是先穷尽你能找到的所有资料
如果你需要出一份专题报告,先搜罗这个专题的所有相关论文和书籍。你不一定需要把所有的付费资料都买回来,很多时候只需浏览目录,看看别人都是从哪些角度切入这个题目,再通过目录标题搜索相关的资料,并且顺藤摸瓜找到更多资料里提及的其他资料来源,已可找到足够丰富的素材。
如果你要装修房子,先大量浏览别人家的装修效果图,找到自己喜欢的风格;收集各种与自己家类似的户型图,看看别人如何利用空间;再看看别人的装修日记,看看装修都有哪些常见的坑。一番研究下来,不出三个月,你也能成为一个小小的行家。

2
寻找现成的最优解

许多人上手新东西的方法是自己先瞎捣鼓一通。当然这没什么不对,只是效率不太高。
比如你想学做一锅白粥,当然可以凭自己喜好随便扔点米和水进锅里,凭感觉爱煮多久煮多久,等烧成锅巴后再研究为什么这次煮得不成功。这符合人类长久以来进化的习惯——在实践中总结经验。
事实上,99%的情况,这个对你而言全新的领域,对别人而言早已是玩剩下的。完全没有必要自己重新实验一番再总结经验,你可以直接套用别人经验总结出来的最佳方案。


你可以在做白粥之前先研究各路大师总结的做粥秘诀,知道米和水的最佳比例是1:10,最适合做白粥的米是圆粒的珍珠米,熬一锅好粥的关键是熬透米心,为了熬透米心你需要提前一晚浸泡大米,在煮粥前用一勺油将米裹上,然后烧一壶滚烫的开水缓慢地冲入米中,这样裹在米周围的油就会将热量吸在米周围,慢火熬了两小时,最后半小时要用勺子不停搅拌,帮助米心融化。

于是,你虽然是第一次下厨熬粥,却能令人惊叹地熬出比做了一辈子饭的妈妈熬的更香更浓见米不见粒的标准粤式好粥。

有人说什么都用别人的最优方案岂不是特别没意思,我这人就喜欢不参考别人的自己创新。连牛顿这样的神级人物都要“站在巨人的肩上”,李白这样的诗仙都会借鉴《黄鹤楼》写“凤凰台上凤凰游”,我们又有什么不能借鉴别人的呢?

创新从来不是从石头里面蹦出来的,参考过现实中所有最佳方案仍感到不满意,在理解原方案的基础上创造出更好的东西,才算真正的创新。如果所谓的原创只是在低水平徘徊,那不叫创新,只能算自娱自乐。

3
依样画葫芦的练习

在你搜罗了大量的资料和最佳实践的案例后,就要开始练习之路了。足够量的练习是达到优秀的必经之路。
练习之初,不要急着发挥你的创造性,请一板一眼,完完全全按照你收集到的最佳方案进行练习。学烘焙,就完完全全按照方子的分量和步骤做;学画画,就完完全全按着样稿一笔一笔地画;学画原型,就完完全全地按照范例一步步地设置。
不要笑,太多人在这一步跌倒,以至于一辈子无缘优秀。老人家常笑孩子“还没学走,先想学跑”,看似浅显的道理许多人却从未明白,总是觉得自己特别聪明,幻想着能一步登天。

如果你真的很扎实地做了前两步功课,就该相信你学习的对象已是目前能找到的最佳方案,人家这么做一定有他的道理,即使你并不懂那道理是什么。只有一板一眼地依样画葫芦,成品出来不如人意时,你才能回溯出自己到底哪儿做的不够好。如果中途发挥各种创意做了稀奇古怪的改动,就很难找到成品不满意的原因了。
觉得自己特别聪明,不需要这样沉闷无聊的练习?弗罗基俄为何让达芬奇画了三年鸡蛋?自己的悟性能否超过这位文艺复兴时代的天才,请再思。

4
修正与总结

大量练习的过程中,如果你自问已经完全按照最佳方案实践,却始终无法达到满意的效果,就要多问几个为什么了。问的方式可以是搜索、找该领域的牛人,或者到相关的领域的论坛跟别人讨论。相信我,你不会是唯一一个遇到问题的,你踩过的坑,前人多半已踩了无数回。

列出练习中发现的问题,认真地研究每一个产生问题的可能性。这是提升水平的关键时期,只有你真正掌握了每一条迈过这些坑的方法,水平才会有质的提升,否则不管投入多少时间练习,都只能在低水平徘徊。

我曾经因为自己做的戚风蛋糕达不到理想的状态,搜罗了网上所有的戚风蛋糕失败原因,买了n本大师级的书看里面的教程,换模具换打蛋器换鸡蛋,每晚做一个戚风蛋糕,测试各种温度、各种转速的打发、各种混拌手势、各式各样的戚风蛋糕配方,终于达到了做戚风蛋糕信手拈来的程度。

在那之后,我的烘焙水平忽然突飞猛进,以前搞不定的各种高难度糕点如马卡龙、意式蛋白霜都变得很轻松。朋友们在烘焙上遇到问题来问我,我竟然每次也能将原因猜得八九不离十。虽然离真正的烘焙大师还十万八千里,可至少达到了“超过周围大部分人平均水平”的程度。

许多人做几次做不好,就将原因归结为“自己根本就不是这块料”。不客气地说一句,大部分时候,水平之低还够不着谈“是不是这块料”的程度,因为根本还没入门呢。

5
结语

所谓的实践出真知,没有理论的实践是瞎忙,没有实践的理论是纸上谈兵,只有学习了理论,用实践验证理论,再用实践修正理论,才会实现真正的“从量变到质变”。

如果足够专注与投入,用了合适的方法,用三个月甚至更短的时间,在一个领域做到比周围大部分人优秀是可能的。更有意思的是,随着这四步变成了习惯,接触一个陌生领域并迅速达到优秀水平的时间会越来越短。

老子说“一法通,万法通”,当获悉了一个领域的奥秘后,其他领域的奥秘之门也会变得轻轻一推就开,哪怕这些领域表面看起来似乎毫无关联。

一站式青年人才职业成长平台

What are the best-kept secrets of great programmers?

Source:Quora

Andy Crews

Andy Crews, Principal Engineer with 15 years of professional software development experie…

96.8k ViewsUpvoted by Miguel Paraz, Programming since 1985 at age 11.

Learn when to tell your manager little white lies.
Well, they are not really lies, but rather this is about interpreting questions the right way.

Managers need to know how long it will take to implement a new feature or fix a bug. Often they are under pressure, but even when that’s not the case, they still need that information for prioritizing and scheduling. Getting this information from a developer is where some miscommunication can occur in my experience.

“How long will it take to implement this feature?” Often there is some explicit or implied time pressure in the question. “You know, I’m really in the hot seat on this one with our biggest customer.”

Once upon a time, I interpreted this question at face value: If I were to work on this feature starting now, what is the minimum time it would take me to have something that met the requirements? I answered that question, but I ignored other relevant considerations:

  • What kind of tests should I add?
  • Is there some existing code that can be reused?
  • Is there some refactoring that should be done to implement this feature in a way that it can be maintained and enhanced in the future?

Ignoring these questions and getting a feature working quickly makes lots of people happy in the short term, but all of these aspects affect the long term quality and maintainability of the software. When they are ignored it leads to Technical debt in the code base.

Technical debt makes it ever more difficult to add new features and produce high-quality software. In my experience, if one doesn’t address testing, refactoring and code reuse during the implementation, they are never addressed. There is always another problem to solve around the corner. Each time we ignore them, we take one more step towards the inevitable “sea of complexity”. Each step makes the next enhancement or feature more difficult. When you finally reach the “sea of complexity” you realize you can no longer enhance or support the software using the existing code base and the only solution is to throw it all away and start over.

So when I hear the question “How long will it take to implement this feature?” Before I answer, I translate it in my head into the question “How long will it take to implement this feature with high quality, including adding unit tests, refactoring existing code, and integrating it into our existing code base in such a way that can be maintained and enhanced?”

Jens Rantil

Jens Rantil, Developer, life hacker and inspired Swede

276k ViewsUpvoted by Austin Kelleher, Software Engineer
Answer featured in Forbes and The Huffington Post.
  • Most of the time, using inheritance is a bad object oriented design in the long run. It reduces reusability and testability of code. Consider using composition and interfaces instead. See No, inheritance is not the way to achieve code reuse!. Related;
  • Avoid introducing an interface until you are comfortable in your domain. “Premature interfacing” can also lead to design issues down the road.
  • Deep nested code (both intra-function and inter-function) is 1) harder to maintain, 2) more prone to bugs and 3) harder to reuse. Shallow code hierarchies generally makes a better foundation for reuse and testing. See note about inheritance above.
  • Estimating time is hard. One reason why Scrum and sprints are used in many places.
  • Proper encryption is hard. Don’t invent it yourself unless you have a good reason to.
  • Side-effect free logic is nice. It makes it easier to reason about state (see below) and generally simplifies automated testing.
  • Learn to reason around state and lifecycles. See Jens Rantil’s Hideout.
  • Concurrency can be hard without the right primitives. Threadpools, queues, observables, immutability and actors can sometimes help a lot.
  • Premature optimization is the root of all evil. A good general development process is: 1) Get it to work. 2) Make the code beautiful. 3) Optimize.
  • Know your basic data structures and understand time complexity. It’s an effective way of making your code much faster without adding complexity.
  • Practise back-of-the-envelope calculations. How many items will a piece of code generally hold in memory? Related;
  • An application will eventually break; Bad deploy, unintended behaviour, unintended input or unintended external load. Plan for that. This includes making sure you log uncaught exceptions, test a deploy works after it’s out (and potentially roll back), should run tests continously, but also should make sure to set (sane!) limits on all in-memory queues and thread pools. Related;
  • If you monitor the size of a queue, it’s generally always full or empty. Plan for that. Related;
  • Networks and external services should always be expected to be flaky. Always set socket timeouts on your sockets and read/connect timeouts on HTTP calls. Consider wrapping external network calls in a retrying/circuit breaker library (see Netflix/Hystrix & rholder/guava-retrying).
  • Write code as you want to read it. Add comments where you think you will not understand your code in a year’s time. You will need the comment in a month. Somewhat related;
  • Setup you build tooling around a project so that it’s easy to get started. Document the (few) commands needed to build, run, test and package in a README file.
  • Making sure your projects can build from command line makes things so much easier down the road.
  • Handling 3rd party dependencies in many languages can be a real mess (looking at you Java and Python). Specifically when two different libraries depend on different versions. Some key things to take away from this: 1) Constantly question your dependencies. 2) Automated tests can help against this. 3) Always fixate which version of a 3rd party dependency you should use.
  • Popular Open Source projects are a great way to learn about good maintainable code and software development process.
  • Every single line you add to an application adds complexity and makes it more likely to have bugs. Removing code is a great way to remove bugs. Related;
  • Every piece of infrastructure (databases, caches, message queues etc.) your application is a source of bugs, requires maintenance & new knowledge. Not to mention that such dependencies might slow down productivity. Weigh new infrastructure against productivity carefully. Can you replace an old piece of infrastructure with your new?
  • Code paths that handles failures are rarely tested/executed (for a reason). This makes them a good candidate for bugs.
  • Input validation is not just useful for security reasons. It helps you catch bugs early.
  • Somewhat related to above: State validation and output validation can be equally useful as input validation, both in terms of discovering inherent bugs, but also for security sensitive code.
  • Code reviews are a great way to improve as a programmer. You will get critique on your code, and you will learn to describe in words why someone else’s code is good or bad. It also trains you to discover common mistakes.
  • Learning a new programming language is a great way to learn about new paradigms and question old habits.
  • Always specify encoding when converting text to and from bytes; be it when reading/writing to network, file or for encryption purposes. If you rely on your locale’s character set you are bound to run into data corruption eventually. Use a UTF character set if you can get to choose yourself.
  • Know your tools; That includes your editor, the terminal, version control system (such as git) and build tooling.
  • Learn to use your tools without a mouse. Learn as many keyboard shortcuts as possible. It will make you more efficient and is generally more ergonomic.
  • Reusing code is not an end goal and will not make your code more maintainable per se. Reuse complicated code but be aware that reusing code between two different domains might make them depend on each other more than necessary.
  • Sitting for long time by the computer can break your body. 1) Listen to what your body has to say. Think extra about your back, neck and wrists. Take breaks if your body starts to hurt. Creating a pause habit (making tea, grabing coffee) can be surprisingly good for your body and mind. 2) Rest your eyes from time to time by looking away from your screen. 3) Get a good keyboard without awkward wrist movements.
  • Automated testing, and in particular unit tests, are not just testing that your code does was it should. They also 1) document how the code is supposed to be used and 2) also helps you put yourself in the shoes of someone who will be using the code. The latter is why some claim test-first approach to development can yield cleaner APIs.
  • Test what needs to be tested. Undertesting can slow you down because of bug hunting. Overtesting can slow you down because every change requires updating too many tests.
  • Test what (outcome) is being done in an implementation, now how it’s being done. In other words, your tests should not depend on the inner nitty-gritty details of a class. A different way of looking at it is that a rewrite of how a class does something shouldn’t require changing any of the tests as long as the outcome is the same. This will simplify refactoring a lot easier.
  • Dynamic languages generally need more testing to assert they work properly than compiled languages. (Offline code analysis tools can also help.)
  • Race conditions are surprisingly more common than one generally thinks. This is because a computer generally has more TPS than we are used to.
  • Understanding the relationship between throughput and latency (http://en.m.wikipedia.org/wiki/L…) can be very useful when your systems are being optimized. Related;
  • Many times high throughput can be achieved by introducing smart batching.
  • Commit your code in small, working, chunks and write a helpful commit message that summarizes what you did and why you did it. Working commits are a prerequisite for bisecting bugs (Git – git-bisect Documentation).
  • Keep your version control system’s branches short-lived. My experience is that risk of failures increases exponentially the longer a branch lives. Avoid working on a branch for more than two weeks. For large features, break them into multiple refactoring branches to make the feature easier to implement in a few commits.
  • Know your production environment and think about deployment strategies for your change as early as possible.
  • Surprisingly, shipping code more frequently tends to reduce risk, not increase it.
  • Learning an object oriented language is easy. Mastering good object oriented design is hard. Knowing about SOLID (object-oriented design) and object-oriented Design Patterns – Wikipedia will improve your understanding of OO design.
  • It’s possible to write crappy code in a well architected system. However, in a well architected system you know that the crap is isolated and easily replaceable. Focus on a sane decoupled architecture first. The rest can be cleaned up later if on a tight schedule.
  • Bus factor can be a serious risk to your team. Be a team player: Most of your code you write will be read or modified by someone else. This includes the code you write early in a project! Document (as appropriate) and write solid commit messages from the start. Also, code reviews and scripts can help a lot in knowledge sharing. Last, but not least, do make sure you aren’t the only one sitting on secret passwords etc.

Jeff Darcy

Jeff Darcy, “ask for topic bio” was a mistake

617.2k ViewsUpvoted by Abhishek Kumar, Search Quality Engineer at Google
Answer featured in Forbes.

1. Never reveal all that you know.

OK, seriously this time.  I think there are really a few things that distinguish great programmers.

  1. Know the concepts.  Solving a problem via memory or pattern recognition is much faster than solving it by reason alone.  If you’ve solved a similar problem before, you’ll be able to recall that solution intuitively.  Failing that, if you at least keep up with current research and projects related to your own you’ll have a much better idea where to turn for inspiration.  Solving a problem “automatically” might seem like magic to others, but it’s really an application of “practice practice practice” as Miguel Paraz suggests.
  2. Know the tools.  This is not an end in itself, but a way to maintain “flow” while programming.  Every time you have to think about how to make your editor or version-control system or debugger do what you want, it bumps you out of your higher-level thought process.  These “micro-interruptions” are small, but they add up quickly.  People who learn their tools, practice using their tools, and automate things that the tools can’t do by themselves can easily be several times as productive as those who do none of those things.
  3. Manage time.  Again it comes back to flow.  If you want to write code, write code.  If you want to review a bunch of patches, review a bunch of patches.  If you want to brainstorm on new algorithms . . . you get the idea.  Don’t try to do all three together, and certainly don’t interrupt yourself with email or IRC or Twitter or Quora.  😉  Get your mind set to do one thing, then do that thing for a good block of time before you switch to doing something else.
  4. Prioritize.  This is the area where I constantly see people fail.  Every problem worth tackling has many facets.  Often, solving one part of the problem will make solving the others easier.  Therefore, getting the order right really matters.  I’m afraid there’s no simple answer for how to recognize that order, but as you gain more experience within a problem domain – practice again – you’ll develop a set of heuristics that will guide you.
  5. Reuse everything.  Reuse ideas.  Reuse code.  Every time you turn a new problem into a problem you already know how to solve – and computing is full of such opportunities – you can save time.  Don’t worry if the transformed solution isn’t absolutely perfect for the current problem.  You can refine later if you really need to, and most often you’ll find that you’re better off moving on to the next problem.

A lot of these really come down to efficiency.  As you move through more problems per day, you’ll gain more experience per day, which will let you move through more problems per day, and so on.  It’s a feedback loop; once you get on its good side, your effectiveness (and value) will increase drastically.