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.