 |
| Bottom panel reaccs only |
1. Trying to build a finished project on the first try
The project began with a week-long brainstorm of a design document to implement. This part went fairly smoothly, as we checked up with TAs and took advantage of office hours to improve upon our design in multiple iterations. I think our biggest downfall was then trying to implement all the features at once, in a coding language (Golang) that we've never tried before, and this led to a myriad of debugging issues that we just couldn't fix in time.
What would have worked better?: Building a basic product that passes all the sanity checks (testing frequently), and then adding features from there
2. Reading through the entire project documentation before starting
It's overwhelming realizing how many different moving parts you have to implement at once and is tempting to convince yourself that reading the project specifications and documentation is a productive use of your time. However, this just caused me to be afraid to take action and convinced myself that rewatching lectures to better understand the material was the first step before starting.
What would have worked better?: Code the freakin' project to the best of your knowledge, for now, taking it one section at a time. Fix it up later when you add more comprehensive tests.
3. Being forced to hold virtual meetings and attend virtual office hours
This one wasn't exactly our fault, as coronavirus has forced everyone to stay indoors, and virtual collaboration is much harder than actually meeting with project partners and TAs in person.
What would have worked better?: In hindsight, I admit our meetings could've been a lot more productive and we could've taken advantage of much more office hours (especially if we had started coding earlier).
4. Being too reliant on the help of others
I asked one friend in particular for help almost every day leading up to the deadline of the project, and even with his help, we did not manage to come up with a decent output. He helped a lot with figuring out exactly how to cast different variables into different types, but in the end, our project had too many flaws due to point #1 above.
What would have worked better?: Discuss not by talking aloud, but drawing diagrams and code it up. Only then should we ask about our approach and clear up misconceptions, not asking him what to do from the start.
5. Having P/NP to fall back on
UC Berkeley announced that every class would default to a Pass/No Pass grading option and that as long as you pass, it would count toward your major requirement. This definitely subconsciously took the pressure off completing the project, but also shut off my capacity to think critically and deeply about our project as a whole.
What would have worked better?: This shows that I am still in a "work for the grade" mindset rather than "work to learn and improve". Perhaps cybersecurity is just not a subject I'm particularly interested in, but I could use a paradigm shift in this mindset.
Final Thoughts
Overall I'm a bit disappointed in not being able to finish the project. I realize that I'm not bad at solving problems with code or even figuring out difficult projects with scaffolding, but when it comes to a project that I must design myself and then come up with the implementation I feel hopelessly lost. I still have a lot to learn and anticipate struggling many more times in the future, and regardless of virtual limitations the project was not undoable (many of my other friends did finish). Although I've resorted to P/NP-ing this class for the semester, this will not be an option to take in future semesters and in even more difficult courses.
Nothing I can do now but to end the semester strong.
Comments
Post a Comment