C# Part 2: Projected Fails As a List

A self-evaluation of C# Part 2 at NWTC Fall 2024 semester. I had dreaded this course and OOP Programming in general as an expertise or specialty (which I want to commit to, by the way) due to the learning phase of it. Learning phases of something you want are confusing - you don't dread it; you are in a foundational mentality that lively hosts for how much you lack in comparison.

C# Part 2: Projected Fails

• Teamwork tasks incomplete, incomprehensible, undirected
• Resource gathering speed was not fast enough
• Internal built-in feature list is null
• Prioritizing schedule and time management

Pros : Projected Fails (Yes.. like a class. We are defining the positive outcomes with the projected fails list to offset and include how I somehow made up for it!)

• I was able to follow a template of instructional documentation (which I also suffer with writing, instructionally, since my first class back into college from my Social Science degree in 2013. I just got done with an IT Documentation course and was following this structure. However, the details entailed within the actual programming of a game, was nothing like an agile framework. Agile framework is the coordination of team environments to collaborate effectively for that time management. The actual task you commit to is entirely different structuring in the program - paying attention to this part was being more involved. I understood what was happening up to a point and once you lose track of the even further details in those processes of planning the program, the more difficult it is to maintain your developer role. 
• Spend the extra time researching C# tools, built-in features, and other relevant articles outside of documentation to reveal new coding hacks, tricks, tips. It's worth taking a dabble in. I would often get distracted, interested, and that information was useless because I wasn't using it. Take the time to find where that will be useful and place it there for you to review and use at that time. 
• Developing the perfect questions. Before you can do this, you are resolving with solutions to put a tangible essence with the code for the program to operate as it should. This part, I shadowed my teammates as they talked through their processes. It helped me envision how they were solving a bug, logic, or invoke method crises. Don't be afraid to let the group know you are falling behind in making sense of what to do next. Don't worry too much about how to get your code to work from theirs, at this point. Do the code. Share. Then everyone can figure out how to instill your code into the project together. 

Team project #1 with 4 members was tough with GitHub as a first-time user of it. My files would be unfound, too many changes without maintaining a push/pull commit flow for only making minor changes or reading code or outlining something minimal as an undone forced commit. I did ruin the project towards the end but was able to fix it though! 

It was rough, I don't know how they did it. But it was a good learning experience for me. I truly enjoy learning in this program and want to continue to improve. Making notes of this now will help me recollect my future progress to recall how to help the next person in their beginning steps. 

Yaw^!

__Mischief