Week 3
This week we learned about git and worked in our teams to create cards for Thanksgiving. I use git and GitHub regularly at work, so that hasn't been challenging for me to pick up. The most difficult thing about this week is working in the group with little direction on how to work together as a group. Also, the assignment doesn't feel geared toward collaborative pairing. We were supposed to create a card for each member of our group, leading us more or less down the path of creating our own cards. If we were all forced to create one, together I think it would have been a different story. It's also nearly impossible for all four of us to be at the computer at the same time. We also have a midterm coming up, but it seems like we will still be applying the same kinds of methods we've done up until this point, so it should be pretty straightforward.
Assigned Readings
The Wikipedia page for pair programming currently describes pair programming as having two people working on one computer. the two people switch off being the "driver" and "navigator". The driver writes the code and the navigator comes up with various ways to do operations and acts as the extra set of eyes for bugs. It also details some of the benefits and studies done on pair programming. I have pair programmed quite a bit in the past and love the idea of it. Unfortunately, this course hasn't yet defined any way to go about setting up meeting times and student environments (tools) to facilitate remote pair programming. Instead, we're being directed toward a collaborative git workflow. It's extremely frustrating (from what I'm seeing) for the students because the reading we're directed to provides guidance on pair programming in a situation where the students are in the same room.
This article briefly describes that it's possible for computers to recognize and distinguish human faces. A startup company, called Uniqul, released an ad full of hypothetical situations where they showed consumers that could pay with their face. So, there was no real transaction and just a button that the user clicks that says to accept the charge. The company is hoping to develop the facial recognition technology to do this. I'm not really sure how this relates to this course, but I guess it is showing us what we could potentially do down the line.
Sension is another facial recognition product. This product uses faces to track and test the level of engagement an end user is experiencing and to provide a new way to play video games. This product ended up having an unintended application, which is to recognize different emotions that people are conveying at the end of the camera (found useful when dealing with autism). I'm also not sure how this relates to what we've been studying, but we will see.
Google had nontraditional hiring practices. As a programmer, many people will go further if they can learn quickly and face challenges well. I know this is the accurate because I don't have a degree and work as a programmer. There aren't too many people that are in the field without degrees, but I can attest that the ones that are work very hard. In relation to this course, I believe this article was better suited for the ProSeminar course and doesn't really apply to a multimedia design course.
This is another article that seems to be a better fit for the ProSeminar course, but it basically explains how Google grades themselves on their own tasks. Prior to a particular set of time, they establish several (less than six) quantifiable goals. They are graded on a scale of 0 to 1, where 0.6 - 0.7 is the ideal result. A full 1 would mean the goal was too each and closer to 0 would mean that the goal was too difficult. Perhaps this was a subtle suggestion that we should try out Google's Objectives and Key Results (OKR) strategy for ourselves.
No comments:
Post a Comment