Software engineering is so much more than coding for web development, but the most difficult aspect is getting others to believe it. My day job requires me to be an Avionics Engineer for small satellites and most of my colleagues are Electrical or Computer Engineers. Every day, I am reminded how Software Engineering is not a real Engineering field and asked why I chose to major in Information Computer Science instead of Computer Engineering. As someone who has spent fifteen years of my life in a career I did not enjoy, the answer is simple – I like programming and creating something from nothing. Programming has been one of my hobbies since I was thirteen years old and I still enjoy programming at thirty-four years old. As I transition from being a hobbyist to be a professional, I am learning that a lot of my prior experience as a Nuclear Engineer and Avionics Engineer is applicable to my Software Engineering projects; indeed, my projects require coding standards, design patterns, and agile project management.
In my ICS 314 class I was required to learn coding standards. Coding standards are an accepted norm that all collaborators agree to follow to ensure source code is readable, efficient, and reusable. Generally, a company – such as AirBnB – documents exactly how source code should be formatted, how to use classes and constructors appropriately, how source code should be documented, and common naming conventions. Outlining and enforcing how source code should be formatted and documented is critical for someone else to understand your source code without having to spend hours trying to figure out what is going on. In the Navy, we used Submarine Interior Communication standards to ensure everyone talked the same exact way, referred to equipment names the same exact way, and were all expected to enforce these communications on each other. Using these communication standards ensured that each Sailor communicated correctly in times that were high stress or life threatening. Being able to read someone else’s source code and being able to quickly understand that source code is instrumental to a business operating efficiently and effectively to achieve goals and deadlines.
Designing and building a satellite requires knowledge of system standards and required modules. An experienced Avionics Engineer can look at a system diagram and easily determine inefficient and immature solutions for use in space because best practices have been determined and documented to solve reoccurring engineering problems. Software Engineers use the same mechanism and call them design patterns. Design patterns allows for extensible, maintainable, and flexible source code by assisting developers with recommended techniques to solve future problems as projects grow in size. Using design patterns allows for projects to scale without having to reinvent the wheel or restructure when memory and resources would otherwise become scarce. Using design patterns requires a big picture architectural view of the overall project with an in-depth understanding of what happens on a fundamental level.
This semester, I was introduced to Issue Driven Project Management (IDPM) which was incredibly similar to the preventative maintenance programs in place onboard submarines. Each work center consists of around a dozen Sailors, work is divided amongst them based on experience and availability, and each preventative maintenance task must be well documented and discussed amongst the workers and project managers. For my final project, Manoalist, my team utilized IDPM techniques by meeting at least twice a week formally (while talking everyday informally over slack), divided issues into small and achievable tasks, created separate GitHub branches for each issue, ensured that each team member was consistently working on at least one issue at a time, and utilized an Automated Kanban board to allow every team member to see what issues are outstanding and who may need help completing their tasks. Overall, our milestones were due about ten days apart which was perfect for our team. This was my first time leading a project where I was not able to speak face-to-face with every team member and I found the process incredibly challenging despite having an amazing team that was mostly self-motivated and extremely competent.
Overall, I gained an incredible amount of experience with regard to Software Engineering, leading a team while working remotely, becoming familiar with design patterns for software, and gaining appreciation for coding standards. I will take this newly refined and developed skill set with me as I deepen my comprehension of software engineering as I complete my education and incorporate these techniques in my daily routine as an Engineer. The most important thing I learned throughout this process is that Engineers are Engineers regardless of the form and utilize similar principles to solve problems.
