Event Reporter Post Mortem

This week we turned in our first individual project, called Event Reporter. It built on other work we'd completed in class, including two smaller programs that we were walked through step-by-step. With Event Reporter, we didn't have an outline of steps to take, but we had very clear instructions on what the program needed to do, as well as the testing criteria.

As soon as the assignment was released, I was admittedly stumped on how to even approach it. I wasn't sure where to start, but I knew we would be using similar code to the other projects so my first step was to copy all of that into a new file, and delete methods I knew we were definitely not going to use. Then, I was overwhelmed with a mess of code as you can imagine, so I set that aside and hand wrote an outline of what the project needed to do at it's most basic level. That basically amounted to:

  • Prompt user for input
  • Accept user input
  • Output based on input

Oversimplified, but I think it was useful to have this concept nailed down. However, it still didn't help me unerstand how to approach the project.

I knew some others were trying to tackle this issue too so I made sure to work with them, thinking we could guide ourselves as a group. We only got so far, and had to ask a peer who was largely done with the base expectations to help us. This was instrumental in our group getting going, but once we were working individually agian I felt pretty lost pretty quickly.

At a certain point, I became very anxious about being able to complete the project, and felt like I wasn't understanding much of the code I was implementing. Once I realized I was feeling this way, and knowing it was not conducive to success, I took a break to think about what my goals were. We aren't being graded and I knew that above all else, Jeff and the Jumpstart Lab team want us to LEARN, not only meet deadlines. I defined my goal as completing what I could, even if that was only half the program, but to fully understand all the code I was writing. When new concepts like Structs were introduced, I tried to really visualize how they function, ask questions, research the concept, etc until I felt some amount of understanding with them. I think this was the best thing for me at the time, and removing the fear of failing to complete the program removed a LOT of stress for me.

Another strategy I used to better understand my code was to insert comments above each method or block explaining what the code did, and how it worked. If I had questions, I inserted them as well. I learned this after seeing a classmate do this, and I found it very valuable. After a long day of coding, when I felt no longer productive or abel to problem solve, this helped cement some concepts for me.

There are many things I will do differently in the next project I build. For starters, I will invest more time in an outline, and will write more simple methods to start and let them get increasingly complex as needed. I also want to try refactoring as I go, instead of putting that off until the project is complete. I thought it would be easier to avoid it until the end, but in reality my code became willfully confused and calamitous.

To the experienced, my code is nothing to be proud of. To me, it is a major accomplishment and I am very proud to have created “bad” code over no code at all. I look forward to looking back at this project in two months and being able to see how far I've come.

Here is my repo if you would like to see what a total novice being thrown into the deep end looks like. I welcome all constructive (and preferably polite) feedback: git://github.com/7maples/event_reporter.git