Categories
Chinese articles Software development

Programming career

Reading Time: < 1 minute

I read this article from wenxuecity a while ago. Being a programmer for more than 5 years in the US, I shared the author’s view to great extent. I have made the mistakes he/she mentioned below (see bold text). I think the principle could be applied to other careers as well.

The article link is here.

==============================================
程序员生涯之我见
文章来源: 程序员 于 2005-07-31 17:35:56

程序员生涯之我见

在海外有很多中国人在从事程序员这个职业。我认识很多这样的朋友,发现许多人并不快乐,只是将这个工作当成养家糊口的工具。还有许多人工作努力而不能入门。我曾经在很长一段时间内也有过困惑,但最后终于走了出来。在这里谈谈自己的看法,希望对大家有一些启发。

俗话说“兴趣是最好的老师”。这话很有道理,但运用在事业上往往并不是这么一回事。在学生时代你可以追随兴趣天马行空,为未来作各种各样的设想。坚韧不拔而又有些运气的在后学生时代仍可在预设的道路上跋涉前进,甚至一帆风顺。而绝大多数同仁们则在生活所伏下的各种小圈套中纷纷落马,有的痛苦挣扎,有的怨天尤人,还有的则既来之,则安之,以失败者的心态接受生活的安排。这些为生活所改变的同仁们的共同点是不再(敢或愿)提对原先事业的兴趣了,如果曾经有过的话。当然,兴趣是会变化的。但因生活改变而生的新的兴趣往往难以长久,而人生苦短,又经得起几次改变呢?

和其它许多职业一样,从事程序员职业的可分成三种人:入门的, 不想入门的,和想入门而没有入门的。我对入门的定义是:喜欢这个职业并且有持之以恒的目标和努力。

入门的是极少数。如果一个程序员一直在从事这个职业,而且热爱并愿为之终老,我想他一定是幸福的。任何职业其实都是这样。我所在的公司有个年轻的老美,是负责三十多个程序员(包括我)的Software Architect,为人朴实而性格腼腆,但他对职业热爱的纯连我都嫉妒得要命。他好像可以不食人间烟火,可以没有任何爱好(他其实一年要度好几次假的,但全是老婆安排,当然也参加公司活动),但对几年前写的代码记得清清楚楚。他没有可炫耀的学历(服兵役间在一家小学校读的计算机本科)和经历(因为太年轻),在任何场合都总是腼腆地笑着(我将他研究了很久,发现他实在本性如此),毫不起眼,但我知道,他是被造化所祝福的。他可以一直思考一个问题,在半夜起来用VPN连上公司网络修改一个bug。我遇到过不少优秀的程序员,就没他这么纯的。

不想入门的程序员可能是这三种人中比例最高的。女的居多,家庭负担重的居多,思想活跃的居多。程序员职业为男性所主宰是一个事实。女孩子结婚后兴趣大多都变了,程序员工作辛苦,责任大,也就没什么吸引力了。很多程序员聪明而思想活跃,却不愿意喜欢这个职业。有的一直在琢磨怎么开自己的公司,有的天天研究炒股,还有的只想好好保住这个工作,完成分配任务了事。究其原因,一是将人生看得太“透”了,觉得程序员工作只是衣食父母;一是认为编程太简单,没啥好投入的;还有就是看不到出路,当一辈子程序员划不来。人各有志。对一些人来说,程序员只是人生经历的一部分,他们有自己所追求的目标。虽说这两年的IT不象五年前那么火热,但仍到处是机会,很多人通过程序员的工作进入IT而寻找机会。但对那些可能长久从事程序员工作的人来说,不入门实在太辜负了上天赐予的聪明才智。在美国的这些年,我认识了许多转行做程序员并做得不错的大陆来的朋友。附近一家老美的公司,软件研发部门中大陆来美读研毕业后留下来的有二十来人,多半是国内名校本科毕业的。这二十来人没有一个本科或博士是读计算机的,现在水平都很高。我用这个例子是想说明程序员这个队伍的素质是多么优秀,理应做出点事来。

在现实生活中许多人由于缺少机会而不能成为程序员。不少人是半路出家,而人过而立之年,要想的,要考虑的东西多了:家庭,孩子,健康,股票,老人,房子,车子,地位…。有一位朋友,国内名牌大学物理本科,来美国读了物理博士。他在博士期间喜欢上编程,上过计算机系的几门课。九八年博士毕业时计算机工作火热,就找了个程序员的工作,从网页做起。我看得出他是很想做一个优秀的程序员。这些年我们一直保持联系。可惜的是他为生活所迫,年年在找工作(他一直做的是合同工,收入会高些,家里上有老,下有小)。而博士学位在很多时候都是over qualify(资历过高)。这两年经济不好,更是动不动被解雇。最近他终于找到了一份稳定的工作-在银行里做全职的DBA (数据库管理员)。他人显得老了,语气也变了,只求有一份安稳的工作。他对编程的爱好依旧,但始终处于外围阶段,不是网页编程,就是DBA,只有业余时间学习一些.NET。还有一次,在2003年,Job market 正不好。我参加休斯敦中国人西区教会组织的Job Fair,目的是让教会里的人将工作机会互通有无。我当时因为朋友邀请去看了看。参加的人基本上全是在做或找程序员工作的。好几个年龄相当,还没找到工作的在和我聊起来时听说我是国内计算机系本科毕业的,一直在做程序员,都很踊跃,要和我讨论一些问题,并留下电子邮件地址。看到他们羡慕的神情,当时我还没觉得什么,可现在每想到此,都有些震撼。很多人如果得到了机会可能会成为很好的程序员。然而世事往往如此:得到的人不珍惜,珍惜的人得不到。

想入门而没有入门的有很多:学有专长,由于各种各样的原因做上了程序员,做长了发现也许要做很久,于是试图研究并喜欢它,却发现这很难。难就难在看不清自己的方向。我认识不少程序员,工作很努力,有抱负,业余时间也学习,考证书,可是方向换来换去,今天学Java,明天学.NET,后天又打算考MBA,到outsourcing的消息一传来,又灰心丧气。究其原因,数理化和许多其它的工程职业都已成型,研究方向明确,很多人通过学习会入迷而入门,知道自己的奋斗目标。软件工程行业才只有几十年的历史,作为一门科学还远不成熟,不能给程序员工作以明确指导。Microsoft的Visual Studio以及现在的.NET在大大提高编程效率的同时, 也使得编程变得前所未有的容易。仅仅在编程上钻研不仅难以入门,而且在日新月异的技术面前会产生光阴易逝的困惑。

在美国,很多中国人去教会,而且其中不少成了忠实的信徒。我周围有不少朋友如此,所以由他们牵线参加了一些中国人教会的活动。我问他们信教后最大的感受是什么,答:平安喜乐。看得出真正的信徒是蒙福的。这是我所向往的生活。但我至今还没有信教,因为我在没有参加教会活动前早也有过那种感受。我知道信教不是唯一的途径,对不同的人会有不同的方式。早在春秋时代的孔子说过“朝闻道,夕死可矣”。这里的“道”,我相信和真正的信徒的信仰是殊路同归。而我们人生,不管是从事什么职业,能“闻道”,也就“夕死可矣”。所以我一直在寻找在程序员这个职业里的“道”,也就是“入门”。

一日我读到了冯友兰先生的《中国哲学简史》,在网上广泛流传的电子版本。如获至宝。我第一次知道了原来我们的哲学家们也在研究这个“道”。不过他们研究的是与职业无关的,更为广泛意义上的为人之道。在书中,冯先生提到有各种各样的人,每种人都可能达到那种人最高的成就;而对所有的人来说,他们都可以达作为一个人最高的成就,为“圣人”,为领悟“道”的人, 为哲学的人。而中国哲学所研究的就是怎样可以成为一个“圣人”,达到天人合一。在书的最后他指出,中国人可以不信教的理由是我们有自己的哲学,我们不需要信仰,因为我们是哲学的。我至今深表赞同。基督教义让信徒体会平安喜乐,只需无条件接受即可。中国哲学则需要你思考去体会。两者的功用有异曲同工之妙。

三百六十行,行行出状元。无论一个人从事何种职业,都可以在工作中加深自己对人生的理解,都可以在对事业的探索中去领悟这个天人合一。我一直相信,入门的人是得道的,无论他的天人合一是来自人的本性,还是信仰或哲学。

在程序员这个职业里感受这个“道”,不同的人会有不同的理解,得由自己来体会。程序员不妨一读Fred Brooks的The Mythical Man-Month一书。作者是大师级人物,将软件工程的各个方向深入浅出地描述一遍。如果你已有几年在公司里当程序员的经验,读后或许会有拨云见日的感觉。其实我在美国读研时也上过软件工程一课,真没学到些什么,所以一直忽略了这门知识。现在计算机教育仍需要改善,有些课程设置并不合理,无论是国内和国外。像软件工程课,给没有几年程序员经历的人来人往说只会是纸上谈兵,而对有经验的人却往往是对症下药,醍醐灌顶。编程只是程序员工作的一小部分,而当你能对整个行业能有一个全盘的了解,你自然会找到自己的兴趣所在。

当你找到兴趣所在,无论是中国的哲学和智慧,对教的信仰,或是你内心深处对世界的体会,都会给你以信心和指导,不再会有疑惑。
=======================================

Categories
Business Fun Software development

NBA and team work

Reading Time: 2 minutes

I got chance to watch some NBA games lately. I am not a big NBA fan because I don’t have cable at home and I felt it takes too much time (usually 2.5 hrs) to watch a game. I told my friends who are big NBA (Yao Ming) fans that I only need to watch the final 5 minutes because that’s when a game gets decided most of the time.

Anyway back to the games. Last week there are a few superstars made steller performance in some games. Kobe Bryan made 62 points in 3 quarters against Dallas. Vince Carter scored 51 points against Miami. Both Bryan and Carter’s teams won the games. Then there is this amazing story, Allen Iverson scored 53 points but his team Philadelphia lost to Atlanta. I don’t know what exactly happened in that game. But I started to watch Allen’s game since 2000 and I can guess what happened. Allen, who is only 6 feet tall and 165 pounds in weight, is the most agile player in the NBA. I remember somebody (maybe his former coach Larry Brown) said “pound for pound, he is the best player in the league”. But at the same time, Allen sometimes relies too much on himself without passing the balls to his teammates. Basket ball is a team sport. Star player or team leader is very important. They make shots in the crunch time (final 5 minutes). Allen, Kobe, Robert Horry, Tracy McGrady and many others are those kinds of the guy. But superstars are not supermans. They can have injuries, illness or just bad days. During those times, their teammates’ help is more critical. Even if they are on the top of the game, they need to get their teammate involved. Because if you don’t make your teammate look good, they won’t make you look good too.

This can be applied to the software development and other businesses. In “mythical man month” I read an exceptional software developer can be as productive as 300 average developers. I believed it. I think the founders of Netscape, Yahoo and Google are those kinds of guy. That’s cool. But what’s more amazing is those guys are not running the show themselves. They know their limit especially in the business side so they asked some senior people to join the team. The results are obvious — success of the companies.

This does not means average developer (like me) are totally hopeless. First I think “exceptional developer” is very rare. My brother and I went to Google campus recently and saw some Google people at the packing lot. My brother’s comment was “they are average people like we are except they are lucky enough to be hired by Google”. So here is the hint: join a winning team. I am not saying “jump to the Google now” because they raised the bar very much. There are many winning teams including your current employer (you may not realize it). Do your work and help your teammates. Make your boss look good. They will make you look good too.

Back to NBA. My favorite team is Detroit pistons. In 2004 when they won the NBA champion they don’t have a guy in the All Stars game. The 5 starters are good players but are not at the level of Shaq and Kobe. But they beated the LA Lakers by the teamwork. 2005 Champion San Antonio Spurs is also that kind of team. Tim Ducan is a superstar but he is probablly most unselfish superstar in the league.

Categories
Software development

Chasing the bug round 2

Reading Time: < 1 minute

I was pretty stressed out debugging a problem last two weeks. Luckily I saw the light at the end of the tunnel yesterday. I found out the cause: the tolerance of transform matrix. This is a tough problem because it appears to me the problem occurred without any pattern. But later on I realized out of all the randomness, there is something in common: the misplaced components all end up in the same place. I implemented the fix this morning and it worked like a champ.

Tolerance played an important role in my world. I guess it’s just a way of life. The problem is the computer can not represent a number accurately. Say an inch is 25.4 mm, but in computer it is really 25.399999…If you convert the inch to mm and then convert it back, it maybe something like 25.398888. Now if you do a comparason of this number with 25.4, it won’t be equal any more. Similar things can happen for vectors, matrix, geometries, etc.

There are called rounded errors in numerical computation. I took a course on numerical computation in graduate school in Rolla. The theory was a bit abstract. But now I got the fun to play with the real stuff. It’s not as complicated as one might think.

Categories
Software development

Indian food and software developers

Reading Time: 2 minutes

Working in the software development these days also means working with people all over the world. Most notablly, Indian software engineers. I have great respect with my Indian colleagues. I know some of them from my graduate school. But I have to admit I don’t like Indian food. I have been to Indian restaurants in St. Louis several times with my coworkers but I did not really enjoyed it. But this does not means I can stay away from it. Like today.

This week we had food festival at my work place. The idea is everyone bring his/her own favorite dish and share it. I am not a good cooker and I am lazy so I did not participate. During lunch time I felt a strong smell dispersed from a cubicle nearby. Initially I thought it was some American food but later on I realized it’s Indian food (curry, spicy, etc). I had to leave from work early because I just can not stand it. But I think many American coworkers enjoyed it. Now I remember yesterday one of my coworkers asked if I liked Indian food. No wonder he was looking forward to it!

This reminded me of something related. Some of my Chinese friends complained it’s hard to understand Indian English but most American have no problem with it. One time I posed this question to my fellow American graduate student. He told me he would pay more attention when he listened to Indian students but there is no problem in understanding.

Another point I want to make (and I think we Chinese need to learn) is our Indian coworkers know how to market themselves. The food festival is a perfect example. While there are quite some Indian fans among Americans, not everyone likes Indian food (take myself as an example). But they prepared and marketed the food with enthusiasm. That’s what counts. Attitude, not the substance (taste, smell).

Now I wish I would not be at lazy. Maybe next year I will bring some crab rangoon or fried rice.

Categories
Software development

Chasing the bug

Reading Time: 2 minutes

As software developer finding and fixing the bugs (defects in software) is just a way of life. I have been debugging (find the cause) a tough problem lately. During debugging sometimes I wished I would have another job. But when I solved a real problem, the satisfaction can not be easily described by words. I bet a lot of people in software developement have similar experience. I want to share some of the general steps I take during debugging.

  • Reproduce the problem
    A lot people ignore it or treat it too lightly. But this is the first step. Make sure the problem appears consistently under the user-described situations; and the symptom is exactly as the user reported. Otherwise you will try to solve the problem “you see”, not “the user sees”. Maybe you will be lucky enough to “see” the same problem as “the user see”. But more likely you will be will be solving another problem, or a related problem. And the next day (week, month), the user will come back and shout at your boss: how come the problem you claimed “fixed” still exisits? You know how embarassing you will be at that time.
  • Simplify
    After “reproduce the probelm”, the next step is to simply. By “simply” I mean the real problem is ususally complicated, and it will take a lot time to run through debugger. The goal here is to simply the problem as much as possible. For example: delete unrelated parts from the raw data. You should be very careful in doing this too. Because you could eliminate the problem area in doing this, i.e., the problem will be gone if you don’t simplify properly.
  • Find the cause
    Here comes the real run. After all the analysis, time to jump into the code. It’s why we progrmmers are paid for, right? But it is also the most difficult part. I am still puzzled by the problem I mentioned at the beginning. Hopefully by stepping through the code, talk about the algorithm with the guru in your team, even ask a second pair of eyes to take look, we can nail the problem.
  • Fix or ask appropriate party to fix
    Then comes the politics part. I have to admit this is not my specialty. Luckily if the mistake is made by yourself, and you know how to fix. Life is good. But a lot of times the mistake could be made by somebody else, maybe some code written by another team member, or even a piece of software created by 3rd party. In these cases, you need to demonstrate the problem to responsible parties, bugging (asking) the people for a quick fix. Meanwhile your sales team or customer are already screaming.
  • Workaround
    Luckily, sometimes you can find a workaround the customer like. That provide cushion time for you or your team to work out a fix.