For my past few semester breaks, I worked at Wideband Systems in Silver Spring, MD as a Software Engineering intern. Wideband is a data recording and post-processing firm that has devices and software to record, store, and play back data taken during telemetry missions such as satellite missions or missile testing. During my stay, I developed and ported many of the file processing utilities for files containing data that needs to be tweaked or filtered.

A typical work day would consist of many similar tasks to that of many other software development jobs. I would arrive at work around 9 am, and log onto my computer. I would open up the Qt creator IDE, and start analyzing previous code or write new sections. To standardize development, we started using the Qt framework for C++, which gave us a good library for UI and frontend development, but most of the recorder-specific code was written in-house. Throughout the week, I would have meetings to present my issues and progress to senior developers, and would often collaborate with them to fix building or coding issues with my programs. I would also periodically check my code into the codebase using git and bitbucket, another company standard. Near the end of my stay for each break, I would typically spend a few hours making comprehensive documentation of the progress of my projects as well as some tutorials for the utilities.

In the very first semester of Colloquium we learned about logical fallacies and one specific topic kept being brought up both in future colloquium classes and outside of them: Occam's Razor. The data I worked with was at a byte level. Because I worked with the data at a number level, when debugging an issue, trying to collect all of the possible reasons for an incorrect outcome was a difficult task. Applying Occam's razor to all of the possible sources of a bug in the code would frequently fast track me to the issue. If the data was missing certain specifications, then it's most logical to first check if they had been specified to begin with, then see if they had been accidentally removed. My boss would often use the acronym KISS, meaning “Keep it simple, stupid”, which is a colloquial way to think about Occam's Razor.

I had wanted to work in the software field for a long time, ever since I learned to program. This experience gave me the opportunity to thrust myself into the field, but also opened my eyes to the drawbacks of software development. Like other office jobs, I worked by myself frequently, and would have the regular discomfort of sitting at a desk for long periods of time. It definitely helped me develop my C++ abilities, a very necessary language in the engineering industry today. Although I like most of the tasks of a software engineer, and I love problem solving, the overall workflow of it all was draining, and I'd physically tired despite not doing much physical work. I will definitely look for technological development internships and jobs in the future, but I don't know if my career lies in software engineering, or some other type of engineering.

Working in a software development team is weird. We often work together under an umbrella project or codebase, but everyone has their own individual project. I knew my coworkers were also working, but their development was tangential to mine. We would meet often to discuss the project I was working on, and I'd have to explain certain features that I assumed were self explanatory. Even though I was writing all of the code myself, I was writing it as if someone else would have to work on it as well later, because you never know if that could be the case. I also picked up on the stylistic habits of the company, as every software team has their own style standards when working on collaborative codebases. Being the least experienced member of a team is daunting usually, but I luckily didn't feel much pressure from my coworkers.

If a student wants to work in the technology industry or some form of engineering, a software engineering job would go a long way for their career development. Even if they are like me and don't enjoy specifically software engineering, the problem solving skills and general knowledge learned from programming will always lead to a more capable engineer. However, be careful with where you accept internships from. I had a good experience and like my boss, but many firms see interns as cheaper labor, and won't give you projects that develop your skills, which could give you an inaccurate view of what software engineers do.