William J. P. Laboon
University of Pittsburgh
Department of Computer Science

As a would-be software engineer, I was eager to get my feet wet in the “real world” of programming. At the beginning of my sophomore year, I heard about the co-op program through friends of mine in Engineering. Although I had minimal time to prepare everything, I rushed around writing my resume, interviewing with prospective companies, and the rest of the work that co-opping entails. I won’t mince words – it was exhausting. However, it was easily worth it.

I decided to co-op for Medrad, Inc., located in Indianola, PA (about 15 miles northeast of Pittsburgh). Medrad makes vascular injection systems, ancillary magnetic resonance imaging equipment, and other medical imaging niche market products. We are the worldwide market leader in sales of vascular injection systems for Angiography and Computed Tomography (CT) and fast becoming the leader in Magnetic Resonance (MR) injection systems and MR coils.

FIRST ROTATION (January – May 1999)

I was brought on as Medrad employee with the Service Engineering department. The Service Engineering department generates testing, calibration, and repair procedures for in-house and field service personnel, as well as creating hardware and software to assist them in these procedures. Specifically, my assignment was to create an application that communicated with an EnVision CT Injector via its proprietary serial protocol, querying the system’s memory for a list of recent system errors and displaying these errors to the user along with auxiliary data, a description of the error, and the repair sequence to follow. This would allow Field Service personnel to troubleshoot and fix problems with injectors more easily.

This application took almost all rotation to finish. As a medical device company, Medrad follows a very regimented software development policy, which I was not experienced with. In addition, I was developing the application in a language I had never used before (Microsoft Visual Basic), using technologies I was unfamiliar with (RS-232 serial port communications and SQL, among others), and interfacing with an injector which I knew little about. I just sat down and talked with various people to get information, as well as reading and doing a lot of exploratory coding. By the end of the rotation, not only did I have a working application, but knew quite a bit about EnVision internal software, Visual Basic, and other technologies.

Not only did I receive practical experience, but also some theoretical background. Part of the EnVision communications protocol involves calculating a Cyclic Redundancy Check (CRC) checksum on each packet. The math I learned here directly helped me in CS 1501 Data Structures and Algorithms.

SECOND ROTATION (August – December 1999)

During my second rotation, I had several responsibilities. First was to change the EnVision calibration application to a version which could be used by non-Medrad technicians. As it was written using 16-bit C++ and Microsoft Foundation Classes (MFCs) , I had to learn a lot of obsolete technology just to understand what was going on. Shortly after comprehending the overall flow of the old application, I had a working, documented application which could keep track of the number of pot and pressure calibrations used on a separate, encrypted security key.

Throughout my second rotation, New Products was busy developing the Spectris ISI (Imaging System Interface), which would allow Spectris MR Injectors to communicate with the imaging system in an MR suite. For SDE-Test Group I performed software and hardware testing of this interface, using debuggers, logic analyzers, and other tools. I also learned about the process of testing, and how to develop test protocols that would check a maximum number of situations and ensure that products met requirements. In addition, studying the Spectris’s RTOS helped me out with CS 1550 Operating Systems, which I took the spring after my second rotation.

EnVision and Spectris Injectors are built using similar architecture, and I mentioned to my supervisor that it would be relatively easy to expand my first application to transparently work with Spectris systems, as well. In addition, other features that would be useful to Field Service, such as viewing keystroke logs and injection history, could be added. I received the go-ahead to work on this project.

THIRD ROTATION (May – August 2000)

During my third and final rotation, I was involved with multiple projects and acted as a resource for many other people at Medrad. This is when it first hit me that not only is Medrad providing me with valuable experience, but I am providing them substantial support as a technical resource. While I wasn’t exactly a guru, I had useful information for other people working on EnVision and Spectris injectors as well as more mundane computer technology. For the duration of this term, I worked half-time for Service Engineering and half-time for SDE Test Group.

For SDE Test Group, I worked with a team of other programmers to create a universal PC to injector interface to handle all the cases where Medrad personnel would need to work with the internals of our new injector line. In the past, separate applications were created by Service, Manufacturing, R&D, and any other departments that needed to access internal data. As my past experience was with developing Service applications, I was in charge of writing the Service user interface to this software, as well as the VBA “scripts” (lists of commands for the injector to execute) that Service personnel would use. Truth be told, this was the best part of my co-op experience – working with a team to solve a company-wide, persistent problem.

During the rest of my time with Service Engineering, I continued writing the EnVision/Spectris analysis software as well as laid the groundwork for a new version of our EnVision calibration software. This was the first assignment that I was helping out with from the very beginning - seeing a need and designing requirements for a product to fill it. This filled a big gap in my experience, and enabled me to state that I had experience with all stages of products’ life cycles.

CONCLUSION

There is no way I would pass up an opportunity to participate in the co-op program. The experience I have obtained as a co-op is more than just another line on a resume; it is proof that I can function in the demanding field of software engineering. When I started out, I wondered if I could hack it... there were all these exceptional programmers around, talking about things I barely understood. Some times, the lines of code on the screen were the same all day, with the only evidence of me being there a bunch of equations written on a notepad. Eventually, however, the jumble of math and acronyms began to sound like English, and just when I was ready to switch my major to Theater Arts, I’d understand the algorithm.

Medrad itself is a great place to co-op. The environment is extremely friendly and jovial, while still allowing you to get work done. Playing Wiffle ball during lunch breaks (my batting average is 0.400), my cubicle neighbors heckling any living organism in a 10-mile radius, weekly intern/co-op lunches: I’m going to remember these as much as how to calculate a linear regression. Management is approachable and listens to employees. In fact, when the CEO, John Friel, heard that I was thinking about going to his alma mater for graduate school, he set up a meeting with me to discuss it. Some companies will throw you in a cubicle, not knowing what to do with you; Medrad typically expects you to act as a real software engineer. It is a challenge, but the skills you get out of it are invaluable. You can’t learn everything in the classroom. I highly recommend the co-op experience, and co-opping at Medrad in particular.