For this project, I worked on my own (with supoort from peers and mentors) to create a computer version of a popular cardgame. The game had to shuffle and deal cards, force players to alternate turns in specific ways depending on the rules of the game, and move cards to and from the player's hands and another pile (array) of cards. The game has fairly complex rules, and uses keydown events to determine when moves happen; many of the moves within the game are announced on a header that changes to reflect the action of the game. Player wins are counted and persist within local storage when the page is refreshed.
Throughout this inning, I have been taking more of a leadership role in projects, so I felt confident in my ability to accomplish this task. I was able to break the project down into smaller steps and had a pretty clear vision of what how to approach the challenges. When I reached a block, I had the ability to use dev tools, MDN docs, peers and mentors to work through to a solution. In some ways I feel like it is a victory that my code is not as elegant as it could be. I am feeling more confident in my own work and progress. My code will get better as my skills increase, but this is where I am now, and that is good enough.
One specific challenge was learning how to work in the data model, without using the dom. In the past, I have set up the DOM as I created the data model, and was able to use the dom to see what was happening with the data. For this project, it was suggested (strongly) that we work in the data model without the DOM, which was interesting, and helped me focus on and understand the logic differently. It forced me to work in dev tools more, and I found that when I went to connect the data model to the DOM, it seemed completely different. It made it easier to keep query selectors and event listeners local, since they were not created until after the functions that they were used for (in the past I have always created them first). Doing things in this order did cause me to completely restructure at least one method, so that the same keydown event listener could activate different methods depending on which key was pressed.
Something that I have realized on a personal level is that it is all right to struggle, and that I have the resources and skills to navigate challenges to a greater degree than I had believed. It is also true that sometimes I need help, and that letting other people see that I am struggling is not disgraceful.
On a technical level, the big thing is that I can create something as complex as a game! I definitely saw how valuable tests are in coding, especially if you are not in the DOM, and will be learning how to write my own tests over the intermission, so that I have that in my bag of tricks before Mod 2.
I would like to understand more about the architecture of an app. I want a better grasp on when to create a separate class, where the most appropriate place for certain methods/functions is within the files and that sort of thing.
This was a small group project in Mod 1, three of us were assigned to collaborate (remotely) on a project to create an app that would allow people to create and store memos about certain activities that they participated in (meditation, study or exercise) and have a countdown timer for the activity.
There was a disagreement early in the project, when we agreed that during a break, one team member would research an issue that we were having and report options back to the team. During the break, she made substantial changes to the code without consulting the other members, and then another team member appropved an merged the changes before I was even aware the changes had been proposed. The changes were not consistent with the Turing style guide, and some of them, I would definitely not have agreed with. We had a discussion about it, referring to the DTR, and agreed that we would not make merges without input from all team members, and that we would be certain we were following the style guide. This was managed with honest and respectful communication, and actually served to improve the relationships within the team.
Getting the countdown timer to work was definitely challenging. We tried a few different methods that had significant problems (such as a 1 second delay when the timer started) but eventually we found a method that worked, but only accepted seconds as input, so we had to convert the input in minutes and seconds to seconds for the functiona and then back to minutes and seconds for the display.
One professional takeaway is how important it is to refactor early and often. Refactoring can create it's own problems and also change the way a problem is approached, which can inform how other problems need to be resolved. Waiting to refactor makes refactoring harder, and if there is a time crunch or if people are fatigued, it is likely to be overlooked.
A personal takeaway is simply the reminder that conflicts can be resolved in ways that strengthen a relationship, if people are careful in how it is handled, and everyone is committed to improving.
Something that I will take forward is preplanning is important, and will need far more time in a group, since people have their own methods that they are comfortable with and it can be difficult to get everyone on the same page. This also seems like a good way to start building relationships within the team, which is important, but can make things slower
For theis project, I was paired with a fellow student to complete a project in which we were provided the HTML and CSS files. The goal of the project was to create functionality so that a user can go to the site and create an image of a romance novel cover, which can draw from a collection of images, titles, and descriptions to create a random cover or switch to another page to input custom choices. The user can also save covers that they select and switch to another page to view the collection.
During the course of this project, we were maintaining social distancing and all of the work was accomplished via remote work and GitHub. We typically worked at the same time using Slack, with one of the partners doing the typing/Git pushes. Although we were working together, we practiced using the git review process to get used to that process.
Up to this point, I have usually been less avtive on the team, providing thoughts and insight, but not taking a forward role within the team. During this project, I was able to move into more of a leadership role, as my understanding and confidence have grown. My partner's views and level of understanding were sometimes different than my own and that certainly shaped the way that the code was written, but I feel that I was much more actively involved during this project than I have been in the past.
There were certain points in the project when we were not able to get the code to function on our own using console logs and dev tools, we looked to MDN docs or other reliable online resources, looked through notes on past lessons or projects, or turned to peers or Mentors for assistance. When a Mentor provided significant assistance, we deleted that code and then worked to replicate it on our own. On one occassion, I found that a function was not working properly because I had a completely wrong impression of how the function worked, basically believing that certain aspects of the function were inherent properties, when they actually needed to be written in.
One thing that I have definitely taken from this project is that I do not have to be able to write clean code to get something working. It's better to write anything at all than to wait until I can 'do it right'. I would like to be able to write elegant code, and I will get there, but I am learning to trust the process.
During the first month of my time at the Turing School of Software and Design, one of my fellow students and I were assigned a project designing a website that allows users to create randomly generated or custom designed motivational posters. The HTML and CSS for this project was provided and this was our first experience using the DOM. It was also our first experience working with another person on a project, which was made more interesting by the necessity of working completely remotely during the Covid19 crisis.
My approach to working on a team is to work together to create guidelines for workflow and communication, and assign roles if needed and then refer back to that agreement so that we are working within those parameters. I think it is also importaant to remember that things rarely run to plan, people handle stress differently and most people have good intentions. On this project we started with the DTR that was provided for us, and we also checked in with each other early each day to schedule worktimes and any other commitments that we had. Frequent an open communication between team members is critical to a successful team.
This was challenging project, and we frequently ran into problems that we were not able to solve on our own. MDN Docs was our first resource in those instances, followed by google searches. In many instances, we went to Mentors, other students or Turing alumni for assistance. There were times that we found or were offered solutions that got the project to run, but we did not understand how it worked and so we chose less elegant solutions that we better understood.
One takeaway from this project, which seems to be both professional and technical is that I need to integrate formal pseudocoding into my workflow, and strongly request it when working with/learning from others. The mentors we turned to, and my partner were all faster and stronger coders than I currently am. Even though I was frequently the one seeing what the code needed to do, without pseudocoding the steps, I frequently found myself a bit lost while others were writing code and needing to go back later and ensure that I understood. Clear pseudocoding would have helped me to understand and probably to be able to contribute more.
The final project for Mod 1 was very different from the other projects, both because it was a solo project, and also because we were tasked with building from the ground up with no clear guidelines on how to reach the end product. In previous projects, I was able to rely on other people's strengths to make up for areas that I was not solid on. Everyone contributed and the project was completed, which to some degree camouflaged areas where each individual was not as strong. Although I did not need to consider the scheduling needs or personal workflow of other developers, not having other perspectives and talents made the work more challenging in other ways.
As always, MDN Docs and CSS tricks were very helpful during this project. Part of the assignment was to not look at tutorials or get help with actually writing code from other developers, and it was interesting to see that several times a google search for a specific problem related to the game would result in an offer of a tutorial on creating a Tic Tac Toe game, even though I was careful not to mention Tic Tac Toe in the search parameters. It underscored how often the problems that I am encountering have been faced by other developers, and that the answers are out there. I also talked with mentors and peers about the logic of the game play, discussed various options on how to determine a winner and updating the data model.
One thing that I have definitely learned through this project is that we do not work alone. Even on a "solo project", we have to rely on others; we talk things through with peers or mentors, we seek answers online, either through articles or forums, and although we do the work independently, we are still part of the overall community. It has made me think about my place in that community. Even when I am seeking support, asking clear questions and reflecting back the answers will help others who are struggling with the same concepts; we are all in a position to help others, either with our work and knowledge or maybe just by offering to be a "rubber duck". Even for an introvert, even working remotely, remaining connected is relatively easy and extremely important.
I already knew before I started this project that coding is a creative process, as much or even more than it is a science, but now I know that this is true. Up until now, my approach to learning has treated coding as a science. If I got stuck, I went back to the books, or watched others solve the problem and then went through and made certain that I understood the code. The fact is, that is simply not enough. Understanding the code is great, but writing code is the actual job. I got part way into the project and realized that my approach has not served me well enough to get me to the standard that I need for success. To use an analogy, it's like studying art theory and thinking that will help you draw a picture. I have realized that I have to move out of my comfort zone and just write code.That was a difficult realization, but I can see what I need to do going forward, which is a kind of success, in it's own way.