The final blog!
The test was not so bad. Like almost ever other point in this blog, I will mention a comparison to OOP. The final test there was horrendous, and this one really wasn't. I was surprised that there was no python. The UML seemed like it was worth a lot. I wan't expecting it to be there at all. Overall, it was okay, but it helps that I wasn't shooting for an extremely high score.
One of the main reasons I wanted to take the class was the group project. If you're going into a software engineering career, group projects similar to this are going to be your life. You will work with other people on code. Unlike many of you, I didn't need a writing component. I had one from high school and one from CS349 (beware, those of you who are taking it. They care about writing a lot. Or at least one of my TAs did.). I don't feel like I learned as much as some people about the 'working with a group' aspect as a lot of people, because I've had more group projects than most, but it was still a worthwhile experience. More on this below.
Covering Python was definitely a plus. There's a possibility of using Python for my full time job. Due to the amazing teaching of Julian Bishop in CS105 Python, I actually didn't learn that much more about Python. I can probably count the additional topics on one hand. The time in class probably would have been much more beneficial if it wasn't some combination of concepts from OOP and the language from CS105. It did help to hammer the concepts more firmly into my brain.
I did enjoy using GAE. It gave some insight into web frameworks in general (especially when you add in django). Even if you're not using GAE, there are certain ideas and ways of thinking that are spread between web frameworks, and a few of those were present in GAE/django.
Haskell was not my favorite. It's important to experience many languages and ways of thinking in programming, but this isn't the right class for that exposure. It just seems very unrelated to everything. As a side note, many parts of Haskell were described as weird/strange/some synonym, which personally has a negative connotation and I feel less inclined to learn more about it. But that could just be me.
I did enjoy that we covered Refactoring, not so much that a large portion of it was straight-from-book. After working on a REALLY old codebase last summer, I learned about the need to refactor very well, but didn't really know the proper way to go about things.
I enjoy Downing's lecture style. I think it was less effective for the class as a whole than it was last year in OOP, and I'm not sure why. Some questions which were pretty simple took a longer time to answer, and it took up precious class time. I got called on less, which I enjoyed haha. There are always the few quizzes that are pretty sneaky, but they made me attend class, so I'm thankful for that.
I have to say that, overall, I enjoyed Object Oriented Programming more than Software Engineering. I'm going to directly rip off Fred and say that this might be because it was my first class with Downing, and there is quite a bit of overlap. Many of the lectures covered the same concepts. I was expecting there to be something more "Software Engineer"-y about the class material of this course, but it didn't really give much of that. Refactoring, databases, and some design patterns squished in? The advice I give to people is that it is essential to take a Downing class. But I'd probably recommend one rather than multiple with the amount overlapping content if there are other upper division courses that you have interest in. CS373 is a stronger class if you don't have experience in python or much experience working with large groups, and both of those things detracted from the whole experience.
--------------------------------------------------------------------------
Now, I'm going to go on a more personal tangent.
While reflecting on this class, I found that I did already have substantial experience working with groups that a lot of other people never had. In high school, we had an end of the year project during my 2 years taking computer science. Both of them were creating games, which was not only a fun thing to do, but it also started teaching us to code in groups. This was a major thing that I told interviewers about since I understood the significance of being able to work with others. The first two summers of my college career, I had internships creating projects that were built from scratch. Only the team of interns was working on them. All four of these experiences were pretty much the same: clarify everything with teacher/mentors, figure out what we're doing, split up work, complete work, stick everything together. It's the unexperienced way of doing things.
During my first internship, we did have source control between our group of four, but people rarely committed until the end. And when they did, disaster, pretty much. In my second summer, we had source control and committed more often, but my part was a completely separate part from the two other interns, so I rarely had to deal with it. Source control is an absolute essential to understand. While there was source control in OOP, most of the projects were done with both partners in the lab and all from the same CS account, making it pointless. If you did this project properly (not 5 way pair programming oh god, or giving everyone your cs password to get the files oh god), you've actually experienced source control. Thankfully, not all source control is git (not my favorite, nooo fast-forward nooo), but regardless, it's an important thing.
In high school, testing never came up. In my first two internship projects, testing wasn't required. In retrospect, that kinda scares me but kinda doesn't. My first project was an internal tool, but I'm pretty sure it never got used. One of those sad intern projects you realize half way through that there's no way anybody will use it because its impractical, but you keep chuggin on. My second summer project was a test program, so testing the test program seems kinda trippy, but probably could have been done. It still found bugs, but the product we were testing got cancelled, so my untested code isn't floating around anymore anyways. I hope you learned in this class that having untested code is bad. Peter was more lenient about having test cases than I would have actually liked. Even though the books covered testing more than OOP, I feel like I got the message of important testing in OOP more.
The last experience we learned about in this class that I hadn't dealt with in the same way, surprisingly, was dealing with the customer. But I'm not going to say just dealing with the customer because I've experienced that. I'd put it in the category of dealing with a customer making requests that don't seem logical. (Sorry for ripping on you, customers. :) I won't say that I haven't had ANY experience because my previously mentioned summer-project-that-will-never-get-used definitely falls into that category. During my three internships, I've had more freedom working on those projects than in this class. The freedom of my first two projects could be written off as "they're just internal tools", but my third internship was working on a real product that was released. Maybe I'm just lucky to work around people that trust my judgement, who knows? Any company that locks onto some base element (read: schema) that has unfortunate flaws that affect many other things negatively and refuses to change it, I don't want to be working for. =P I would rather be painfully trying to come to a consensus on a schema in phase 2 (which I believe happened some other semester in this class) than stuck with something that we all know isn't good. I think it's clear to anyone who has read my blog that this bothers me a lot. It's probably my biggest gripe of the whole class because I came into the class with high hopes of a real group experience. And in a way, that's a pretty lame biggest gripe out of the whole class.
-------------------------
Just so I don't end on a negative note, I want to say that this is a really great class. I enjoyed the whole semester and had a bunch of fun with the project. It was so addictive that I worked on it while I should have been doing work for other classes. I'll go on continuing to wish that Downing was still teaching the new CS315ish class so that everyone can get the knowledge they should have at that level rather than having to learn some things far too late. Instead, I guess I'll just have to force everyone I know to force everyone they know to take one of his classes.
No comments:
Post a Comment