December 16, 2005

Reading Time: 2 minutes

Last Updated on May 28, 2009 by stlplace

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.

Chasing the bug

Reading Time: 2 minutes

Last Updated on May 28, 2009 by stlplace

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.