The skills learned in the study of software engineering can be applied to other fields and disciplines, as well. Think of it as a sort of cross-training, where you gain skills and knowledge that blend into a beautiful synergy in your body and mind, and you’re a well-rounded force to be reckoned with as a result!
As a start, we can look at Open Source Software Development and Agile Project Management as examples.
In our Open Source Software Development module, we learned about the ever-changing lives of public information. In other words, we learned how to use online resources. We learned how to search for keywords and advice in both official sources (ex. official company website and manuals) and unofficial sources (ex. third-party user forums).
Very importantly, we learned how to ask smart questions. This involves being specific, concise, and clear about what you’re trying to do and what you’ve already attempted. People are busy, so it’s a delicate balance of being snappy, interesting, and informative all at once in order to catch their eye as they’re skimming over a page. Also, while possibly not super vital to the effort of accurately communicating your issue, being polite and displaying an effort to learn and figure things out on your own are immensely encouraging for a potential helper and might color your writing more positively in their eyes.
From flyers to emails to reports, communication through writing is a widely applicable skill. Furthermore, being able to write in a way that appeals to your target audience and convinces or successfully encourages them to do what you’re asking of them, while also leaving them with a positive impression of you, will likely be very beneficial to you wherever you go. Think of the possibilities!
In our Agile Project Management module, we learned about breaking a huge project into smaller, more manageable chunks. An important tool that we used was a Project Board. Specifically, we used GitHub’s Project Board feature, but I’d say it’s absolutely possible to make a physical version or other virtual version, too.
Basically, the Project Board had three columns to organize the project issues or tasks: (left) tasks to complete, (middle) tasks in-progress, and (right) tasks that have been completed. Each task had a number (unique, for identification), name, description (optional), and one or more people who were assigned to it (optional). The idea is that each task can be completed in around 1-2 days; otherwise, it’s best to break a longer task into smaller ones, if possible. Tasks that can be completed in a shorter amount of time don’t need to be listed on the project board.
We would move the tasks between columns as applicable. For our Final Project, we also had a Project Board for each of our three Milestones, and we moved tasks from the recently closed Project Board to the next one if we needed more time to work on them.
Also, speaking for GitHub specifically, whenever we started working on an issue, we created a new branch off of the master branch for it, and named that new branch with the number of the issue in question (ex. “issue-10”, for issue 10).
This type of labeled, chronologically organized, yet simple visual layout was immensely helpful when discussing the project’s progress and areas to improve. The entire group could look at the project board together and see specific names of tasks and the people assigned to them as well as what stage of progress they’re currently at. For a larger or more complicated project, and when multiple people are involved, especially, it can be easy to forget what’s been mentioned and who’s responsible for what task, so it’s helpful to have a record available to everyone.
The listing of tasks acted as a to-do list to check off discussion points for group meetings and aided in showing everyone roughly how much work each person was assigned and how much work the group was aiming to complete overall. Furthermore, at any point during the project, anyone can look and see what specific tasks have yet to be completed, and can offer their help to the people assigned to the tasks, and/or can avoid assigning new tasks to those people.
Any sort of multi-step effort and/or group effort could benefit from using a project board. From working at my current internship in a government engineering office, where multiple projects are happening and need to be explained to people whose expertise is not in that specific field, a clear and simple visual layout works wonders in communicating information to people and getting responses from them and helping them follow along. Having a visual that everyone can refer back to, works wonders down the line.
Project boards like the ones we used (on GitHub) also look really smart and professional, I must say. That was something I found myself being proud of us for right from the beginning, and it helped put me into a professional, focused, and optimistic mindset. All good things.