I have completed a full 4 semesters of co-op work with IBM in Endicott, NY. In spring/summer of 1998, I worked in the systems group of the Travel/Relocations department. During my second rotation I worked with an engineering group in the Microelectronics department. I gained many skills in the time spent working on different projects at IBM. These skills, however, pale in comparison to the experience of seeing, first-hand, how daily operations take place in a huge corporation.
In 1998 I worked in a systems group that supported system operations for Travel/Relocations. In the beginning, I was relegated to maintaining REXX code. While I wasn't exactly thrilled to be programming in REXX, I was definitely enthused to be in a position to see how a corporate accounting system works from the inside and surprised to see how heavily dependent such a system is on a relatively simple scripting language as REXX. I also learned many lessons and tricks of the trade as they apply to code maintenance from this portion of my job. After I had become very comfortable with the REXX language, I was able to complete my assignments with greater ease and began to feel that I needed a bigger challenge. After talking with my manager about this I was given the assignment to develop a two part application that would be used by the programmers in the department to submit and approve change requests. I started out developing the program using IBM Visual Age C++. After fiddling with VAC++ for a few weeks, trying to understand the poor documentation provided, I realized that I would need serious training just to learn how to use this tool. At about this time I had started toying around with Java 1.1 on my own time and was very pleased to find how easy it was to develop GUI applications with the JDK. I suggested that I abort the VAC++ project and re-implement it using Java, noting that it would save a lot of time not only because I found it easier to program in, but also because we needed the program to run on OS/2 and Win32. My program lead approved the switch and I began work immediately, making more progress in a few days than had taken me weeks with VAC++. By the time I was nearly done with the change request application, I found out that IBM was taking over Lotus' payroll process and I was given the task to make the jobs auditing job easier, while other programming groups were trying to design a way to incorporate the Lotus payroll into IBM's system. The Lotus payroll process was extremely paper driven and the auditing process often took days of tedious work to complete. I was asked to eliminate some of the dependence on hard copies of the payroll register. Luckily I had been playing around with Perl at the time and upon experiencing the power of Perl regular expressions, I decided that I never wanted to parse a text file with REXX again. For the remaining 2 months of this rotation, I worked closely with the accountants and was able to eliminate much of the dependence on hard copy documents. In my first co-op rotation I experienced my introduction to real programming projects in the corporate environment and improved my skill set considerably.
In 1999 I began work in a brand new department, which was just one floor up from the Travel/Relocations department that I had worked with in 1998. Just about everything was different about this department. It was made up of mostly engineers as opposed to the accountants that inhabited my previous department. I also had an odd position within this group, being the only programmer in the department. This had its good and bad points; it was good in that I was able to experiment with new technology without having older programmers trying to force me to use older technology (which only happened a few times in my previous experience), but was bad in that I didn't have those same older programmers to turn to when I needed advice on a particular problem. All things considered, I enjoyed the autonomy, but would rather have that pool of knowledge to draw from. My first few projects dealt with simplifying some things for the engineers. This usually involved making information available and searchable on the corporate intranet. The largest project of these projects was an assignment to come up with a replacement for an old DOS program that assisted engineers in the printed circuit board (PCB) drilling department in preparing drill machines for operation. This program was called the 'Kitting program' because it assisted the part of the preparation called 'Kitting' and the engineers involved were called 'Kitters'. I spent a few days talking with the kitters and reading through a few thousand lines of garbled C code, trying to figure out how the existing system worked. After getting a pretty good idea of what was going on, I decided that I wanted to develop the new application as a Web-based application. One of the biggest issues leading me to this decision was the fact that many of the kitters were using OS/2 machines, making platform independence an issue. My first design involved a java applet, but this quickly fell apart as I realized that not all browsers supported java very well. My second design was to use Perl on the NT server running IIS that was provided to me. My first reaction was to suggest that I get rid of the NT box, as I was more comfortable with Unix/Linux and its complete and robust set of tools compared to NT's lack thereof. However, the NT box was already serving a critical role in the drilling process, and being unaware of any other machines fit for the purpose, I decided that it would be better for me to deal with NT than to go through trying to secure a completely new machine. A few weeks into development I realized that the program would be much more powerful with a database backend. After talking this over with my supervisor, the order for IBM DB/2 arrived in a week or so. The nightmare began. After about the 5th install of DB/2 on the NT machine, I was finally able to start writing the backend Perl code. I then found out that there were "issues" with the Perl DB/2 database driver that caused certain valid operations to fail. Things were not looking good and I was willing to accept most of the blame personally, even though deep inside I somehow knew that NT was to blame. Then it happened. One day my supervisor took me into a storage room where he wanted me to take a look at another NT machine that needed to be set up. I noticed that opposite the NT machine was another machine whose monitor had a "Red Hat" character in the corner. When I asked my supervisor about the box, he goes "Oh yeah, I was playing around with Linux on that machine." At this point I had to restrain myself from physically executing a back-flip. After explaining to my supervisor the success I had had with Linux, Apache, and Perl in my own experiences and my current plight with NT, IIS and DB/2, he approved the switch. I chose PostgreSQL as my database backend, knowing it to be very flexible and a decent performer from my personal experiences. In a few days I had the new platform up and running and was well into the development process. I remember a distinct feeling of relief to finally not have the technology getting in the way of my primary goal, which was to help the engineers. As work continued, I had several meetings with the engineers and kitters and came up with several time saving features that were impossible with the old program. At some point I realized that I had not just replaced a deprecated program with a more modern one, but I had implemented a completely new system that saved the time and effort of many people .
My co-op experience has given me a chance to see many different aspects of business computing projects. The programming experience I gained from co-op'ing is definitely invaluable, but the experience of building and dealing with professional relationships was every bit as important.