This project was called Intention Timer - an application where a user can pick a specific category on which they'd like to focus on (study, meditate, or exercise), specify what they will be working on with a short description, and also specify the length of time they will be doing the task. This application implements the use of a countdown timer entirely built from Javascript. Once the time is up, the user has the option to log the activity, and have it appear on the right hand side of the screen for later viewing. This implemented the creation of a Javascript class for Activities, which created a new instance of the activities class every time a user pressed "log activity."
Since I have repeated mod1, my understanding of working on a team has been refined. I think I see many more benefits to working on a team rather than independently. During this project, my partner and I agreed that for the very most part, we'd work entirely together - two heads on one computer. This way, when solving problems, we'd be able to fill in the gaps of knowledge between the two of us and build a strong code base that both of us understand. I understand that some people prefer to work independently, but as often as I can in the future, I will try to employ as much collaboration into projects with my partners as I can. I learned more from this project than I have from anything else here at Turing and it is because my partner and I put our brains together.
Throughout the project, there were two primary technical challenges for us. The first was the creation of the countdown timer. We spent a very long time researching how to do a countdown timer, and most of the resources we found were all doing it in very similar, but complex ways. It took us hours to tease apart the pieces of code that would build a timer, but we finally implemented it on our own. The function itself is very long, and could definitely use some refactoring, but at the very least the timer is functional. The second challenge for us was the optional addition of a class that would then create instances or objects from that class. I knew this would be extremely difficult, but I also knew it would be a great learning opportunity for us to understand how objects and classes operate in real code. Similarly to the timer, it took a long time for us to wrap our heads around how to build a functional class, but we eventually got it working.
One personal takeaway that this project has shown me is that I can actually learn how to write Javascript. A month ago, I had absolutely no idea how to write a function, and felt like I was drowning in information with no understanding at all. Today, I feel unbelievably proud of myself for having written an application like Intention Timer, an application fundamentally run on Javascript. The most notable technical takeaway for me is a firmer understanding of objects and classes, and how to later use them for different projects. Based on these takeaways, in my next project, I want to focus on local storage, which to me seems like the next step after creating a class.
Since the last project, my view of working on a team has changed a little bit. In the last project, I came out really valuing paired programming and almost being a bit fearful of breaking apart to code alone. This time around, I think I have a bit more of an appreciation for the possibility of individual space while writing code. For example, there were a few times when we were all coding together that it felt like there were simply too many ideas floating around that weren't directing us in any particular direction. In these times, I found that it may be beneficial to get ideas out on the table, but then take some time to brainstorm / psuedocode on your own to see what you can come up with. I think another good approach would be to work together during the day, but when each member goes home at night, everyone can then all work on the same thing, separately, to see what everyone comes up with and see what may be best to use in the codebase.
One major technical challenge we faced was the build-up of one specific function in our code that became way too complicated. At one point, our project manager asked us what the function was doing, and all three of us said different things (and none of us were wrong, because the function was doing all those things and more!). We continued to run into bugs and other logical issues because of this one function and the problems only continued to get larger, so on the day the project was due we decided that we either needed to continue working with that function as-is, or refactor it. This was when I took some personal time to individually think about the function, and after about 30 minutes I was able to simplify bring down the function to about 8 lines of code. At this point the codebase as a whole was more evenly distributed and made more sense.
One professional takeaway from this project would be the benefit of working individually, as I have said above. A technical takeaway would be to take planning for future sprints / iterations more seriously, and write out in plain English what each piece of functionality should be doing and how it should be doing it. Drawing pictures / diagrams of how the functionality should flow would also be very beneficial. For the next project, I want to focus on SRP, ensuring that each piece of functionality is doing exactly what it says it is, concisely.
Our solo project was called Check Yo' Self. This was an application where a user is able to log various to-dos, each with a number of various tasks beneath them. For example: a user could log a to-do, "Clean the house", and within that to-do, log some specific tasks, like "mop the floors", "empty the dishwasher", or "dust the window sills." Once the user is done filling out that to-do, they click a button to log it on the right as a card, where it will be displayed with other past or future to-dos. A user is also able to mark certain cards "urgent", check off tasks, search through all to-do's based on title, and filter to only see their urgent to-dos. The user is also able to navigate away from the page, refresh the page, or close the tab entirely and return to it and still have their to-dos on the page.
In some ways, this project felt easy, and in other ways, it felt pretty difficult. There was essentially no new material from the last project to this project, but having to do it alone made it a bit more challenging. One major challenge for me throughout the project was concerned around time - in a few different ways I think I dug myself into a rut with poorly written code, and had a hard time deciding whether or not I had time to go back and refactor, or if I should just keep on moving and find a solution. Another technical challenge I faced was figuring out how and when to reinstantiate an object once its been pulled out of Local Storage.
One personal takeaway for me in this project looks back at myself last time around when I only turned in the HTML and some of the CSS for this very project. Although I don't feel absolutely amazing about the code I've written for this project, I feel as if I've come very far from where I was last mod, and successfully built a functional application that I can be proud of. A technical takeaway would be to take some time to quickly refactor each day, if not multiple times a day, rather than waiting to refactor giant pieces of functionality. In my next project, I want to focus on refactoring, and catching myself if the code I am about to write feels off, hacky, or strange in any way.