Leaving IBM

To be honest, this is probably the most difficult post I have ever written. This is majorly because there is a ton of stuff I want to say but I’m unsure whether I should keep them public or should keep it to myself. Another factor that makes this post hard to write is because the span of drafting. I have been drafting this post since April in 2016, right after when I decide to start the whole process of quit-IBM-and-get-a-PhD project.  I used to use this post as a log to record things and feelings when somethings happens around me at IBM. Frankly, if I take a look at the stuff I record (mostly are rantings) retrospectively, lots of stuff still hold but the anger just passes away with the time. So, that year-long drafting really makes me hesitate even more because the mood when those stuff are written are gone. However, two years can be a significant amount of time and quitting IBM can be called “an end of era” and I should give a closure to my happy-and-bitter experience with IBM anyway. So, here it goes.

 

Thank you, IBM!

I’m really thankful for the opportunities working with IBM. This experience really makes me grow both technically and mentally.  Technical-wise, I have the opportunity to get hands on experience with DB2 development. DB2 as a database engine is extremely complex. It has over 10 million lines of code and it is way beyond the scope of any school project. Working on those projects are quite challenging because there is no way you can get clear understanding of every part of the project. I still remember when I attend the new hire education on DB2, there is one guy says: “I have been working on the DB2 optimizer for over 10 years but I cannot claim with certainty that I know every bit of the component I own.” This fact really shocks me and based upon my experience so far, his claim still holds but with one subtle assumption, which I’ll talk about later. There are lots of tools are developed internally and reading through both the code and tool chains are a great fortune for any self-motivated developers. I pick a lots of skills alongside: C, C++, Makefile, Emacs, Perl, Shell, AIX and many more. I’m really appreciated with this opportunity and I feel my knowledge with database and operating system grow a lot since my graduation from college.

Mentally, there are also lots of gains. Being a fresh grad is no easy. Lots of people get burned out because they are just like people who try to learn swim and are put inside water: either swim or drown. I’m lucky that my first job is with IBM because the atmosphere is just so relax: people expect you to learn on your own but they are also friendly enough (majority of them) to give you a hand when you need help. I still remember my first ticket with a customer is on a severity one issue, which should be updated your progress with the problem daily. There is a lot of pressure on me because I really have no clue with the product at the very beginning. I’m thankful for those who help me at that time and many difficult moments afterwards. That makes me realize how important is to be nice and stay active with the people around you.  Because no matter how good you are with technology and the product, there are always stuff you don’t know. Staying active with people around you may help you go through the difficult moment like this by giving you a thread that you can start at least pull. In addition, participating with toastmasters club really improve my communication and leadership skills and more importantly, I make tons of friends inside the club. Without working at IBM, I probably won’t even know the existence of the toastmasters club. If you happen to follow my posts, you’ll see lots of going on around me when I work at IBM. Every experience you go through offer you a great opportunity to learn and improve yourself. Some people may look at them as setbacks but for me, I look at them as opportunities.

toastmasters1

( the picture on the left is all the comments people give to me about my speech and on the right is the awards I have earned inside the club in these two years)

With the help of all those experience, I have developed a good habit of writing blogs (both technical and non-technical), reading books, and keep working out six days per week. All those things cannot be possible if I work at a place where extra hour work commonly happened. I’m very thankful for IBM for this because staying healthy both physically and mentally are super critical for one’s career. Even though those stuff don’t directly come from IBM, but IBM does provide the environment to nurture this things to happen.

 

IBM has its own problem. The problem is centered around people. There are many words I want to say but I think I’ll keep them secretly but I want to show my point with a picture:

ibm_survey

I don’t know why IBM’s term “resource action” on firing employees and the sentence “IBM recognize that our employee are our most valuable resources.” bother me so much. I probably just hate the word “resource” as a way to directly describe people and how this word get spammed so much around IBM. I know everyone working for a big corporation is just like a cog in a machine. However, what I feel based upon lots of things happened around me is that IBM as its attitudes represented by its first-line managers (because those people I commonly work with) makes this fact very explicitly. It hurts, to be honest. No matter how hard you work and no matter how many prizes you have earned for yourself and your first-line manager, you are nothing more than a cog in a machine, which is not worth for high price to have you around because there are many cogs behind you that are ready to replace you. They are much cheaper, much younger, and more or less can work like you because your duty in the machine is just so precisely specified, which doesn’t really depend on how much experience you have had under your belt. To me, that’s devastating.

This leads to the problem that talented people are reluctant to stay with company. My mentor and the people are so good with DB2 have bid farewell to the team. That’s really sad to me because they are the truly asset to the company and the product. The consequence of this is that crucial knowledge is gone with people. Some quirks existing in the product are only known by some people and once they leave the company, the knowledge is gone with them. That makes mastering of the product even harder. That’s the subtle assumption that the person makes during the new hire education and that’s also part of the problem when working with legacy code. The whole legacy code issue is worth another post but one thing I now strongly believe is that any technical problem has its own root cause in company culture and management style. To me, I’m not a guru now but I cannot see the way to become a guru with my current position, which scares me the most

That’s it for this section and I’ll leave the rest to my journal.

Advertisements

Source code security

Well, this is a post that I started on 2016-04-15 and I finally finish today…

Yesterday morning (04/15/16), when I came to the office, I got a bad news from my manager: he was informed by security that I had an abnormal checkout of code on Monday, 04/11/16. The way how things work regarding source code security in our lab and probably in IBM other labs is that security will track each developer the frequency and quanity of checkout each day. They collect some statistics and alert the first-line manager when something potentially terrible happened. For instance, if I usually checkout code twice per day and each time around 20 source files, but on 04/15/16, I checkout 3456 files in day will certainly set off the alarm. Believe me, this number is exactly the number I was informed from my manager. What did I do on that day? It turns out that I need to make a special build on top of a GA build for a client and I need include all the code change specifically for this client in the past plus my code this time. The way to make a special build is that we use some scripts to check out the source files that are needed to be changed and merge the code, and run test buckets on them. Those will involve tons of checkout & checkin. After all, I successfully explain this to my manager and everything works out at last.

What interests to me for this incident is that this is the first time I realize the power of Clearcase. I have never heard of ClearCase until I join IBM. Back to the college, I solely work with Git and I feel extremely uncomfortable when I firstly work with ClearCase. However, from this incident, I personally start to feel like ClearCase is probably more powerful than Git on security level. Basically, in Git world, I need to fork or clone the repository so that I can have a local copy of ALL the source code and to start work on my branch. There has some problem in terms of security because I literally need to have all the code locally before I can work on my stuff. Make branch on the remote repository also has this issue. However, in ClearCase, I only need to first make a dynamic view and only check out the files I need to modify. If I check out too many files that will raise warning like this time. This security checking mechanism works great with ClearCase because:

  • There is a central server to hold all the source code. A Corporation can simply monitor the checkout behavior of this central code repository.
  • the quantity of checkout is different from person to person. In Git, it feels like a standard way for everyone to checkout all source files even you only need to modify one. However, with ClearCase, that can be different from person to person. This will the statistics monitoring checkout becomes meaningful.

I’m not saying Git is bad. In fact, in IBM, we are starting to have GitHub Enterprise that hosts on SoftLayer behind IBM firewall. That is really a great news for me because I can finally have “social coding” experience that I have been enjoying so far outside of the work. It will make some work I have done tailored specifically to fellow IBMers more organized and easy to get. I don’t need to attach the code inside emails sent to each member of the team that we collaborat with one by one. I can simply send the git repo to their team lead and each member of their team can access simultaneously. Plus, having Github inside IBM also helps me to track issue with the code I own and again, saves ton of communication cost for me.

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.

 

 

 

 

 

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