商业软件编程很无聊?(转贴)

【备注】以下文章转载自负暄琐话。是因为最近又有一些关于职业发展的思考。自己工作时间也不算短,回头来看,自己对职业(工作)的选择上从来没有考虑到自己的兴趣。或者,即使自己对某个工作没有兴趣,也没有仔细思考过,这个工作的定位,以及对相关行业的兴趣。以至于因为IT本身其实是为其他行业做支撑的,工作(项目)的变换导致实际从事的行业发生变化。比如:从证券到门户,到电子政务,再到物流。所以到现在,没有办法改变做IT必须依从一个行业的现状,而行业背景的不断变换,显然对这种职业道路的发展没有好处。没有了持续性,没有了行业知识的积累,IT知识也飞速更新。让人深深感觉到隐藏的危机。自己认为自己做事不是不专,而这一切都是在渐渐发生变化的,量变到一定的程度,自然发生质变。所以被迫要思考一下职业发展道路。思考一下职位、行业的变化,同时还要综合考虑一下当下IT行业的现状,那些需要IT的行业面临的问题是什么,未来几年他们的业务系统会发生什么样的变化?当前热门的技术是什么,那些技术是自己感兴趣的,那些技术是需要并值得跟踪的?以后会从事怎样的职位,这些职位会需要什么样的技能(管理技能、沟通技能)。所以,自己是一定要把这些问题看清楚的,然后找一个行业,一个业务方向,一些自己感兴趣的技术,不断跟踪、思考,这才是可持续发展的道路。

对于自己,一定要走可持续发展的道路。上面提到的是指职业发展的可持续,这当然要身体因素也是要可持续发展。有一个好身体,清醒的头脑外加和谐的家庭环境(当然也有社会、自然环境)才是这一切的基础。

(以后要多爬爬山,多出去走走,和所谓的学习、工作一点都不冲突。人活着要有精气神!)

好长一段备注,以下是转贴正文,我想计算机专业毕业,又在做某个行业内项目的人看了一定会有同感:

——————————————————————————————


商业软件编程很无聊?

这周读到三篇博客帖子。把它们串在一块儿读,对我们的职业发展非常有教育意义。

一篇是Thoughtworks前员工Ravi
Mohan写的,《但是马老大,商业编程就是无聊》。Martin
Fowler在一篇帖子里说,编写企业软件不光是捣腾数据。并不是只有解决算法问题,操纵硬件,和应用大量数学才有意思。关心顾客(马丁所谓的客户亲和力),全力让自己的软件为客户带来商业利益也是挑战所在,趣味所存。Ravi在帖子里不以为然,认为不管Martin
Fowler
怎么辩白,商业编程无趣是不争的事实。不信可以看看人心所向。从来只见有天赋的程序员屁颠屁颠地去开发编译器,操作系统,TCP/IP
stack,
大规模并行系统,高性能服务器,游戏引擎等系统级软件。哪怕优秀的商业软件程序员也无限渴望去开发系统软件。相反,从来没见那个能靠系统开发软件挣钱的牛程无限向往开发商业软件。这好比柏林墙没倒前,只见东德人拼死冲到西德去,没见有什么西德人拼死要到东德去的(愤青们就不用和我争论东德怎么好了哈。
Ravi自己的例子而已。东德好不好关我P事)。Ravi还说,哪怕Thoughtworks内部员工也无限向往系统编程。每次Thoughtworks讨论把生意扩展到嵌入式编程和非其它非企业计算领域时,Thoughtworks的员工们都士气高涨。然后Ravi引了老愤青Paul
Graham的话,号称集中精力攻克困难但定义清晰的问题完全是出于自我保护的需要,因为成天解决琐碎问题不能让人学到任何东西,只能让人变蠢。做系统编程给人的满足感比做琐碎的商业编程大多了。Ravi进一步谈到Martin
Fowler其实也承认商业软件开发遇到的问题太过随意,很多都是为了满足客户莫名其妙的要求,不会带给程序员成长的机会。他尤其赞同Martin说的“商业编程的真正挑战在于找到软件中能给客户的生意带来切实利益的东西。要做到这点,我们需要扎实的行业知识和技术功底。”。可惜的是,大多数商业软件程序员处于尴尬的境地:论行业知识不如行业专家。论编程技术不如真正的hacker(黑客这个词已经等同于cracker了,所以我还是用原文)。当然,这种尴尬情况在其它编程领域也存在,但症状没有那么严重。搞笑的是,Ravi说其实Martin算是商业程序员里比较幸运的,总有机会和牛人们合作,找出他的代码到底有什么商业价值,而这和普通的“编码人”有本质区别。这也是为什么外包的工作如此无趣的原因:商业方面的分析已经定了。编码的框架已经定了。承接外包项目的程序员发挥余地实在有限,更不用说趣味二字了。作者的要点是,要想让自己的工作变得有趣有意义,要么就下大力气变成业务专家。要么就变成可以玩儿转系统的编程高手。其实系统编程高手也是业务专家。只不过他们的业务领域恰好和技术领域重合。

第二篇帖子是Reg
Braithwaite
的一篇帖子,《商业编程没有那么难?》。这篇帖子同时引了Reganwald另外一篇短文,《怎么让编程变得困难》。Reg
在两篇文章里都谈到了同样的一个观点:商业编程从表面上看来都是广泛而肤浅的。程序员有大量问题要解决,但没有什么问题特别深刻。哪怕你用最新的技术都不足以让普通的商业编程变得更有意义。用Reg的话来说就是用Ruby
On Rails编程好比聆听Jaco
Pastorius,什么人都能干。只有在复制Jaco的盛宴时才能真正获取学习经验。还是以RoR为例。用RoR远远不够(其实不用也无所谓)。仔细研究RoR的代码,学习怎么设计自己的DSL才是正道。在《商业编程没有那么难?》里面,Reg举了三个例子。一个是从信用卡的使用情况实时判断被使用的信用卡是否被盗。一个是实时卡车调度问题,能针对路矿和递送要求优化卡车路线和发车时间表。还有一个是销售辅助系统,能学习潜在客户的特质,帮助销售决定是否跟进。嗯,两个模式识别和学习问题,一个调度和网络流优化问题。都是非常有挑战性的问题。都可以让一个普通的商业项目变得趣味十足(当然也能让我们的压力陡增)。当然,如果你对每月一张固定的工资单感到满意,知道自己的工作马上就要外包给西贡的大学生也能安然入睡,就不用自找麻烦了。作者的要点就是:挑战不是别人给的,而是在勃勃雄心驱使下,你自己找的。也许以后做每个项目时,我们应该给自己找点有挑战性的问题,激发自己的潜力。不然做的项目再多,也不过浪费人生。

第三篇帖子是XML发明人Tim
Bray
的一篇短文。在Tim的努力下,
JRuby的两个主程加入了Sun。新闻公布后Tim收到几乎所有JVM语言作者的询问,问为啥子Sun独选了JRuby那俩哥们,能不能给其它JVM语言也提供支持。于是Tim谈了JRuby受到重视的原因。首先,没人要求,没人给钱的情况下,这俩老大投入大量精力,运用各种技术把半死的JRuby项目盘活了。其次,JRuby背后有活跃的社区(大半因为Rails的风潮)。第三,他们善于交流,到处做报告,做让人印象深刻的演示,展示项目进展。第四,他们不断发放高质量的代码。每个版本都较上个版本有长足进步。也就是说,他们证明了自己的能力,展示了自己的领导才能,更重要的是他们不断交出优秀的作品。职业培训里常说要想事业顺利,要做到两点,搞出事(make
things happen),和搞定事(get things done)。JRuby是个很好的例子。

帖子的教育意义很明显,俺就不用在罗嗦了吧?

3,096 次阅读

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注