damien.h

The Empathetic Mindset

For any engineer reading this, I’m pretty sure at some point in you career, someone has told you that engineers alone are not able to make great products. And I can see they are probably right.

Stereotypical engineers are known to create stuff not suitable for human consumption. Typically, those products either pack a stellar amount of features that are hidden behind convoluted interfaces, or boast some features that only interest like-minded people of the engineers themselves.

But why is that?

Because by nature, humans tend to think for themselves. One’s judgements are always based on his own past experience. When you think about how a certain product feature should work, you’ll naturally search your brain looking for pleasant situations you’ve once had using similar products. For an engineer, he’ll recollect memories with his own favorite products. And what’s the most important and beloved to an engineer? Tools. Tools are what defines an engineer. Therefore, products designed and created by engineers tend to be just like tools – form follows function.

But the problem is, this also means humans are limited by their own experiences. One cannot see beyond himself. One’s own memory is the whole collection from which he searches for ideas. In the case there’s no perfect match, he picks the closest thing possible. For an engineer, who almost always deals with tools, tends to draw references from his favorite tools no matter how the product relates to tools. That’s his best judgement nevertheless.

This gives rise to the common conception that engineers are often not the best product designers. However, based on the facts above, this statement is no more accurate than saying that a inexperienced non-engineer often doesn’t come up with the best product ideas. Typical engineers suck at product design because products are not always meant to be used by engineers themselves. And engineers have limited experience using products not interested to themselves. The same applies to non-engineers when the product is conceived to be used by other kinds of people than themselves. For example, when a non-gamer product designer works on a product targeting to gamers.

So the real question here is not that whether it’s an engineer or not, but that whether one can think on behalf of other people, the target users of the product. That is, to think empathetically.

Thinking empathetically is a conscious process. It’s like self-discipline. It’s what one voluntarily applies to oneself, resisting natural tendency. It not only requires one to actively seek outside of his own experience, but also demands one to greatly expand his experience by trying out many new things, new roles, and new ways of thinking. If you are a driver, try  the passenger’s seat. Only then will you understand what a passenger wants. Just like self-discipline, thinking empathetically is hard. That’s why great products are not common. And innovative products are even more rare.

The empathetic mindset applies not only to engineers but to non-engineers as well. I reckon that it’s the single most important factor that could lead to a great product. And in fact, I believe if engineers can learn to think empathically, they are more likely to become a great product designer than others. Why? Because being able to understand the various details and limitations how a product is built and works can help one form better judgement about how to best put it to work, especially when tradeoffs are necessary. If a certain feature for an iPhone app is so CPU-intensive that it impacts battery life, it’s the engineer who knows it the best. And it’s the engineer that can think of a reasonable alternative as a better design. On the other hand, a non-engineer product designer often needs to understand the engineering details of a product in order to do the same, while it’s probably harder.

It’s not that engineers can’t make great products. It’s people without empathetic thinking who can’t. This has nothing to do with being an engineer or not. Once you learn to apply this mindset to yourself vigorously, everything else will follow.

伟大产品的哲学

一直在思考这个问题,如何定义伟大的产品,怎么样才能做出伟大的产品。这个星期某天又折腾了一把Quicksilver,注意到了About窗内的老子语录,真有茅塞顿开的感觉。这不就是最好的对伟大产品哲学的概括吗?!难怪Quicksilver能达到这种境界。

为无为 事无事 味无味 大小多少 报怨以德 圆难于其易 为大于其细 天下难事 必作于 天下大事 必作于

  1. 难/易,是对”Getting Real“哲学的概括
  2. 大/细,是对Mac(包括iPhone)哲学”polish the hell out of it“的概括

我想,要做伟大的软件产品,参照这两条足矣。要是几千年前有电脑,老子就一定是古代的Steve Jobs了。遂发至Twitter与友共勉。

平台不是一天建成的-从开发者角度看国内SNS平台技术

题外先说一句,最近太忙,欠着的GAE+Django开发SNS应用的文章一直没写好,很抱歉。之前给康盛的《站长》杂志写过一篇简单的稿子,准备整理和丰富下具体的代码例子再发布到本Blog上。

上周末把测试完毕的Py51放上了google code,至此我已经为校内UCHome Manyou,以及51这3个目前国内最主要和最先开放的SNS平台都发布了各自的Python SDK。通过这些工作我对这几个SNS平台技术有了比较详细的了解,有不少经验想分享。今天写下来的主要是一些技术细节,可能不是你感兴趣的。但是目前还没看到有从细节方面总结的各平台的开发经验,所以觉得还是值得写一下。

魔鬼藏在细节中

网站面向的是所有普通用户,而开发者平台面向的是有专业技术背景的开发者。设计和实现API,是难度最高的软件工程,需要出色的技术和经验。

国内SNS的开放平台,主流都是模仿Facebook F8平台的,所以可以称作F8系平台。但虽然从表面看和F8平台的设计基本一致,仔细接触的话就会发现,技术方面的差距其实很大。

  • 校内平台

校内是国内最早开放的F8系平台,我从开放不久就开始在校内平台上做开发。在校内经过一段时间的开发,明显感到校内平台的仓促上阵,和技术实力的捉襟见肘。刚开放的时候,整个平台功能极其单一。XNML只提供非常有限的重用组件标签(现在也没什么改善),不支持除了inline方式以外的css,不支持js(这两个最近已经支持了)。最严重的是校内明显对API服务器的负荷缺少准备,API调用经常堵塞超时,还动不动发生整个应用服务器长时间无法正常工作,所有应用都没法打开的问题。而这样的问题持续了不少时间都没有明显改善。

不过最夸张的还是校内API不设防的安全机制。校内平台对来自第三方服务器的API调用从刚开放到目前一直是不做签名检查的。记得你在新建校内应用时候得到的API Secret字串吗?其实这个Secret根本就用不到,就是摆样子的。做过Facebook开发的同学肯定知道Facebook App也是有一个唯一的secret字串,校内看起来和Facebook平台也一样,到底有什么区别呢?

Facebook平台要求第三方应用调用其API的时候除了调用参数还要提交一个签名字串,而这个签名字串就是用调用参数外加应用的secret做的md5 hash。由于你的secret是唯一而不公开的,那么平台就能通过你的签名字串来唯一验证这个API调用是不是来自真正的应用本身。

而校内平台在接受第三方应用调用API的时候并不需要和检查签名字串,这样,只要得到了某个应用的API Key,那么任何应用就可以在调用API的时候冒充其他某个应用了。而得到一个应用的API Key也是举手之劳,因为API Key是明文POST到校内服务器的,任何人只要用一下某个应用,截取应用发出的POST就能得到它的API Key了。于是,就在大赛期间出现了某名列前茅的第三方应用利用校内自己“特权”应用的API Key突破平台限制获利的事件。

  • Manyou平台

Manyou平台在国内来看是目前技术方面最严谨功能也最强的一个F8系平台,从功能和稳定性来看都做的不错。这点和康盛拥有若干PHP大牛是分不开的。但奇怪的问题还是有的。

首先是有些过分神经质的签名算法。具体细节现在在Manyou开发者wiki上应该有更详细的解释了,但是我在写PyManyou的时候在签名问题上着实费了不少周折。不过,有这么神经质的签名算法可见Manyou对平台安全的重视,所以还是应该赞一下的。

另外有一个诡异的细节问题,通过MYML的表单POST到应用服务器地址的多值参数,会让django无法解析成list。

比如,我在一个form里有一批多选框,input的name是”select[]”。在正常情况下,包括facebook,校内和51.com,这个form在post过来以后,从django的request.POST里可以通过getlist直接得到”selectp[]”值的数组。但是在Manyou上,从django得到的POST数据确是”select[0]”, “select[1]”这样的变量名,也无法通过getlist得到多值参数数组。select[n]这样的变量名对PHP的处理来说是正常的,但是我不理解的是为什么其他平台都没问题,唯独Manyou要设计成这样,对非PHP的语言缺乏考虑了。

  • 51平台

实话说,51.com就算是网站本身,也是几个里面技术上最落后的。不说别的,在utf8编码早就成为广泛接受的标准的今天,51.com还用的gbk编码。这也造成了51平台混乱而毫无意义的编码问题,就连用51官方的PHP SDK也需要为编码折腾。

提交到51应用服务器的非英文参数值,如果编码和51期望的不一致,就会发生签名错误。经过和51技术人员的沟通和自己的摸索,最后终于发现,尽管声称一切用UTF8,但实际上对非英文数据,在计算签名字串的时候必需用encode(‘GBK’)把unicode字串编码成GBK二进制格式,而在向51服务器发出POST的时候又要用UTF8。另外,在发布中文feed内容时候,也需要把中文编码成GBK。

平台不是一天建成的

国内SNS平台到目前为止给人的感觉是,为了让手上的投资有地方用,抓着开放平台和第三方应用的概念炒一把。从校内51平台的开发协议就可以看出,两个SNS的管理层在理念上和它们竞相模仿的Facebook只是貌合神离。这方面Manyou确实做的最正宗,只是Manyou的模式太独特了,还需要发展和完善。

不过值得赞扬的是,虽然校内和51第一版协议都让人非常无语,但是在听到了开发者的骂声以后,两家还都是用开放的心态确实在改进。而随着年底前更多开放平台的加入,相信国内的SNS平台在明年能逐步发展到脱离幼稚期。只是,其实一开始肯定能料到开发者的抗议,为什么还要来侥幸一把呢?

Interface First:为什么我们学到的一切都是错的

ok,我承认有点标题党了,不过这并不妨碍讨论这个有趣的话题。

我在读Getting Real的时候,发觉其中一些观点和我在刚开始计算机学业时候的那些“错误”观点出奇的一致。Interface First就是一个典型。

我从小喜欢涂涂画画,梦想做一个设计师。对于软件,我也认为一个出色的界面是非常重要的。其实对于任何东西,我都觉得,如果能做的漂亮,为什么不呢?人的本性不就是喜欢美好的事物吗?所以,对于我自己作出来的东西,我都喜欢先把界面设计好,设计到自己觉得满意,很漂亮,才好意思拿出去给别人用。不然一个丑巴巴的东西,自己看见都不喜欢,何况给被人用呢?特别是以前做Flash的时候,游戏也好,片头也好,小小的动态菜单也好,总是喜欢费尽心思的作出最漂亮的界面。

然后我意识到,我的习惯对于一个程序员来说太“反常”了。身边的老师同学,基本都对漂亮的界面不屑一顾。“先把逻辑实现了,界面到最后随便做做就行了”没错,软件最根本的不就是功能吗?界面不过是一件随便换的衣服罢了。

好的程序员,基本都有非常糟糕的审美。牛人写出的软件,经常都有常人无法理解的界面设计,搭配上只有色盲才能欣赏的色彩。我们认为,这样才是真正值得崇拜的大牛!

明白了这点以后,我努力克服喜欢从界面开始构思一个软件的习惯,一切从逻辑开始!需要实现的use case是哪些,如何实现它们,怎么做到效率最优,等等。我们为我们程序员写出的丑陋界面感到骄傲,我们提供的是强大的功能!界面?对不起,我们忙着研究算法,没时间考虑这种肤浅的事情!

当软件开发成了我的职业以后,我一度感到非常幸运,幸好当时改正了不好的习惯。在企业软件的开发团队里,根本没人关心用户看到的界面怎么样才最好!任何一个软件,都从功能需求开始,根本没人会提出需要什么样的界面。lab的唯一的2个美工(我很讨厌中文对artist的这个称呼)都坐在办公室的一角,一年也不会和我们开发团队说上几句话。

但是,我错了,我们学到的,一直认为是对的事情,都错了!很显然,设想你自己就是用户,面对一个简单易用的软件,另外是一个强大复杂但无法上手的东西,你更喜欢哪个?

问题是,企业软件的购买者根本不是软件的使用者;而使用者通常又是没有能力影响购买决策的。

所以,这些造成了企业软件的一个畸形问题,usability成了难以攻克的障碍。有些产品确实可以宣称市场占有非常大,功能应有尽有。但是不可回避的事实是这些产品用起来无一例外都非常烂。在这点上,M$作为从消费市场起步的公司,确实做的很好。而传统只作企业市场的公司,拿出来的产品基本都是用起来及其不爽,最终用户抱怨不断的。

Getting Real的这一篇短短的文章解释的很清楚。只有看到自己的软件长得什么样,才能不断的完善它,不光从界面上,功能上同样如此。

看到这里我很高兴,我根本不必克制和掩饰自己的本来想法。软件作出来和任何其他产品一样,都是给人用的。与其做一个丑陋的东西,为什么不费劲心思做一个美好的呢?

最后,我并不赞成走另外一个极端,只追求华丽的外观而没有实质有用的功能。这方面的反面例子我最喜欢用金山词霸,建议用一下就知道一个实用的软件是怎么做到华而不实的。

我赞同的是能帮助用户在解决问题同时得到愉快体验的设计,解决问题当然还是根本,不然还是本末倒置的。

10 ways to kill your star programmer

1. Make them project managers.
2. Make them managers.
3. Enroll them in all kinds of full-length time-consuming leadership classes.
4. Ask them to attend numerous stupid meetings and conference calls on behalf of the team.
5. Ask them to spend a lot of time sorting out various best practices and coding guidelines that will never be read or used by anyone else.
6. Bug them with licensing concerns with every code library they want to use.
7. Ask them to submit purchase request for software they want to use once a year. If they miss the time, they have to wait another year.
8. Lock them in the project important for your promotion and reject their requests to leave the project because they think it’s boring.
9. Reject their requests to travel to tech conferences they are dying to attend so that you can balance your quarterly cost.
10. Tell them you love them so that you can keep their pay low without feeling guilty.

Tech-savvy? Biz-Savvy?

An IBM development VP recently answered an interview. One of the interview questions was that what suggestions he’d have for the mass of developers for them to become successful in their careers. The VP mentioned that one important factor was to become biz-savvy.

Well, I believe this holds true for the typical developers who enjoy caffeine and coding through the nights. They do need to look beyond their Dilbert stereotype and become a little bit more biz-savvy if they don’t like pointy haired bosses to rule them.

But that also depends on who you are now and who you want to be.

I have personally seen more than a few great developers who shows excellent technical potential, and yet decided to do more business. They just became mundane business people.

This is especially a problem with the highly thriving and restless atmosphere in China. I grew up as a typical technical guy. So I can understand this increasingly heavy pressure from unnamable sources to developers. There are people who are making a lot and lot of money out there, by simply doing “business” stuff. Yet, developers are required to sit in small cubicles staring at computer screens all day while their bosses often don’t show enough respect to them.

This is a different story in China than in the US or other western countries. In China, young people have to fight for existence first. Young graduates coming fresh out of school are pressed to find better paid jobs. Their families have spent years of family income for their education. The government doesn’t pay for their unemployment. Their parents have retired, with little pension. Housing price has been skyrocketing. They will have to work for almost an entire life to afford a simple apartment. Everything is about money.

Yes, and it seems that the highest paid positions are in doing business. Everyone is talking about successful entrepreneurs. Everyone wants to do management.

I have interviewed dozens of students. And I can feel that for many of them, the sheer passion in technology is the least likely reason that they choose to become a developer. The valid reason is simply that being a developer has a steady pay at the moment. And many fresh employees eagerly seek to become “biz-savvy” even before they become “tech-savvy” enough. Because they believe they see more money in that.

What’s the problem? Why are less-than-2-year-experience developers crazy about executive biographies and fancy marketing stories more than ingenious technical stuff? Why do CS majored students long for consulting jobs where software productivity is sarcastically measured by lines of code?

Someone has to fix this problem in China. And I believe it’s the employers themselves’ responsibility to do so. Treat your developers fair first, before you even dream about your master business plan. Without the tech-savvy folks, nothing will be realized.

Browse Happy logo

My tweets

2016年九月
« 八    
 1234
567891011
12131415161718
19202122232425
2627282930  

分类目录

Articles

Fancy Stats