My biggest success during this course has been learning a new tech stack and realizing that this semester was similar to my internship this summer, where we were constantly learning new technologies to better serve the needs of our customers and lay the foundation for a software solution.
I learned that setting up a project is not as simple as making tasks and assigning them. I have gained respect for product managers and Scrum Masters because creating tasks with my team made me realize there is so much thought that needs to be in place while also considering the long-term goals of a project. One thing I learned about myself is that I work better with structure, as long as the structure is something I can challenge if I think of a better way.
In terms of my SWOT analysis. These are my thoughts:
Strengths:
This course is somewhat realistic to what I encountered during my internship this summer. Being thrown into a project, having no idea how to build it, and brainstorming with what we do know to bring us steps closer to completing the project. This was a great reminder that as software engineers, we will always be learning new things and solving new problems that might not have readily available solutions, hence why we are building them from scratch.
Weakness:
The strength of this course is also a weakness in some ways because we had way too much control over what we were building. All roles that would be on a team, for example: Scrum Master, Product Manager, Senior Engineer, Junior Engineer, Intern, Program Manager, were essentially done by everyone on the team all at once. I came into this class a little misled from what I was reading in the emails and assignment instructions about picking a project. My thoughts were that we would have a T.A. or professor giving us tasks or features they’d want to see, as if it was a live product being deployed. Most of the feedback was just about decisions we made and just stuck to because it brought us closer to meeting “requirements.”
Opportunities:
I think this class should follow a structure similar to an internship where students will experience both comfort and discomfort. Perhaps, for the initial weeks, have some assigned tasks to complete just to get things set up. These tasks can be optional and open to change to help those who honestly do not know where to begin. While, yes, we need to figure things out on our own as we do in the industry, in my experience, asking someone with experience after struggling a bit is different than just relying on everyone who is also learning.
One suggestion I have is maybe having the option of doing one large project or two smaller ones. I personally think if an option is picked from what was given, there should be more than just requirements that need to be met.
Threats:
I think it’s unrealistic to measure how many hours each individual team member put into their assigned tasks for a week. Something that may seem trivial to a TA or professor might have genuinely taken a student much more time than the person reviewing it. I think another thing to consider is when a student drops the course from a team or if the experience level gap is too large in a team. It’s easy for a student to feel like they are not contributing, and for another to feel like they are doing everything. Once again, these are difficult metrics to account for.