So, what’s it really like working in the software industry?
Having worked in a big software company, I thought it would be good to share some of the things I’ve learned working in the industry as a software developer. While some of the things that I’ve learned can probably apply to any job – whether it’s software related or not – some things are specific to the software industry. I think that 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. Basically, if a company used our database software then they needed some specially trained people to manage the database – these people were called DBA’s, and my team created the software that was targeted to DBA’s.
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 – they basically told me to play around with the applications and read the manuals. 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 with 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. Most people who are starting new jobs tend to be too scared to ask questions for fear of appearing stupid. But, I know that perceptions change fast, and that it’s better to ask questions that may appear stupid at first than not know what the hell you’re doing later – this theory has worked out pretty well for me.
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 and integrated with the database. So, when they put me back on the testing effort they were very surprised that after a few weeks I found some rather significant bugs that only someone who had a solid 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. They clearly thought that when they hired me that I was really intelligent, since they kept saying things like “You’re smart, you’ll figure it out”. So, I learned that I should try not to be affected by other people’s opinion of me whether they are good or bad – and I think this is a valuable piece of advice for anyone who hasn’t already learned this lesson, because opinions change fast and usually are not accurate. 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.