Software Engineer For A Defense Contractor
Job Title: Software Engineer
Type of Company: I work as a software architect for a defense contractor.
Education: BA, Computer Science
Previous Experience: None, really. I've been working at the same company ever since graduating from college.
I develop and guide the software architecture used for large-scale government defense projects. This includes developing threading models, communication models, design and development guidelines, and general infrastructure guidelines. I also help developers with design, coding, and debugging problems. I spend about 20% of my time writing documents and presentations to guide and instruct developers, 50% of my time resolving integration and system issues (e.g. bugs), and 30% of my time working with developers.
A typical day involves answering questions for developers, helping developers and integrators understand the intended architecture of the system, helping developers and integrators resolve defects in the system, discussing future development plans with the management team, and generally helping to resolve any day-to-day development crises. (This is largely because the architecture on my current project has stabilized over the past two years. Previously, I spent much more time designing software components and less time helping out with issues).
This also involves a good deal of process creation and refinement, where "process" refers to the procedures and rules used to control and measure the quality of our software rather than "process" in the computer science sense. This takes much more time that I would have expected, but that's largely a function of working as a government contractor.
Best and Worst Parts of the Job: The best part of my job is seeing a long-term project develop over the years into a final deployed system. The day-to-day nature of my job changes as the system progresses.
The worst part? Working for a defense contractor means following numerous government processes, which can be a bit jarring at first (since there's a high ratio of paperwork to technical fun).
1. It's important to understand how programming languages work "under the hood" rather than just understanding their syntax.
2. Take courses in computer and OS architecture -- e.g. understand the mechanics of threading, communication protocols and disk systems.
3. Learn to effectively debug problems. Any sort of software will always contain defects, and I think the measure of a good software engineer is his or her ability to assess and resolve the cause of a defect. Programming knowledge is of secondary importance.