We had to create a simple web app that would let you time an activity of your choosing, and then log it. There were three main categories: exercise, meditate, and study that you could click on. The user could then add a more exact text description of their own choosing of the activity and input the number of minutes and seconds that they would like to do the activity for. After clicking on a button to start the activity, a countdown timer would appear. After the time was complete, the user could then log the activity on the "past activity list" on the left side of the page.
I generally like to do my best to be as flexible as possible in order to make the working experience as smooth as it can be. I think all people have habits or styles that they stick to and prefer when working on a team. I do as well, but I believe that if everyone can be more flexible to adapt to and work with the varying styles and work habits of other team members, then it can support an overall positive experience. I prefer to contribute to said collective positive experience, even if it means I may have to step outside of my comfort zone a bit in terms of my own preferred work habits and styles.
I took the same approach as last time with this project. I tried to work with the team to meet up when we all had time, even if that meant I had to push things around with my schedule. I think this helped contribute to a positive experience.
What went well? What was a struggle?
We had a lot of trouble merging our code. My partner's code would work with her part of the project, and my code would
obviously work with my part of the project. We also had different experience levels with how to write code, and it showed when
putting everything together. To be fair, that was to be expected. We did our best to be methodical when we went through the
code and worked out the bugs, which I think is probably the only strategy. We got everything worked out in the end.
When we didn't understand something or were presented with a technical challenge, we used a lot of different resources. We all asked either other people we knew who were either more knowledgeable like out mentors or other friends already in the field, or we approached other groups to get ideas on how to tackle the challenge we faced. We also googled a lot and did out own research when needed.
This really highlighted the importance of DTR, and of setting up coding standards so as to minimize bugs caused by variable or class naming conventions and the like.
I think that we did very well with keeping things professional and setting standards to make the group relationships easy to manage.
I realized the importance of keeping code DRY. I want to be better, but having clean and refactored code is helpful to make everything easier to go back and read, especially when you are debugging.
The planning stage should be more robust. We did some, but it would have made it much easier if we would have looked ahead a little more to future iterations to set some overall goals and plans for our functions to fit together.
Getting better at writing cleaner code, and planning a project out and pseudocoding in order to set up a clear idea of what I want my code to do.
Planning more. I think taking a full day to plan and pseudocode things will be good in the future.