My first IT job – TechRepublic

I’ve worked in IT, primarily as a system administrator, for 25 years in a series of challenging and rewarding jobs. I’ve witnessed first-hand how the IT world has evolved in terms of cutting-edge hardware, software, and new inventions. Many skills I use today I learned at my first IT job.

I started my first full-time IT job in the fall of 1996. I recently moved to the Raleigh, N.C. region and was hired to work at IBM in Research Triangle Park. The position involved testing hardware and software processes with an emphasis on looking for bugs and documenting procedures. Oh, and I earned $38,000, which for a single 25-year-old male living in a southern town in the mid-1990’s was not bad by any standards.

Work environment

I was assigned to a 1,600-square-foot lab, which displayed four rows lined up with various computer equipment, workstations, servers, and monitors. The hardware was IBM workstations currently under development; servers, which were released to the general public; and software, which was IBM’s OS/2 Warp 4 operating system, both workstation and server versions.

SEE: IT jobs 2018: Hiring priorities, growth areas, and strategies to fill open roles (Tech Pro Research)

My company workstation ran Windows 95 on an x486 processor with a whopping 16 Mb of RAM. The system had a 100 Mb hard drive, and both a floppy, and CD drive.

The main network was a token ring network. Yes, token ring. I think it was all of 16 Mbps. We also had a 10 Mbps Ethernet switch for testing purposes.

Day-to-day duties

My job entailed running through checklists and testing all of the hardware components of the workstation models under development including CPU, memory, disk, and various functions in the BIOS.

My boss, Daryl, sat several hallways away from me in the labyrinth that was the facility. I shared the lab with some other technicians who engaged in similar testing. I remember one gentleman setting up several monitors, which then played an Edie Brickel music video over and over again, to the point that I knew every scene and note by heart. His goal was to measure MTBF (mean time between failure) on those monitors.

SEE: Hiring kit: IoS developer (Tech Pro Research)

I was also assigned the task of testing certain server functions and writing them up. One stellar example involved the OS/2 RPL (Remote Program Load) function whereby hypothetically you could boot a server and have it load an installation image, which would then install OS/2 Warp 4.0 over the network.

This was quite an adventure for me because existing documentation was subpar (hence the need for me to establish the official steps and test them out). An IBM technician from Scotland actually came to North Carolina to walk me through the process, which I fully documented both for token ring and ethernet networks.

I still own those guides. You can find the ethernet version here, and the token ring version here. Note that the ethernet version ended up entailing 100 separate steps, and the token ring version was more modest, clocking in at only 68 steps.

Valuable lessons

During this job, I experienced the rigors of testing equipment over and over again, and the humdrum it can entail. However, the job also taught me not to be complacent nor to rush through checklists without thoroughly tying up all the loose ends. I even found various unexpected problems on a few systems, which forced me to keep focused.

SEE: Hiring kit: User experience specialist (Tech Pro Research)

Handling complexity was another skill I gained—documenting the server RPL process was a herculean task. While it seemed hopeless after I hit a few dead ends, bringing in some outside help provided the solution. As a result, I’ve never hesitated to call on available resources to help despite the temptation to seek out the glory of single-handedly finding a solution.

Large company culture

This job was also my first experience with a large company culture, and it was an eye-opener. IBM may have had plenty of money, but it was easy for projects or even individuals to get lost in the shuffle. Over the years I’ve come to prefer working in smaller, more intimate settings with a wider array of responsibilities. (However, IBM did have an excellent cafeteria, which served barbecue every Friday.)

My boss Daryl was laid-back and carefree to the point that he rarely checked up on me and never minded when I took time off. He also wasn’t a penny-pincher like other bosses I have known; perhaps another sign of a large company mindset whereby cost savings aren’t as high a priority as getting results.

I was used to rigid bosses who demanded constant updates and punctual attendance. Daryl’s personality and outlook was refreshing, but it also made me become my own motivational force lest I turn into a slacker (I knew a few of those during my time there.). To this day if I am at the office with little to do I become uncomfortable and seek out endeavors to engage my time. I like leaving at the end of the day with the feeling of accomplishment.

When I left the IBM job I needed to write up the details of the duties I conducted, so I learned the importance of proper documentation to leave a solid trail for the next guy (or girl) to follow.

SEE: Hiring kit: Multimedia designer (Tech Pro Research)

How things changed

The speed and breadth of technology have evolved drastically since 1996. Servers and workstations contain much more powerful components. OS/2 is a thing of the past (sadly; I quite liked it), and networks are more robust. I replaced my pager with an Android smartphone. Pay rates are higher, as well.

However, many of the same work processes continue to exist. System testing still remains critical, as well as thorough and sufficient documentation. Self-motivation remains a highly valuable skill, and the ability to sufficiently withstand monotonous or repetitive tasks is also the mark of a successful IT professional (Hint: Automate that as much as possible).

Also see