Dealing with the Dynamics

Yesterday, we wrapped up our last class of Codesmith's CS Prep course, a two week course designed to prepare the student specifically for Codesmith's immersive bootcamp. Overall, this was a really good experience, and I learned a lot. We do have one more session tomorrow, but it's not an official class; we are just presenting our group projects. In the second half of the class yesterday, we were assigned groups of 4 to come up with a project idea and implement it by Monday, so we were given about 48 hours. Out of the 4 of us in the group, 2 of us are a bit more advanced in coding than the other 2, which is fine. There's no reason everyone couldn't still participate in the project, especially given the pretty basic project we ended up landing on. One person had the idea of creating a quiz game of sorts, while another wanted to create a musical keyboard using the web audio API built into the browser. I had the idea of creating a game where you had different attacks you could do on a monster, and the monster could attack you back from a random array of attacks. We ended up going with the quiz game coupled with creating sounds somehow associated with different actions in the game, like whether you answer the question wrong or right, or you lose or win. I was fine with this, so we got to work.

I quickly realized that one of the people in our group was going to try and dominate the entire project. I didn't want to fight them, so I tried to compromise wherever I could. For example, I really wanted to implement this in the DOM with HTML and CSS, to make it at least somewhat visually appealing. It would have been fairly simple to have the questions show up in the browser, with the possible answers being represented as buttons. When you click on one of the buttons, an overlay would pop, telling you whether or not you made the correct choice, and it would move on to the next question. This would involve a little bit of DOM manipulation, but nothing too crazy. This other person in the group thought it would be much better to just write it in the console, which would have virtually no visual appeal, at all. I think the reason for this is because they don't have any experience writing websites, so they didn't think they would be able to have control over this process, not knowing this is something I've done plenty of times. I decided to allow them to go down the road they chose, and we ended up doing it in the console. We implemented some prompt popups that would then print to the console. It looks terrible, but the functionality works.

I committed to this decision, but I thought about it last night and this morning, and realized it would be better to write the console logs in alerts, since we already have the popup from the prompt. It seemed silly to me to have to go between the prompt popup down to the console, and just overall a really bad user experience, on top of what is already a terrible user experience. When I suggested this and implemented some changes to a separate file, as to not change the original file, I received some push back from this same person. They weren't able to get their web audio API to work with the alerts, so they wanted to go with the console logs and were unwilling to budge. This kind of pushed me past the point of being polite about it, and I suggested the fact that the site has a poor user experience when having to go back and forth between the console and the prompt. I'm just about to start a group meeting with them, and the challenge for me is going to be expressing my opinion without upsetting this person. This project is more about learning to work in a team environment than it is about writing code, in my opinion, and I'm trying to learn as much about that as I can.

Until tomorrow!