程序员,你的路好走吗

━╅ 醉夜杂谈╆━ | 2007-10-26 21:39:00 | 阅读 2636 次 | 评论(2)

一次偶然的机会知道了迈克尔?波特,当时他作为嘉宾参与了中央电视台制作的《对话》节目。那期对话我看了两遍,深深为波特的学识和执着所折服,于是买了他的《竞争战略》来看看。

《竞争战略》系统地提出了一套指导公司制定竞争战略的框架。Framework可是程序员最喜欢的单词之一,就冲着这个词也得看看它都说了啥!全书共分三篇十六章,刚刚看完第一篇共八章,就忍不住要跳出来说点什么,因为我发现它不仅仅能够指导公司制定战略,甚至可以用这套理论指导我们的职业发展。公司里同事之间的关系,正如产业里各个公司之间的关系一样,是既竞争又合作的。我们做着同一个项目,却又争夺着有限的加薪、升职机会。我们所处的环境是相当复杂的、又是不断变化着的,多种因素交织在一起影响着我们的竞争能力,要想在这场较量中胜出,我们不仅要有一个明确的、恰如其份的战略,更要学会一套能够指导我们制定战略的工具。

不知道程序员是不是一个工作环境相对恶劣的职业,至少,做这一行的人相对喜欢抱怨环境恶劣,毕竟,软件行业在中国才刚刚起步,有太多的不规范之处。不过,我不打算在这里讨论这个问题,仅摘一段The Art of Unix Programming里的话,送给那些仍被其困扰的同行:

Software design and implementation should be a joyous art, a kind of high-level play. If this attitude seems preposterous or vaguely embarrassing to you, stop and think; ask yourself what you've forgotten. Why do you design software instead of doing something else to make money or pass the time? You must have thought software was worthy of your passion once...

To do the Unix philosophy right, you need to have (or recover) that attitude. You need to care. You need to play. You need to be willing to explore.

看到这个once的时候我被深深地感动了,不仅仅因为它让我联想到了“曾经有一份真诚的爱情摆在我的面前……”,而是因为它让我再一次认真地想一想,是不是要沿着这条路走下去。

我一直坚信程序员就是我所想从事的职业,可以实现自己的价值,而且现在的工作环境不错,有相当大的自由度,但是在日常工作中,却时常会有挫折感。我清楚地知道自己想做什么,可是我不知道自己所想做的是不是能够得到同事,甚至是公司的认可,是不是可以凭借所做的事情获得相应的回报。我知道必须和同事合作,但是又不得不和他们竞争有限的加薪机会;我希望能有一个长期的、持续的发展,但是竞争的存在使得我不得不做些短期的工作,使年度总结不至于太苍白,我知道得平衡一下,但却不知道到了哪里才算平衡。

我越来越觉得个人的发展与公司的发展之间的差距没有想象中的那么大,可以试着学习一些发展公司、甚至是发展经济的知识,也许可以帮助我更加有意识地发展自己。毕竟这是一个经济的世界,关于经济的理论应该有着更广泛的用途。这是我第一次尝试着用专业之外的知识指导职业发展,我将以自己为例,运用《竞争战略》第一篇里讲述的理论,剖析竞争环境,制定竞争战略。

形成竞争战略的实质就是将一个公司与其环境建立联系。——《竞争战略》

《竞争战略》第一章名为“产业结构分析”,指出“一个产业内部的竞争状态取决于五种基本竞争作用力”,即“进入威胁、替代威胁、买方侃价能力、卖方侃价能力、现有竞争对手的竞争”。显然,直接套用是套不上了,不过,倒是可以借鉴一下波特的具体分析过程。

进入壁垒和退出壁垒

这两个壁垒的高低决定了职位的竞争激烈程度。进入壁垒越低,潜在进入者选择这个职位的可能性越大,竞争越激烈。这个道理很直观,就拿我从事的编译器开发为例,通常情况下编译理论被认为是计算机科学里最晦涩艰深的学科之一,大多数人学过就忘了,唯一记得的就是难学。这样的话,即使有从事这方面工作的机会,也会选择放弃。那是不是进入壁垒高了竞争就不那么激烈呢?也不是,还要看退出壁垒。想想看,我费了那么大劲入了门,谁要是让我改行我还不得好好寻思寻思啊,总不能让前面的心血白白浪费了,怎么也得把投资回收的差不多啊。在我看来,那些偶然进入编译器开发领域的人,要么知难而退、早早退出,要么越陷越深,不忍放弃;而真正促使竞争激烈的,是那些有意识地进入这个领域接受挑战的高手、天才。由于人才难得,做这一行可以获得相对高薪;可是高手云集,要取得成就,有所突破就很难,容易产生挫折感,“既生瑜,何生亮”是最贴切的描述。

其实壁垒不仅仅是技术上的,还包括感情上的,尤其是退出壁垒,很多人也确实是这么想的,想想都做了这么久了,有了感情了,索性一直做下去,不再换了吧。而转换成本是进入壁垒中的一个重要因素,我们可以从两个方面分析它,一是跳槽后做同样性质的工作,虽说工作内容在理论上是基本相同的,但形式上却可能是完全不同的,这时就要花费一定的力气去熟悉它;另一方面,老板找人替换我的代价也可以看作是转换成本,比如提出“软

文章评论,共2条
Avatar
1楼: 燃燒 发表于 2007-10-26 21:40   回复
预留:

团队协作能力

曾经有这样的感受,与某些人合作非常舒服,而与另外一些人在一起就像是噩梦。我相信,这不仅体现了一种态度,更是一种能力,也许就是传说中的“团队协作能力”吧。尽管团队协作能力非常重要,但大多数人对它的理解十分有限,我就为此困惑过、苦恼过。

隐约觉得,团队协作能力并不是一种可以轻松掌握的能力,仅仅有协作的愿望更是不够的。说起来有些尴尬,如此重要的一种能力,我们竟然说不出它到底指什么,更不知如何衡量、如何学习,有种听天由命的感觉。

一个人的力量是有限的,只有大家携起手来,才能取得更大的成就,而团队协作能力则能够确保众人的合力大于单个人的力量。对于如此重要的一种能力,决不能这样听之任之,一定要不断地学习、锻炼。

XP十分强调metaphor的作用,一个准确、形象的metaphor可以让人迅速理解、掌握问题的本质。

足球是我最喜欢的运动,喜欢看,也喜欢踢(虽然已经很久没踢过了)。足球场上四种角色——前锋、中场、后卫和门将,一共11个人组成了一支球队。通常一名球员只以一种角色出现,但是他不仅要与角色相同的同伴协作,更要与其它角色的队友一起为争取比赛的胜利而努力。每名球员不仅要清楚自身角色的职责,还要明白其它角色在战术上存在的意义和相应的作用,因为他必须通过与其它角色交互来获得比赛的胜利。他不仅要在抽象的概念上明白一支球队是如何通过分工协作来完成整场比赛的,还要掌握具体的技术细节以完成相应的战术要求。在此基础上,如果球员提高个人技战术能力,成为对球队拥有显著影响力的球星,就可以增强整个团队的实力。更加完美的是,球员们还能感受到球队整体打法存在的问题,并通过不断地尝试形成新的风格。当年,伴随着全攻全守、防守反击这样的新式打法横扫足坛的,必然是一支伟大球队的诞生。

我想,团队也应该和球队一样,要想成为具有生产力的团队,其成员必须既理解整个系统运作的抽象模型,也有能力完成自身角色所赋予的职责,这两种能力加在一起就是“团队协作能力”。一名伟大的成员则不仅可以通过不断增强个人能力来增强团队按照模型运作的能力,还会随着实力和经验的积累推动系统运作模型的演化。

知道了什么是“团队协作能力”,如何学习、训练就是自然而然的事情了。两手抓,两手都要硬。之所以将对系统抽象运作模型的理解提升到如此的高度,是因为成员交互过程中很多的矛盾、冲突来源于系统固有的缺陷,不随成员的变化而变化。对于这样的矛盾,我们应本着对事不对人的态度来处理、解决。

Avatar
2楼: 燃燒 发表于 2007-10-26 21:41   回复
学开发,只看软件工程著作是不够的

近日看了两篇IEEE Software上的文章,讲述开发软件究竟需要哪些知识,以及怎样学习。

[1]中提到,如果你希望通过阅读软件工程著作了解和学习如何开发软件的话,恐怕难以如愿,因为这类著作更愿意关注一些轻量级的内容,如项目管理、软件开发过程改进、进度和成本估计等等,而软件开发本身由于是整个软件工程生命周期中最难以理解、也是理解得最少的一部分,所以只能抽象地讲讲,甚至被完全忽略。

然后,文中列出了一系列技术问题,并指出,只有在设计和编码的前前后后解决了这些技术问题,才能使开发和维护工作更轻松。我觉得其中最精彩的部分是"Considerations before design"一节,作者认为在设计前所有开发人员必须掌握两方面的知识——problem-domain expertise and solution-domain expertise。业务知识的重要性就不用多说了,现在网上不知多少文章劝告那些将近30岁的开发人员不要一味钻研技术,要想赚大钱必须对业务特别熟悉。对此我不敢苟同,能够理解和能够描述之间还是有很大差距的,何况任何技术都有它自己的局限性。比如“庖丁解牛”这个典故,它说明的是对牛的结构越清楚,肢解的速度越快,对刀的损耗也越小。然而,如果连刀背刀刃都分不清楚,又如何来解牛呢,即使对牛再了解。当然,刀作为一种解牛的工具其复杂度是很低的,很容易掌握,它与软件开发技术的复杂度是不能比的,可偏偏就有很多人在无视、否认软件开发技术的复杂性。

那么,为什么软件工程教科书都不教这些知识呢?[2]给出的解释是,首先,业务知识与软件无关,它超出了软件工程学的范畴;其次,能在程序设计语言手册、系统文档、以及库手册上找到的技术知识往往过于具体、涉及过多的细节,而更多的技术知识甚至只存在于一个个程序员的经验当中,还没有被总结出来作为一种可以教授的知识。文中还提到,除了这两类知识外,problem-solution integration expertise也是不应忽视的。否则,岂不成了“纸上谈兵”!根本不知如何运用的知识又怎么能算知识呢?

课本不教,大家是从哪里学来的呢?“人类是如何学习的”是心理学研究的问题之一,一般来讲,有两种学习的方式——模仿和摸索。既然没法教,我们也只好摸着石头过河了。

The practitioner is using his or her intelligence to find and then build linkages between the problem domain and the solution domain.  As observers have noted, programming is an endless struggle with How? Why? What? Whether? and When?  Typing takes place when enough questions are tentatively answered to permit the programmer to put a structure in place. [2]
那么,老师们又能做点什么呢?  作者提出了四点建议,其中最后一点是:

Fourth, teach by doing.  Software engineering is not book learning.  Teach with problems and projects where students (and teachers) labor to build and modify nontrivial, even real, systems in working groups.
知道了学什么,以及如何学,“大家有没有感到这个世界美好了许多啊?!”

--------------------------------------------------------------------------------

[1]. James A. Wittaker and Steven Atkin, Software Engineering Is Not Enough, IEEE Software Vol. 19, No. 4
[2]. Nicholas Zvegintzov, Do We Know Enough to Each Software Engineering?, IEEE Software Vol. 20, No. 5

游客请输入验证码
浏览339878次