How to make ecto work with Ultimate Tag Warrior – Part II

[update: I have updated downloadable xmlrpc.php example for wordpress 2.1. It also fixes the wordpress 2.1 bug when getting category via xmlrpc. Check the end of the post. 2007-02-20] I once wrote about “How to make ecto work with Ultimate Tag Warrior”. In that article, I discussed how to make the wordpress with UTW plugin Read more about How to make ecto work with Ultimate Tag Warrior – Part II[…]

再谈Object Setting和Performance review

在中期review的时候发了一篇牢骚,引来了一些朋友的共鸣和反馈,一位guest朋友留言谈了他的经验: 量化工作也是职业化的一种吧。尽管我个人对此并无赞同或者反对。不过如果特别是说程序员做Object Setting,我有一点经验,不知道有用没有:最重要的当然是需要完成的项目。每个项目都会有roadmap吧?roadmap上的milestone就可以作为一个时间上比较靠谱的参考。然后开发时候,陆续把所有的任务都敲碎放到bugzilla里去。到项目结束/年度结束,考察工作其实就是review bugzilla。再不懂技术的老板,看到通过解决的所有的可预见的问题和中途修改好的bug报表(所以要用bugzilla,因为它能自动生成报表),也都会对一年的工作有数了。至于说performance,这个东西应该是相对的,而且最好是这一年度的bug报表对于上一年度的比较。说真的,这东西确实没有什么实际用处,谁会因为多写了一年程序就真的提高了多少performance,这种循序渐进的东西确实无法量化。 对目标的制定也许会很让人迷惑,我的不一定有用的经验就是写的越具体越好。百分比应该用在对项目完成度的衡量上。但是如果有百分比,就一定指出来那些没有包括进来的百分比是留在下一年了,还是有团队的其它人来完成。这对于项目管理者来说也会有帮助的。 定期review工作的好处是,可以及时发现blocking bug,并且对此做出相应的调整。但是管理者不见得能够实践后一条,这可能也不说明review工作真的没有用,只是管理者本身执行得不够好。 其实我并不反对设定目标和定期的review,我反对的是这种纯粹management oriented的长期目标设定和review。 实施敏捷开发有一段时间了,一个scrum的周期最长也就是一个月,每天都会花很短的时间做前一天的review和目标的调整。我体会到的这个过程的要点就是:review要及时,目标设定要随时调整。我对以年为跨度的object setting和performance review的最大困惑就在于两者的严重脱节。 实际上,这样长跨度的目标设定,更倾向于一个career plan而不是project或者product plan。而拿一个career plan作为年终performance review的依据,纯粹就是牛头不对马嘴。

从Object Setting到Performance Review

在三个不同的外企呆了一共快六年的时间,有一个共同点就是每年年初都要做Object Setting,年终要做Performance Review。不知道是这个做法本身有问题还是在中国没执行好,每年到这个时候面对一堆的表格我不知道要添什么,也不知道别人想要我添什么。其实说来简单,Object Setting无非是定一个目标,为这个目标制定一个计划,最后给一个衡量标准,怎么才算目标达到。Performance Review的时候就拿出你当年添的东西一一对照,哪达到了哪没达到。就象自己先下个套,然后钻。怎么看怎么别扭的一个过程。至今我仍然搞不清楚作为一个程序员该如何设定目标,我曾经这样制定过:我的代码(包括bug fix和新feature)产生的P1的bug不超过xxx个,P2不超过xxx个。第二年,为了表示进步,我需要这样制定:P1 bug减少5%,P2 bug减少10%。听上去和扯淡差不多。或者写今年我要做三个features,修100个bugs。更离谱。目标定高了是和自己过不去,定低了是和老板过不去,定实了到年终全变样,定虚了又没法衡量。大多外企的现状也使得Performance Review的作用落不到实处,高了不会升你低了不会抄你。每年两次轰轰烈烈运动的主要作用就是浪费时间。如果还有什么比着更无聊的,可能就是再加一个中期review了。

我小时候用过的电脑

托old computer museum的福,我可以再次重温近二十年前玩过的电脑: PC 8300-使用时间:1985年左右。那时候还不懂得任何语言,只会输入书上的“趣味程序”。印象较深刻的是可以用小图标画房子,按下键盘有很响的嘟嘟声。 Laser 310-使用时间:1986年左右。一度是我的梦中电脑,常常在周末去一家电器店看橱窗里摆着的Laser 310,心里默念”Laser就是激光的意思”。学习basic语言初期在电脑学习班里使用过。最终未能拥有。 sharp pc-1500-使用时间:1987年左右。Sharp出的超强便携电脑,我用过的除了主机还带一个打印机模块,另配专用磁带机,非常方便实用,八十年代很多单位的必备机型,鼎盛时期我家就放了两台。 最后,中华学习机-使用时间1988年以后。old computer museum 里没有这款电脑的照片,链接来自于donews wiki。我拥有的第一台电脑,是我真正认识电脑的开端。为了是否买这台电脑,家里曾经有过激烈的争论。如果当时的结论是另一个,不知道我现在会是什么样。

Getting Real

前天一打开信箱就看到37signal发布他们的新书Getting Real。19美元,电子版,不算贵,又是我挺想了解的内容,就买了“一本”。这是我第二次买他们这种印着我名字的电子书,对于一个习惯性盗版使用者,也算不容易了。 大概看了几章,内容不算丰富,如果你希望通过这本书学习互联网开发,还是省省吧。书里更多是互联网如果对软件工程产生的影响,传统的软件开发流程遇到互联网的新特点需要作出怎样的改变,其中的观点都来自于他们或者其他互联网应用开发者的实际经验,鲜活有力。书中的文字也都象是和顶尖的工程师交流,里面的观点或许不新或许你不同意,但一定会得到很多启发。