Way to be pro

This is gonna be a live update post. All the experience I acquired in order to become a *professional* programmer are listed here. This will be a reminder for me, and hope it is somewhat useful to you 😀

M/D/Y

09/01/15:

1. Be aware of coding convention used in the file

What’s the difference between the following two chunks of code?


if (block_buf > REQUESTS_BLOCK_BUF_MAX){

my_requests_block_buf = REQUESTS_BLOCK_BUF_MAX;

} else {

my_requests_block_buf = block_buf;

}


if (block_buf > REQUESTS_BLOCK_BUF_MAX)

{

my_requests_block_buf = REQUESTS_BLOCK_BUF_MAX;

}

else

{

my_requests_block_buf = block_buf;

}

I guess you would say they are literally the same. In fact, that was what I thought initially, and I chose to write the code like the first one. However, in the code review, this chunk of code is commented by reviewer “Note the coding convention in the file.” Then I realized with more than 3,000 lines of code, all the condition structure is following the second one I listed above. So, consistency in style is really the key in professional programming.

2. Don’t add redundant debug statement

Following the code chunk I added above, it is probably natural to add a printout statement to see if my_requests_block_buf is actually set to the right value. So, I added:


pdTraceData1(FUNCTION_TRACE_ID,
             1992,
             PD_SINT(my_requests_block_buf));

However, this statement may not be OK in the professional setting. There is a clear cutline between what can include in development phase and what should include in actual product. The debug statement is OK for development phase: developer need to immediately make sure everything work correctly so far before moving on to next part, and this is exactly the incremental development philosophy. But, once developer are pretty sure the value he get is correct, he need to delete the debug statement. With excessive debug statements, the performance of product hurts. 

3. Treat comment as serious as code

I developed a bad habit to joke around in the comment during the college, and I somewhat carry it out to the real job. This is one of the comments I wrote in my recent work:


// cheat on initialize_server() function
#define REQUESTS_BLOCK_BUF_MAX_OLD 1024  

If this comment appears in a hobby project or the project that shared with limited people, it will be fine. However, it might not be appropriate when comes to real business. And, this comment is essentially useless: why named “OLD”? What do you mean by “cheating”? My fellow developers will have no clue what I am trying to convey here.

 

 

 

 

 

Advertisements

After three weeks…

As a fresh new grad, I have been work as a software developer at IBM China Software Development Laboratory for three weeks. Here are some…well…thoughts 🙂

My job@IBM is to incorporate cutting-edge technology into DB2 Federation Server (FS). Even though I am entitled with Software Developer, I also need to play some role as a L3 Technical Support. This role can be either interesting or boring to hell…  Usually, the request for L3 support is submitted by L2 support. Depending on the type of problems or the level of expertise of L2 support themselves, the request can be extremely clear or extremely unclear. By clear, I mean they can identify the root cause of the problems; and by unclear, I mean they only observe the problems, and can provide some description about what causes the problem. The former one is interesting to me because if L2 support can actually discover the root cause, then usually the problem is we omit some bugs in our product. Then, as a fresh grad, I can learn a ton about product code-wise. However, the latter one can be extremely boring: incompetent L2 support tries to spam alert emails all day long even calling your late night in order to tell you how serious they think the problem are, and then you skimmed the problem with sleepy eyes, and the problems turn out to be some config issues… This experience can transcend from boring to frustrating when 90% of requests can be fallen into this category…

However, the bright side is even in those boring cases, you can still learn a ton about product, which cannot easily obtain by staring at code solely. It is called user experience. My first impression with our team’s product is that it is extremely powerful: user can query different kind of data sources (i.e. Oracle, Teradata) with DB2 interface only. This is cool… but the price that imposed on the user is that they need to go through some tedious setup procedures: check if the type of ODBC driver matches with product; check if ODBC env variables are correctly set; check if FS env variables are correctly set. All those things are not included in installation script, which means that user have to do them manually. After seeing all those trivial requests, I think automation has to be done fast and right… So, lucky enough, my team’s tech lead support my idea, and I’m on my way to save life XD. I will never sort out how important the automation setup of our product can be without reading through tons of config type of problem requests sent out by L2 support.

So, the conclusion of this verbose whining is that: I’m pretty happy with my job for now.

Have a nice day!

Z