Overall Experience

          Forty-one class days, nineteen papers, three exams, six projects, one presentation, and numerous example programs later, the class is finally over. Overall, I learned a lot of different things in this class, more of them useful than not. If I could make a few suggestions in the course I would suggest having more homework rather than simply just projects. The projects are very useful learning experiences, but I think there was a disjoint between the assigned readings, the quizzes, the projects, the lectures, and the tests. I think that homework structured more like the exams would bridge this gap. I know that I personally learn through practice, but I didn't find adequate practice for the exams in the course material. Even though the exams were mostly programming, the only programming practice we got was in the projects and the projects were far different from the exams.
          I wish we would have talked about the assigned readings more in class. It was not clear why we read some of the papers, such as the paper on Gender Differences, since we never discussed the implications of the paper in class. I found the paper very interesting, but was not sure what gender differences had to do with software engineering. It seemed as though most of the papers were only covered in one question on a quiz and were not covered any further. I would have liked it if there was more of a connection between all the parts of the course - the projects, readings, lectures, and exams - but I do think that each aspect was interesting and useful in its own right. I would have liked if there was more of a global picture of what software engineering embodies.
          I definitely learned a lot of programming techniques that I'm sure I will find very useful in the future. For instance, I found Assembla to be extremely helpful and have used it in my other two programming courses this semester. The programming assignments in these courses also involved pair programming, and git made it very easy to share code between my partner and I and to backtrack when we found bugs. I also think that the issue tracker will be a handy tool in the future.
          Overall, I enjoyed how practical this course is. At the beginning of this semester, I wondered whether this course would prove to be as valuable as I thought it could be and this has since been confirmed. I like how this course is focused on situations you would see in the real world - pair programming, issue tracking, refactoring, version control. Even the projects are tasks you may see in real life, such as programming a website. I surely need all of these things since I graduated just yesterday and will soon be heading off into the real world.

Final Week

          The final week of class is finally here (and the final week of my college career nonetheless)! Class was laid back last week since I watched two other groups present on Monday. I think in general everyone did a very good job on the final project and on the presentations. It became apparent that some groups were at a great disadvantage because several of their members dropped out of the course after the second midterm, which was very unfortunate.
          My group is presenting tomorrow, after which all is left is the final midterm. I'm extremely anxious about this next exam since the last one sent my head spinning. I've been trying to predict what kind of questions, both reading and programming, that could appear on the exam, but I'm at a loss, however, since the structure of the lectures seem to have changed from previous iterations of the course. Previously the course seemed to be focused more on different ways to write methods, but now the examples are more program/class centric.
          Overall, I probably learned more in this class than almost any other CS course I've taken. If I had to make a few suggestions, I wish that the tests would cover more topics. I found that the class covered a wide range of topics and programming techniques, but each of the first two midterms were highly focused on one or two ideas. I don't think the tests do the class justice to ignore many of the topics discussed. Also, I wish the tests had actually made us program Java rather than Haskell, since half of the class was taught in Java but we were never tested over it. I know that we have been tested over Java in previous classes, but there were many Java techniques I had never learned before this class. I think it would be okay to test a little bit over Haskell, but not half the exam since it was not a main focus of the course or the lectures. This seems to have been one of the main complaints from many students in the course.

Extra Credit Blog

                Efforts have been made by many organizations and universities to find out the cause of the underrepresentation of women in computer science and to turn this trend around, but one of the only groups to indicate improvements is Carnegie Mellon University. The paper “Women in Computer Science: The Carnegie Mellon Experience” explains how the university successfully raised the representation of women in computer science from a meager 7% to 40% in five years.

                The university discovered that many of the same reasons accounted for lack of women as those given in “Gender Differences in Computer Science Students”, specifically the experience gap, lack of confidence, and peer culture. Two other reasons that CMU cited was curriculum and teaching faculty. Interestingly, the paper argues that the department’s curriculum tends to favor males over females, since males are more likely to come out of high school with previous programming experience and the first few years of study are heavily programming based. Many of the early courses assume that students “already know the requisite programming language or that they can pick it up on their own.” Just as the other paper argued, this one states that “females with grades equal to or better than those of their male peers have less confidence.”

                It is evident that women become discouraged from joining the field early in their education due to the lower percentage of women that take the CS AP exam in high school, so the university decided to target high school females. In a joint program between university employees and CS Advanced Placement teachers, dubbed 6APT, the university hoped to combat the cause of female underrepresentation at its source. This program educates teachers and students about the gender gap in computer science.

                Another effort was made by CMU admissions officers to send the message that no prior programming experience is necessary to be admitted into the program. Many studies explain that men are more likely to begin programming and studying computers at a much earlier age than women, which causes many women to become discouraged during their first year. Unfortunately, many women even come to the belief that they are admitted into the program solely because of their gender.

                Finally, the Department of Computer Science at CMU created the SCS Advisory Council which organizes events to encourage young women to join computer science, similar to WICS at UT. Some activities include a Big Sister/Little Sister program and student/faculty dinners, both of which have also been executed by WICS. The paper points out that even though efforts have been made by numerous organizations to attract women to computer science, their department is one of the only ones to find success. WICS holds many of the same events as the SCS Advisory Council, but I think the one place they fall short is in targeting younger girls. WICS has tried to hold events at high schools in the past, but I think CMU has proven that a much more dedicated, consistent effort is necessary. One or two events is simply not enough to convince young girls of the benefits of joining computer science.

Women in Computer Science

          This week we had to read about gender differences in computer science students, which I found to be one of the more interesting papers mostly because it pertains to me. I have never read an actual study on the matter, but I found many of the points in the paper to match my own feelings. It sounds absurd on paper that a female computer science major would feel less confident with computers than male non-majors, but I can understand how a woman would feel as such. I often feel that many males in computer science have more general computer knowledge than me and more experience. For instance, I think that more men have built their own computer - something that sounds basic for a computer science student, but something I have never done. In general, it can be quite intimidating when you are one of the only female students in your class, and I understand why some women would feel discouraged from joining computer science. The thing that probably helped me was the fact that my father was a computer programmer and my brother majored in computer engineering in college, so I had been exposed to programming while growing up. I hope that in the future more women will take a chance and decide to join the field.

Refactoring

          The past couple weeks have focused in large part on the techniques of refactoring. I have found the readings over the past couple of weeks somewhat redundant and very long. Many of the techniques in the reading seem like common sense, such as changing the name of a method or the number of parameters. Many of the refactorings seem quite subjective like deciding whether to inline or extract a method. Thus, I think refactoring is not necessarily something that can be taught, but rather something that can only be learned through practice. To some extent, I wonder if the level of refactoring Fowler demonstrated is really practical. It is important to make code clear, concise, and efficient, but in the work place where deadlines play a large role it would be very time-consuming to perform such refactorings.

WC2

          This past week we finished the second iteration of our World Crises project. This time was quite a bit more difficult than last time because I worked on the back end, specifically merge import, this time around. My team decided to trade roles from last time, switching from back end to front end and vice versa, so we would get the opportunity to learn all parts of our app. The most difficult part of switching from front end to back end was the learning curve involved in understanding all the code that had been implemented the iteration before.
          This iteration was the first time I experienced the full effect of software engineering at work. Previous projects maybe stressed specific aspects of software engineering such as pair programming, but this project made me appreciate extreme programming for the first time. Most of all I learned the importance of communication between team members. This had to do with the fact the my team switched roles and I had to work with some team members to understand the code they had written the previous iteration. WC2 proved to be the most difficult project thus far.

Week 9

          This week we covered global, class, and instance variables, constructors and destructors, and static and non-static methods in python and java, which were more straightforward than some of the topics covered in the material on the second exam. I know that many people in the class feel that lectures should cover topics like refactoring more than the semantics of the languages, but either way, I feel as though a day has not gone by in class without me learning something new about the languages. Even though CS307 and CS315 were very programming oriented as well, they were not nearly as detailed.
          On Friday we also had to read the first 5 chapters in Refactoring. Unlike some of the other readings we have done this semester, I felt like this one was very long and tedious. Most of the information presented seemed repetitive and, in some cases, common knowledge.

The Second Midterm and World Crises Project

             On Friday we took the second midterm for the course and I thought the programming questions were quite a bit more difficult than the ones on the first exam. While the reading questions were my main weakness on the first exam, I thought the reading questions, the few there were, were pretty simple this time around. Unfortunately, knowing that I had a hard time with the reading questions last time made me study the readings that much more this time. I reread all of the papers and the Database Design website and filled up half of my cheat sheet with important points for each, but did not use this whatsoever on the exam. I thought the programming questions on the first exam were very straightforward and simple for the most part, but the ones on the second exam took much more critical thinking and I felt much more unprepared for them.Overall, I wasn't expecting the level of difficulty on the programming problems that I had faced.
               This week we also finished up the first part of the World Crises project. This is the first project I've ever worked on with more than three people. It was definitely a different experience from any other group project I've ever worked on. It was hard keeping track of what everyone else was working on since the scope of the project was so large and to be honest I felt a lot more unsure about the details of what everyone was doing. Usually when working on group projects I would have some hand in everything that was done, but this time we split up the work between everyone so my main focus was the front end. I worked mostly on the static html pages which was quite enjoyable since I had worked with html before. 


           

Preparing for the Second Midterm

           This week we're preparing for our second midterm exam. This one seems like it will take longer to study for because of all the subtleties between the languages, especially Python. Plus it will be very important to memorize the numerous terms in the sql readings.
           One of the things we talked about this week was the caching that each of the languages implements. It's very interesting to see how the designers decided to implement their language. To be honest, Java's implementation makes more sense to me than Python. For example, the Java int cache goes from -128 to 127 while the Python cache strangely goes from -6 to 256. The more I learn about Python, the more I think that the language is too flexible, if there exists such a thing. All of the different ways to represent a string seem to only make the language more confusing and prone to error.

Week 6

           Recently, I've been having some difficulty with the reading questions on the quizzes. I also found this the most difficult portion on the exam, and I'm not sure what the best strategy is to do well on these questions. While reading the assigned papers or books I try to identity potential questions that could be asked over the readings, but the questions are often more specific than I'm expecting. It seems far too difficult to memorize every detail in the papers and very easy to overlook some things, so I'm at a lost for how to study for these portions of the quizzes and exams.
           The coding examples seem to be getting more difficult to understand and the more unfamiliar as we go, specifically, the python examples. Needless to say, it will take a little more studying to fully grasp everything that can be done in python. Python is definitely a flexible language, but it also makes me question whether some of the flexibility improves the language or makes it more confusing and prone to error. For example, python allows you specify parameters in a function call in almost any order if you specify the name of the parameter you are assigning. An example on the class webpage is f(2, z = 4, y = 3). This can lead to problems though if the method header is changed. Then, the function calls may need to be changed as well. For this reason, I don't see how specifying the parameters in an arbitrary order can be that much more beneficial that putting them in a set order. Perhaps I am so used to java that I don't see some of the benefits of such flexibility.

Netflix

          This week my partner and I started working on the Netflix project which has been the most difficult project thus far. The scope of this program is the largest I've ever had to manage, considering how much input there is to handle (~2GB). My partner had this great idea to compare each user to every other user and calculate the RMSE between them. Then, we would find which pair was most similar in their ratings and predict that subsequent ratings would continue to be similar. Unfortunately, creating the cache for this implementation is proving to be a project of its own because there are so many comparisons to make and so much data to keep track of. I think that this method would be able to produce a more accurate rating prediction, but it might be a struggle to implement.
          In class, we discussed different types of loops, operators, and assignments. Studying all of the different ways it is possible to achieve the same result has shown me that there is so much to learn about a language. I have been writing code in java for over 4 years, but it has made me realize that there is so much about the language that I never knew, not just about what's going on underneath but also about syntax. For example, I never knew you could index an array on-the-fly, even though this seems like a pretty useless function...

Aftermath of Midterm 1

          I was extremely anxious going into the first midterm, not really knowing what to expect. Luckily, it wasn't as difficult as I thought it would be, but a few of the questions still threw me for a loop. The ones I had the most difficulty with were the questions on the readings. While studying for the exam I skimmed over all of the readings and took notes on what I considered the important points of the text, but this was insufficient considering the detail expected in one or two of the questions. It would have served me better to have reread all of the papers since it had been a week or more from the time I had read most them. Other than that, I thought the programming questions were manageable.

Anticipation of the First Midterm

           Our first exam is this Friday and I'm a little anxious to see the kinds of questions that will be on it. For the most part, the readings, assignments, quizzes, and lectures have not been too difficult to understand. However, I am worried about how specific the questions over the readings will be, since the readings were quite extensive and covered a lot of material. I'm also worried to write code in python since I've only programmed twice in python so far and some of the syntax still eludes me from time to time.
          On a different note, my programming partner and I are almost done with the second programming assignment and I found this assignment much easier to manage than the last. I mostly attribute this to pair programming and the learning curve I had to overcome in the last assignment. Having spent more time than expected on the first project, I actually overestimated the amount of time it would take for this one. If I had one ongoing complaint, it would be that it is sometimes difficult to debug your code with Sphere. My partner and I kept getting wrong answers in Sphere and were not able to figure out where we were going wrong simply because Sphere doesn't tell you what test case you're missing. We had to wait for other students in the class to submit their test cases before we found out that we were understanding the problem incorrectly. Sphere can be frustrating because the messages can not help you find out where you're going wrong, but is generally a useful tool in validating program correctness.

First Project

          So the first programming assignment was due this week. I think I implemented it pretty effectively in the end, but needless to say, it was somewhat of a nerve-wracking task. I think the most difficult aspects of the project was figuring out how to design the cache effectively and keeping track of all the deliverables. I spent quite a while trying to figure out how a meta-cache works, and was often confused by the large number of files we had to turn in. Other than that, coding it wasn't terribly difficult. Overall, I grossly underestimated how many hours I would need to work on the project based on my initial assessment of the project, mainly because of the time it took to figure out the cache. I'm definitely glad we will be able to program with someone on our next project.
          The papers this week on pair programming were pretty easy reads and generally very informative. A lot of it seemed to be common sense, but sometimes you forget about "proper" pair programming when you do it. When reading the papers, I realized some things that I could do better when I program with others. Sometimes I tend to hog the keyboard when I should let others do more of the typing. Also, I was kind of surprised when people in the second paper said that they understand the program better when they program by themselves, because I always find that I understand the material better when I have someone to help fill in the holes for me.

Some Interesting Reads

          I have found the readings in the course so far to be long assignments, but quite interesting. While reading the two papers on college advice, I realized how helpful it would have been to have found these papers when I had first started college. Luckily, I had discovered many of the points over the years and my college experience has followed many of them in the end. One piece of advice I was surprised about was to take foreign language classes because I was always under the impression that these classes were very time-consuming and thus not very enjoyable. Sadly, I tried to avoid taking foreign language classes in college at all costs after having taken 5 years in high school. Now I wonder if I missed out on something...
          Likewise, I found the twelve chapters in Extreme Programming to be an interesting read, and discovered a lot of new programming techniques that I had never heard of before. For example, I found the relationship between customers and programmers described in the book to be quite intriguing and the author made many good points about how such a relationship could be highly beneficial. I especially related to how time-consuming email can be since it often takes people longer to respond and information is often lost in translation. I also agreed with the author's explanation of the benefits of pair programming, but found that many of the computer science courses I have taken discouraged programming with others. I understand that the professors want a more accurate representation of people's work, but I feel that there has always been a contradiction between programming in a school setting and in a work setting. For this reason, I am glad that this class relates better to the workplace and stresses pair programming as well as programming in large groups.

First Impressions

           So far, my impression of this course is that it will be very challenging, but I'm interested to see how it explores the more practical side of computer science. I have found that most of the computer science classes I have taken at UT are much more theoretical, and after interning for the past two summers I think that these classes don't necessary translate well into the real world. I feel that my first summer internship taught me more in 3 months than any of the college courses I had taken over the past 3 years. This class, on the other hand, seems as though it would be much more beneficial for the real world since the class stresses working with large groups of people and the benefits of issue tracking, etc. I experienced many of these issues first hand during my internships and found them quite challenging after being thrust into a new workplace system for the first time. Therefore, I am eager to see if this course can make the transition into the workplace much more smooth and hopefully less stressful.