My First Job Was Boring: Confessions of a Medical Software Engineer

My first "real job" after college was working for a large defense contractor. I had interned with the company and was offered a position after graduation. Naturally, I was thrilled about the offer and the comfort of knowing that I had a job waiting as soon as I wrapped up my last year of computer science at Ball State University.

My internship had been typical of many: learning the ropes of the corporate world, learning that the process of creating software is very different than what is done in college, and generally performing a number of small tasks (the stuff that the "real" engineers didn’t want to do). As simple as the internship had been, I knew that the company did cool stuff, and that I wanted to work on that cool stuff. The following year, I was so excited to start my career that I didn't bother to take any time off before starting. I graduated on a Saturday and started my new job two days later. Looking back, it probably wouldn't have been a bad idea to take a few weeks off, but I was sick of ramen noodles and ready to start making real money.

This corporate giant had a traditional approach to engineering, one that came from a legacy of experience with electrical engineering and driven by the best perceived best approach at the time: The dreaded old systems development lifecycle (SDLC). Agile, RUP, and iterative design—these were things that I had never heard of. Even my computer science teachers hadn’t the slightest idea about the emerging approaches to software engineering. To be clear, I'm not being critical here. Software engineering as a discipline was well established at the time, but the silver bullet to good software design and development was still something of a constant question. 

The entire first week was spent on orientation, afterwards I was eager to get started—to be a real software engineer! But that didn't happen. I was on a project that required heavy up front design, and much learning (on my part) about digital signal processing and real-time embedded programming. A well-meaning manager provided me with piles of documents, I suppose with the expectation that I would learn by reading.

Read this. Done? Read this. Done? Read this...

All the documents looked the same, and it was difficult to keep my eyes open, much less comprehend the words. It wasn't long before I began dreading work and counting the hours to the end of the day. As far as I could tell, I was getting paid to do nothing. 

Had I chosen the wrong career? Would it always be this boring? I could barely stand the thought of reading yet another 100-page document full of words and acronyms that meant nothing. And the thought of spending the next 30 or 40 years like this was downright depressing.

There were several problems: I was a new programmer without the necessary background to get my hands dirty. My manager didn't really know what to do with me. The project I was on was in the early stages of design. And, \aAlthough I was eager, I was clueless.

There and then, design meant constant reading and re-reading and review of hundreds of pages of extremely specific requirements. The software requirements specification (SRS) was the master, and it had to be perfect before anyone considered writing a line of code. This phase of software could take many months—years even. The goal was to write perfect software by way of massive up-front design. Looking back, I suppose it worked for the corporation. For all of its flaws, the traditional SDLC was the best anyone had come up with. The defense contractor had plenty of money to spend on very long SDLC phases.

As I read, bored and frustrated, I wondered if I would remember how to dereference a pointer after so much time spent reading documents. I knew one thing: If what I was doing was software engineering, I didn’t want to do it.

The real problem not as much with the employer as it was with me. I was bored, and I didn't know what to do about it. I hadn't learned how to be a real-world software engineer. I was following the lead of others—folks who were content to take things nice and slow, all the way to retirement. .

Doug to the Rescue

Again, I was new to this world. I didn't understand how to change things. No clue. My job, as I understood it, was to do whatever my boss told me to do—nothing more, nothing less. And I had a boss who didn't have anything for me to do After several months of monotony, I worked up the courage to tell my boss I wanted to do something else. I think he may have actually been relieved—after all, he was given a young graduate as a new hire, but he didn’t have sufficient tasks for that hire. Any small employer would never hire an employee under such circumstances, but in the world of giant corporations, this happens.

Soon enough I was moved to another department. Although it was in the same building, this particular department had a number of people with a different mindset. It was a more vibrant group with much more enthusiasm. Even the lights in this new section of the building seemed brighter.

One guy, Doug, was a key engineer, and he was eager to spend some time with me. Why? I can only imagine that he saw something of himself in me—an eager 20-something who just needed a little direction.He shared some of the things he was working on. He wasn't simply doing that which was asked. He did much more. He explored ideas, created prototypes, and presented his findings. He was constantly busy, not because he wanted to impress management, but because he was a curious and energetic engineer. It was clear that he enjoyed what he was doing.

One conversation between me and Doug shifted my mindset. 

"Doug, how do you get to do all of this cool stuff? I'd like to get involved with this."

"Matt," he said, "nobody is going to ask you to do it around here. Just go ahead and do it, and then you'll get to do more of it."

As I think about this now it seems so very obvious, but at the time it was not. Perhaps my mindset had much to do with the world in which I grew up. Most of the people in my small home of Auburn, IN, union factory were workers. I was told from an early age that the foundry was a great place to work, and the labor union looked after its employees. These people went to work for their shift, worked hard, and went home. They did exactly what was asked of them. Nothing more. Nothing less.

Work, in my mind, was a place where you went and did whatever your boss tasked you with. Sure, I pursued a degree in computer science, but only because I knew from an early age that I really liked writing computer programs. I wanted to be a computer programmer when I grew up. I pursued computer science in college because I was fascinated by programming. It was fun and amazing to write code and see what it does—to discover what one can make happen, and build upon those discoveries. 

But as far as turning that desire into a career, my outlook was limited. I wanted to work someplace where the boss asked me to write software—and other than the task given, I didn’t understand that this was very different than working in a factory.

It wasn't until I met Doug that my eyes were opened to the fact that the direction of my career was in my hands, not my boss's. I learned something else: Doug was moving forward and contributing in big ways to the success of the department by doing more than what was asked. He was prototyping and experimenting, and using what he learned to guide the up-front design. He was doing Agile before any of us knew what Agile Software Design was.

Doug had all the same tasks on his plate as any other engineer. He too had to sit through long peer reviews and read through miles of documentation. But he was never bored. Maybe Doug had to learn the same way that I did. it is imperative to maintain that initial fascination that led to this career path in the first place.

It wasn't long before I got my hands on a TI DSP Prototyping kit. I wasn't presented with the kit one day out of the blue. I had to ask people about it, how to get one and how to get started. I began writing code—experimenting; learning what it all meant. Soon the words on the documents started to become clear. The words on the pages meant something. I wrote a state machine in C. Then I wrote an AM modulator, then an AM demodulator. I learned that the fast fourier transform that my professor rambled on about actually had some sort of purpose.

Integrity

In their book Becoming a Person of Influence John Maxwell and Jim Dorman say, "Integrity is crucial for business and personal success." Are these words true? I've certainly spoken with a good many people over the years who do not think so. In a post Sarbanes-Oxley world, it sometimes seems as though cynicism rules the day. 

But iIntegrity is a two-way street and the thing about having integrity is, it's generally not that difficult. As software engineers we're very often asked for time estimates, project status, and testing results from upper management. Do we pain a rosy picture, saying what we think they want to hear, or do we tell the truth? Acting without integrity in this regard can be tempting, but there is little question about which path is the right way.

The above really touches on a much more broad subject. The only point in bringing it up here is to note that, minimally, a software engineer should be motivated to stay on task for purposes of integrity. I say minimally because I think it can be very easy to stay motivated and highly productive with little need for strong willpower. Software engineers have jobs where we get to play most of the day. We get to put together a big, complicated puzzle. And we get to find new, interesting ways to do things. How can this be anything but motivating?

If you're bored at work, you're doing it wrong. Your boss is never going to be upset when you learn new things and take initiative. Don't expect your boss to constantly check to make sure that you're challenged and learning. Obviously this isn't to say that one should intentionally pursue distractions. Those of us involved in software engineering have plenty to learn with regard to the task at hand.

Also, if you're sick of ramen noodles, give it some time. You'll grow to love them again.

Matthew Rupert is a software architect for Ateb Inc. in Raleigh, NC and he also worked and consulted for XStor Medical Systems as a senior software engineer. He can be reached at [email protected] or http://matthewrupert.net 

Related Content

What's Wrong with Software SOPs, by Matthew Rupert

Using Agile to Achieve Rapid Failure