So, what’s it really like working in the software industry?

Having worked in both a big software company and a retail company in which the IT department exists only to serve the business needs, it’s interesting to take a step back and compare the two, and discuss what I’ve learned from both. This discussion will be especially helpful to new college graduates who are just entering the job market – I make an effort to explain everything so that someone who has never actually worked as a software engineer can understand this discussion.

Straight out of college, I was hired by a big (fortune 500) database software company. I was working on the team that built the tools that were being used by DBA’s (database administrators) to manage the database software.

For my first assignment I was assigned to a testing effort that was meant to test our applications, and how they worked and integrated with the actual database.

It was interesting because there really was no formal training at all. Some of my coworkers helped get me set up with the applications that our group worked on, and i was basically told to play around with them for a few days and read the manuals. After this, they wanted me to jump in to the testing effort and help out there.

I was working w/ a database guy, and after a few days it became pretty clear that he thought I was an idiot – I have a tendency to ask questions about everything, regardless of what people think. Because, I figure that it’s better to ask questions that may appear stupid at first than not know what the hell you’re doing later.

DON’T LET WHAT OTHERS THINK BOTHER YOU

So, after about a week I was told that I was no longer on the testing effort – they never told me why, but I knew it was because the database guy didn’t think I knew enough to work with him. But, a couple days later since they had nothing else for me to do, they put me back on it the testing effort anyways.

I hadn’t been wasting my time – I spent a great amount of time and effort in understanding and thinking about the tools and how they worked/integrated with the database. So, when they put me back on the testing effort they were very surprised when I found some rather significant bugs that only someone who had a decent understanding of the tools could have found. So, the general opinion of me changed quite fast – which I thought was funny because just a few weeks ago they thought I was an idiot.

What I realized is that sometimes people have unrealistic expectations of how fast someone can pick things up – I hadn’t been there even a week and it was almost as if they expected me to understand everything by then. I don’t think this would have been possible for anyone straight out of college, no matter how intelligent the person. So, I learned that I should try not to be affected by other people’s opinion of me – and I think this is a valuable piece of advice for anyone who hasn’t already learned this lesson. Whether you’re dealing with a CEO, CIO, or your own manager – you should learn to be an independent thinker. This definitely doesn’t mean that you should not be open to advice – but just learn to see if that advice appears to be truthful to you first.

After the testing, I moved onto writing some code for some of our applications. I was given a relatively small RFC (Request For Change) to work on – an RFC is, as the name says, a change that’s requested to existing software. In our case, the RFC’s came from the database team since the database is what really drove the company. We were considered ‘client’ side because we created the applications that were actually used to manage the database.

It was quite overwhelming at first – because the applications were complex as was the code. And, once again, I didn’t receive any formal training – just a brief introduction to the code. But, I found that if I took a very specific functionality in the application and then tried to understand the corresponding code then it became a lot easier to understand the code. Basically, this was the ‘divide and conquer’ approach – and I think that it probably was the best approach I could take to understanding things. If I had just tried to understand the code without actually playing around with the application then I would get nowhere because the code by itself was very hard to understand without looking at the application.