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.
Sunday, December 4, 2011
Sunday, November 27, 2011
Week #13
It was a very short week with Thanksgiving, and a much needed break. I feel like I've lost all my memory over the break, so hopefully everything snaps back into place when I get into class again (or at least by Friday).
The first presentation from Team Xtreme was very good for an audience of a less technical customer. The use of the three words they came up with was very creative and added to the presentation. It was probably more difficult for the class to step into this role when everyone has labored over the project. They had some good add on features. I'm not much of a twitter fan, so the extra Twitter feed didn't excite me that much, but the spell check on search was good. I know how many times we mistyped things when we were just testing. It's a very useful feature that I didn't even think of.
The second presentation was less impressive, mostly because of the technical failures. Since the bandwidth was out, they should have switched over to local. I really wanted to know that the image showed up. Even if I just saw that the img tag was in the html or something. It ruined the ability to see important and required functionality. The instant search was a very cool feature. It feels like using Google Instant. Pagination was also a good feature.
Looking at the other sites, some other groups did different things that we were barred from doing after asking the customer (TA and Downing). After asking about not repeating links/images based on url, we were shot down. Also, there were some questions we asked about the search and formed our search around those specifications. Honestly, it's a situation that can appear in the real workplace also. You go on and do something without asking vs asking and then being shut down. It all depends on how your customer/boss reacts.
Looking forward to other groups.
The first presentation from Team Xtreme was very good for an audience of a less technical customer. The use of the three words they came up with was very creative and added to the presentation. It was probably more difficult for the class to step into this role when everyone has labored over the project. They had some good add on features. I'm not much of a twitter fan, so the extra Twitter feed didn't excite me that much, but the spell check on search was good. I know how many times we mistyped things when we were just testing. It's a very useful feature that I didn't even think of.
The second presentation was less impressive, mostly because of the technical failures. Since the bandwidth was out, they should have switched over to local. I really wanted to know that the image showed up. Even if I just saw that the img tag was in the html or something. It ruined the ability to see important and required functionality. The instant search was a very cool feature. It feels like using Google Instant. Pagination was also a good feature.
Looking at the other sites, some other groups did different things that we were barred from doing after asking the customer (TA and Downing). After asking about not repeating links/images based on url, we were shot down. Also, there were some questions we asked about the search and formed our search around those specifications. Honestly, it's a situation that can appear in the real workplace also. You go on and do something without asking vs asking and then being shut down. It all depends on how your customer/boss reacts.
Looking forward to other groups.
Sunday, November 20, 2011
Week #12
Friday was the last day of normal class. So strange to be done this early, but I want to see what other people did with their projects. I wanted to wait until people presented to see what people's sites were like, but we have to look at them to finalize our "what is better/worse" part of the presentation. We will be the very last ones to present, so hopefully we make a nice finale.
As with many projects, I'm not completely satisfied with our project's final state. We had tons of ideas (especially on the visual side of things) to make it better in terms of an end user. I really appreciate user-friendly sites, which as I've learned through this project as well, not everyone really cares about. I think it's kind of a shame that more people don't care about the all around user experience rather than just piling on more functionality. I thought by this point that people appreciated the joy that beautiful and easy to use technology brings to people. Of course, there is this whole thing about this only being a school project, and I'm bringing my full blown user oriented thoughts to a product that doesn't have many future users. :)
This week was pretty cool. I wish there were more design patterns covered in this class, but alas. I'm really amazed that it took me this long to learn that Reflection is possible. It's pretty damn awesome. On Friday, we kind of shoved some ideas into class quickly. For factories, the examples were given in Python only and not Java for lack of time. I was walking through the example, but all I could think is. OMG I WANT TO USE THE POWER OF PYTHON. The thing I reallly wished would happen from the beginning was:
def create_maze (room, door) :
m = Maze()
m.add_room(room())
m.add_room(room())
m.add_room(room())
m.add_door(door(m.room(0), m.room(1)))
m.add_door(door(m.room(1), m.room(2)))
return m
-------------------------
>>> maze = create_maze(Room, EnchantedDoor)
>>> type(maze)
<class '__main__.Maze'>
>>> type(maze.room(0))
<class '__main__.Room'>
>>> type(maze.door(0))
<class '__main__.EnchantedDoor'>
But instead, we had to add lots of extra code which is necessary to do the same thing in Java, but not necessary in Python for accomplishing the end goal. It's all part of the pattern, I guess.
RANDOM! For you kids that really love your CS and just really want to take more classes next semester, here's some free online CS classes from Stanford starting in January.
As with many projects, I'm not completely satisfied with our project's final state. We had tons of ideas (especially on the visual side of things) to make it better in terms of an end user. I really appreciate user-friendly sites, which as I've learned through this project as well, not everyone really cares about. I think it's kind of a shame that more people don't care about the all around user experience rather than just piling on more functionality. I thought by this point that people appreciated the joy that beautiful and easy to use technology brings to people. Of course, there is this whole thing about this only being a school project, and I'm bringing my full blown user oriented thoughts to a product that doesn't have many future users. :)
This week was pretty cool. I wish there were more design patterns covered in this class, but alas. I'm really amazed that it took me this long to learn that Reflection is possible. It's pretty damn awesome. On Friday, we kind of shoved some ideas into class quickly. For factories, the examples were given in Python only and not Java for lack of time. I was walking through the example, but all I could think is. OMG I WANT TO USE THE POWER OF PYTHON. The thing I reallly wished would happen from the beginning was:
def create_maze (room, door) :
m = Maze()
m.add_room(room())
m.add_room(room())
m.add_room(room())
m.add_door(door(m.room(0), m.room(1)))
m.add_door(door(m.room(1), m.room(2)))
return m
-------------------------
>>> maze = create_maze(Room, EnchantedDoor)
>>> type(maze)
<class '__main__.Maze'>
>>> type(maze.room(0))
<class '__main__.Room'>
>>> type(maze.door(0))
<class '__main__.EnchantedDoor'>
But instead, we had to add lots of extra code which is necessary to do the same thing in Java, but not necessary in Python for accomplishing the end goal. It's all part of the pattern, I guess.
RANDOM! For you kids that really love your CS and just really want to take more classes next semester, here's some free online CS classes from Stanford starting in January.
Monday, November 14, 2011
Week #11
Sorry for the late blog. Slept for about 18 hours yesterday because I was sick. At least it worked pretty well at making me feel better.
I'm really failing at getting through the reading of Refactoring fast enough. The first 4 chapters were easy enough to read, but to actually absorb any of the rest of the chapters, it takes a lot longer.
The Gender Differences paper seems to come up around the time of the Grace Hopper conference. I didn't have the change to go this year, which is sad because I found it really motivating last year. At least some things were posted online, like this keynote from Sheryl Sandberg, the COO of Facebook: http://www.livestream.com/fbtechtalks/
Sunday, November 6, 2011
Week #10
Most of what we did this week was look at Refactoring. When I was buying the book on Amazon, a lot of the reviews said that this is one of those "if you're working as a Software Engineer, you should read this" books. I do like the kind of "peace of mind" that refactoring gives you that you can always fix things later if you discover a better way (which in most cases you will) and you shouldn't have to feel bad about it. You don't have to sit there and think of all the future possibilities instead of sitting down and getting code written. But it isn't okay to not think of the future at all.
For the reading "New Methodologies", I really like the way that the author describes agile. Being flexible and open to change appeals to me. During one of my internships, the team I was on was making the transition to SCRUM and I think there was a complete failure in communication about the benefits of the new system. He mentions several times that if you don't have people that are willing to do the work associated with an agile methodology, things just won't be right. The software where the team had to fill out estimated times and priorities for tasks in each sprint just seemed like more bureaucratic busywork than something to help the software engineers. I didn't stay long enough for it to actually be implemented, but I have no doubt that it had less impact than on a team who understood the benefits completely. It also made me think less of the extra work these methodologies bring to the table.
Looking forward at what's scheduled, I see that we're taking it one step further with the example of the first chapter, which seems cool and gives more meaning to covering all the other refactorings in class.
For the reading "New Methodologies", I really like the way that the author describes agile. Being flexible and open to change appeals to me. During one of my internships, the team I was on was making the transition to SCRUM and I think there was a complete failure in communication about the benefits of the new system. He mentions several times that if you don't have people that are willing to do the work associated with an agile methodology, things just won't be right. The software where the team had to fill out estimated times and priorities for tasks in each sprint just seemed like more bureaucratic busywork than something to help the software engineers. I didn't stay long enough for it to actually be implemented, but I have no doubt that it had less impact than on a team who understood the benefits completely. It also made me think less of the extra work these methodologies bring to the table.
Looking forward at what's scheduled, I see that we're taking it one step further with the example of the first chapter, which seems cool and gives more meaning to covering all the other refactorings in class.
Sunday, October 30, 2011
Week #9
This week I'm covering two different topics. On any normal blog this would be two separate posts, but I didn't think I could get you to click on two links. :) Another thing worthy of mention is starting to read Refactoring. A bit of the beginning was painfully simple and repetitive, but it's useful stuff.
TA vs Customer
The first part is inspired by the grading of the first part of the project and the conversation that followed when we got our grades back. You guys may have seen the Piazza post about the discussion following the 11am class, and this is what it's all about (in addition to another conversation that happened). To give background, we were required to turn in an XML Schema as part of the first stage of our project. The best schema after the first stage would be chosen and the rest of the class would be required to use it for the remaining part of the project. At first, this bothered me because it hinders continuous design throughout the project. As we learn more, we aren't allowed to change a significant part of the project to improve the code or the final product that the user sees. But that's a completely different story. The issue that came up is that we got 6 out of 15 points taken off for not having ID/IDREFs in the schema. (some of these points will be returned)
It's a difficult thing to grade the design of a partially completed project. Different people think in different ways and therefore see different solutions. We saw a problem with having a schema that was too strict and didn't allow merging new data easily, so we created a weaker schema that used the names as informal ids. We still haven't found a clean solution for merging new data with ID/IDREFs present. The conclusion that we came to in the after-class discussion is that Peter is a very picky customer, and we have to do what he wants. If something is unclear, ask him and make it clear. As with many other things in the never-ending divide between academia and "the real world", a TA and a customer just aren't exactly alike.
1. The final product is more important than the intermediate.
When working with a customer, they shouldn't care that much about the intermediate steps, especially compared the the final product. I'm not saying they don't care about intermediate steps, it's extremely important to make sure that everything is going in the right direction. The final product simply carries more weight because it is seen by all the REAL customers. In this class, the intermediates are equal to the final product.
2. There should be more open communication between a customer and developer than what is normally acceptable between a student and TA.
If I were to walk up to my Automata TA with my homework in hand and ask him if it looked good, he would not go through every problem and tell me whether or not I was wrong and how he wants it. I expect the same from Peter. He isn't going to grade the whole project before he has to and tell me what's wrong. We can communicate with the customer through Piazza about problems that we discover. As with our schema problem, there are some choices the programmer doesn't second guess, but upon seeing the work, the customer would notice and conversation would take place. I'd like to think of the customer reviewing the product as a further level of communication. We only get this further level of communication when we are graded, and the customer communicates back to us by subtracting points.
3. The customer usually only works with one team to create a product, not six.
Peter is the luckiest customer ever in terms of the resources he has. To complete a relatively small project, he has 31 engineers who have conveniently split into six groups. A customer in the real world usually has one team working on the project and doesn't have the luxury of choosing who has the best stuff. Projects aren't graded on a relative scale because there's only one team to build the project. Yet this project is being graded on a scale relative to what other teams do.
While the TA = customer comparison works to teach some aspects of open ended problem solving, it doesn't really encompass the experience of pleasing a Customer. I was hoping for a very-close-to-real-world experience with this project, and it didn't quite reach my high expectations here.
Joel Test
This guy who wrote the Joel Test is obviously familiar with the Microsoft environment. It's no secret, he mentioned it multiple times. After interning at three different companies (the first being Microsoft), I can tell that his views are very skewed towards the Microsoft, and more specifically slow release, way of thinking. I'm speaking from what I learned over two years ago, so a few things have most likely changed, but the background information I know is scattered throughout.
3. Do you make daily builds?
Microsoft has long release cycles for many of its products. Office for desktop, Windows OS, even Internet Explorer. Some web products have daily releases, so you should be able build daily or else.
5. Do you fix bugs before writing new code?
This section also has strong ties to Microsoft's slow release cycle. If you're releasing every day, you better have as few bugs as possible, because those bugs are all getting released.
8. Do programmers have quiet working conditions?
This one reeks of a Microsoft mindset. For those of you who don't know, Microsoft mostly uses separate offices for every person. They don't believe in cubes or open work spaces. It seems kind of awesome to have your own office for a while before starting to recognize the downsides. Open work spaces promote communication on more levels than just "how do I do this thing I could search", and open communication is important for reason explored in XP as well as other social aspects. When you have offices with doors, you're also less likely to ask questions that should be asked, and can only be answered by other people working on the same project. Without asking questions, the whole process of development moves slower. While being interrupted sucks, the example used in the paper can be eliminated by people knowing when its the right time to ask a question. You have to be aware of the trade off, but sticking everyone in an office is not the only solution.
9. Do you use the best tools money can buy?
I chuckled when I first read this title. Because it said "buy". More and more companies are getting into the habit or not using the best tools money can buy, but using the best tools they can make. Then once I started reading, I realized they weren't really talking about software tools, but mostly hardware. So for hardware tools, I would agree. Dual monitors are the best, that's why I have one at home. I knew someone with 24GB of RAM to build faster. Give people the hardware they need when they need it. But when you start branching into the software end... as they mention Paint... the best tool that money can buy for imaging software used purely by developers is probably GIMP. And tada, it's free. You venture into subversioning software and bug trackers, build systems, and the like. At a certain point, the big tech companies start to make their own, and I'd be surprised if Microsoft hasn't started to do the same. You do this well, and it has even greater positive impact on productivity than any hardware could.
Overall, all of the Joel test rules do apply to good software teams. You just have to be familiar with where he's speaking from, and take a few of them (the last two I mentioned) a bit less literally.
BTW, you're a trooper if you actually got the end of all this ranting.
TA vs Customer
The first part is inspired by the grading of the first part of the project and the conversation that followed when we got our grades back. You guys may have seen the Piazza post about the discussion following the 11am class, and this is what it's all about (in addition to another conversation that happened). To give background, we were required to turn in an XML Schema as part of the first stage of our project. The best schema after the first stage would be chosen and the rest of the class would be required to use it for the remaining part of the project. At first, this bothered me because it hinders continuous design throughout the project. As we learn more, we aren't allowed to change a significant part of the project to improve the code or the final product that the user sees. But that's a completely different story. The issue that came up is that we got 6 out of 15 points taken off for not having ID/IDREFs in the schema. (some of these points will be returned)
It's a difficult thing to grade the design of a partially completed project. Different people think in different ways and therefore see different solutions. We saw a problem with having a schema that was too strict and didn't allow merging new data easily, so we created a weaker schema that used the names as informal ids. We still haven't found a clean solution for merging new data with ID/IDREFs present. The conclusion that we came to in the after-class discussion is that Peter is a very picky customer, and we have to do what he wants. If something is unclear, ask him and make it clear. As with many other things in the never-ending divide between academia and "the real world", a TA and a customer just aren't exactly alike.
1. The final product is more important than the intermediate.
When working with a customer, they shouldn't care that much about the intermediate steps, especially compared the the final product. I'm not saying they don't care about intermediate steps, it's extremely important to make sure that everything is going in the right direction. The final product simply carries more weight because it is seen by all the REAL customers. In this class, the intermediates are equal to the final product.
2. There should be more open communication between a customer and developer than what is normally acceptable between a student and TA.
If I were to walk up to my Automata TA with my homework in hand and ask him if it looked good, he would not go through every problem and tell me whether or not I was wrong and how he wants it. I expect the same from Peter. He isn't going to grade the whole project before he has to and tell me what's wrong. We can communicate with the customer through Piazza about problems that we discover. As with our schema problem, there are some choices the programmer doesn't second guess, but upon seeing the work, the customer would notice and conversation would take place. I'd like to think of the customer reviewing the product as a further level of communication. We only get this further level of communication when we are graded, and the customer communicates back to us by subtracting points.
3. The customer usually only works with one team to create a product, not six.
Peter is the luckiest customer ever in terms of the resources he has. To complete a relatively small project, he has 31 engineers who have conveniently split into six groups. A customer in the real world usually has one team working on the project and doesn't have the luxury of choosing who has the best stuff. Projects aren't graded on a relative scale because there's only one team to build the project. Yet this project is being graded on a scale relative to what other teams do.
While the TA = customer comparison works to teach some aspects of open ended problem solving, it doesn't really encompass the experience of pleasing a Customer. I was hoping for a very-close-to-real-world experience with this project, and it didn't quite reach my high expectations here.
Joel Test
This guy who wrote the Joel Test is obviously familiar with the Microsoft environment. It's no secret, he mentioned it multiple times. After interning at three different companies (the first being Microsoft), I can tell that his views are very skewed towards the Microsoft, and more specifically slow release, way of thinking. I'm speaking from what I learned over two years ago, so a few things have most likely changed, but the background information I know is scattered throughout.
3. Do you make daily builds?
Microsoft has long release cycles for many of its products. Office for desktop, Windows OS, even Internet Explorer. Some web products have daily releases, so you should be able build daily or else.
5. Do you fix bugs before writing new code?
This section also has strong ties to Microsoft's slow release cycle. If you're releasing every day, you better have as few bugs as possible, because those bugs are all getting released.
8. Do programmers have quiet working conditions?
This one reeks of a Microsoft mindset. For those of you who don't know, Microsoft mostly uses separate offices for every person. They don't believe in cubes or open work spaces. It seems kind of awesome to have your own office for a while before starting to recognize the downsides. Open work spaces promote communication on more levels than just "how do I do this thing I could search", and open communication is important for reason explored in XP as well as other social aspects. When you have offices with doors, you're also less likely to ask questions that should be asked, and can only be answered by other people working on the same project. Without asking questions, the whole process of development moves slower. While being interrupted sucks, the example used in the paper can be eliminated by people knowing when its the right time to ask a question. You have to be aware of the trade off, but sticking everyone in an office is not the only solution.
9. Do you use the best tools money can buy?
I chuckled when I first read this title. Because it said "buy". More and more companies are getting into the habit or not using the best tools money can buy, but using the best tools they can make. Then once I started reading, I realized they weren't really talking about software tools, but mostly hardware. So for hardware tools, I would agree. Dual monitors are the best, that's why I have one at home. I knew someone with 24GB of RAM to build faster. Give people the hardware they need when they need it. But when you start branching into the software end... as they mention Paint... the best tool that money can buy for imaging software used purely by developers is probably GIMP. And tada, it's free. You venture into subversioning software and bug trackers, build systems, and the like. At a certain point, the big tech companies start to make their own, and I'd be surprised if Microsoft hasn't started to do the same. You do this well, and it has even greater positive impact on productivity than any hardware could.
Overall, all of the Joel test rules do apply to good software teams. You just have to be familiar with where he's speaking from, and take a few of them (the last two I mentioned) a bit less literally.
BTW, you're a trooper if you actually got the end of all this ranting.
Sunday, October 23, 2011
Week #8
Looking at the viewing statistics graph of the blog amuses me. The only people who do read look at it right when it's posted. It's good to know some people are reading what others write, even if it's relatively few out of both classes. You guys are the best. :)
I don't really have anything to go on about this week. The test was not my favorite. I didn't put down my best work. The haskell problems were by far my least favorite because of my inexperience with the language. Oh well, what can you do?
Another one of my least favorite things is UML. I have never seen it used anywhere outside of a Downing class. After talking to someone, I realized it's a bigger thing in companies that aren't all technical so it may not exist in my tiny little ecosystem, but it has a bigger part in the rest of the world. Between non-technical people and technical people, it creates much better understanding.
I was looking at piazza to see if the class schema has been decided, but sadly, it wasn't. :( It's kind of a blocking issue to continue with the project, so it would be nice to have that, but I guess we don't really need to be starting with the project yet. I did run into the awesome post about someone getting an interview from Google because of blog posting. Software Engineering and OOP are classes that Google should love because of their relevance to everyday work. Personally, I think that OOP has helped me on my career path more than any other class. Besides helping with interview questions, it taught me C++ which I used during my internship, which ultimately resulted with me getting a full time offer. THANK YOU, DOWNING! :)
I don't really have anything to go on about this week. The test was not my favorite. I didn't put down my best work. The haskell problems were by far my least favorite because of my inexperience with the language. Oh well, what can you do?
Another one of my least favorite things is UML. I have never seen it used anywhere outside of a Downing class. After talking to someone, I realized it's a bigger thing in companies that aren't all technical so it may not exist in my tiny little ecosystem, but it has a bigger part in the rest of the world. Between non-technical people and technical people, it creates much better understanding.
I was looking at piazza to see if the class schema has been decided, but sadly, it wasn't. :( It's kind of a blocking issue to continue with the project, so it would be nice to have that, but I guess we don't really need to be starting with the project yet. I did run into the awesome post about someone getting an interview from Google because of blog posting. Software Engineering and OOP are classes that Google should love because of their relevance to everyday work. Personally, I think that OOP has helped me on my career path more than any other class. Besides helping with interview questions, it taught me C++ which I used during my internship, which ultimately resulted with me getting a full time offer. THANK YOU, DOWNING! :)
Sunday, October 16, 2011
Week #7
Time is flying by. Already week 7? Already project 4?
I wanted to spend this week talking mostly about design. Design in something that seems hard to master, and on top of that, we don't get very much practice with it in school. I'm sure there are some good books on design out there. If you happen to know any offhand, I'd love to know the names. The project has taken up quite a bit of time so far, and I don't think it will let down much, but it's good to know a good book to read when I get the time for it. From the reading next week and the whole basis of the book Refactoring, I assume we will be covering more about design, and that would be freakin' awesome. (and I'll add another post as I get less stupid)
In school, we don't have much experience with designing large and complex systems. This project is the largest and most complex thing I will probably ever create in school unless something suddenly appears next semester. The runner up would by the final project for CS345 where my partner and I created a language that was a combination of Prolog and Jython which made for an... interesting... language. Still, the greater point is that we don't really have much design to think about. Jython does have a large codebase that you can learn about design from, but I'm sure many just found where the code needed to be changed and ignored anything else. Every other project during school has been basically like "oh it outputs the right answer usually from one file and the code looks reasonable? awesome". We just don't get to organize ridiculously complex code bases in school.
My experience with design in internships has been lacking also. Two of my internships involved writing code from scratch rather than working out of an existing code base. So basically, a few other interns and I, all of which were probably lousy at design, had to work together to create a design. Neither experience really gave enough feedback for us to know if we were really doing what was best. For all I know, I could have been learning completely lousy design practices for 6 months. My last internship, I was actually working on an old existing codebase. It finally gave me a view into what complex design looked like, though it was hard to understand why it was implemented a certain way.
Software design is massively important to a project. If a code base isn't extensible or understandable enough for example, you're going to be fighting a terrible battle to have a good product in the end. I may be asking for too much out of school. We do, after all, still have the rest of our careers to keep learning. And design isn't just some algorithm. There are good practices overall, but different situations call for different things, and that may be something best learned through experience with a specific project. Honestly, I don't know.
On a slightly unrelated tangent, I'm kind of bummed by the locking in of our schema early on. It comes off as very non-agile/XP to me. It's not letting us change design specs over time. Maybe nothing in the required specs will require a change in our schema, but for features that step out of the box, it could matter.. maybe... I do see the purpose in locking on to one so that data sharing is a lot better, maybe I've just been XP-brainwashed (or XP-empowered at least).
Test this Friday? It's going to be a fun week.
I wanted to spend this week talking mostly about design. Design in something that seems hard to master, and on top of that, we don't get very much practice with it in school. I'm sure there are some good books on design out there. If you happen to know any offhand, I'd love to know the names. The project has taken up quite a bit of time so far, and I don't think it will let down much, but it's good to know a good book to read when I get the time for it. From the reading next week and the whole basis of the book Refactoring, I assume we will be covering more about design, and that would be freakin' awesome. (and I'll add another post as I get less stupid)
In school, we don't have much experience with designing large and complex systems. This project is the largest and most complex thing I will probably ever create in school unless something suddenly appears next semester. The runner up would by the final project for CS345 where my partner and I created a language that was a combination of Prolog and Jython which made for an... interesting... language. Still, the greater point is that we don't really have much design to think about. Jython does have a large codebase that you can learn about design from, but I'm sure many just found where the code needed to be changed and ignored anything else. Every other project during school has been basically like "oh it outputs the right answer usually from one file and the code looks reasonable? awesome". We just don't get to organize ridiculously complex code bases in school.
My experience with design in internships has been lacking also. Two of my internships involved writing code from scratch rather than working out of an existing code base. So basically, a few other interns and I, all of which were probably lousy at design, had to work together to create a design. Neither experience really gave enough feedback for us to know if we were really doing what was best. For all I know, I could have been learning completely lousy design practices for 6 months. My last internship, I was actually working on an old existing codebase. It finally gave me a view into what complex design looked like, though it was hard to understand why it was implemented a certain way.
Software design is massively important to a project. If a code base isn't extensible or understandable enough for example, you're going to be fighting a terrible battle to have a good product in the end. I may be asking for too much out of school. We do, after all, still have the rest of our careers to keep learning. And design isn't just some algorithm. There are good practices overall, but different situations call for different things, and that may be something best learned through experience with a specific project. Honestly, I don't know.
On a slightly unrelated tangent, I'm kind of bummed by the locking in of our schema early on. It comes off as very non-agile/XP to me. It's not letting us change design specs over time. Maybe nothing in the required specs will require a change in our schema, but for features that step out of the box, it could matter.. maybe... I do see the purpose in locking on to one so that data sharing is a lot better, maybe I've just been XP-brainwashed (or XP-empowered at least).
Test this Friday? It's going to be a fun week.
Sunday, October 9, 2011
Week #6
There are a few things in computer science that belong on my "I should know more about this because I've been around this a lot and will be around it for most of my full time career". Datastores/Databases belong on that list. I've used them while still knowing surprisingly little about how they work. While I was interning over the summer at Google, I heard BigTable and other internal datastores mentioned all the time, but I never had the time to look through some information internally since it wasn't directly related to my project. Hell, I went to Big Table Cafe for lunch pretty much every day. :) Seems like I'll start learning more about this internal Google stuff from outside Google, since App Engine uses it.
Between the reading from last Friday and the reading for Monday, I've learned quite a bit about databases, and really, I need to learn quite a bit more. Between working on the WiCS website admin panel along with Cassie, playing around on my own website, and doing this upcoming project, I will definitely learn a few things.
I'm really looking forward to the group project. The projects were really educational in CS371p and they have been so far in this class. I like the fact that the class material and the projects are distinct. We're going to be learning a lot of things not taught in class it seems, and that just makes for more knowledge, which is a great thing. I've found the projects are even more educational and exciting in this class, since much of the python taught in class is review after taking Julian Bishop's one hour python class.
Between the reading from last Friday and the reading for Monday, I've learned quite a bit about databases, and really, I need to learn quite a bit more. Between working on the WiCS website admin panel along with Cassie, playing around on my own website, and doing this upcoming project, I will definitely learn a few things.
I'm really looking forward to the group project. The projects were really educational in CS371p and they have been so far in this class. I like the fact that the class material and the projects are distinct. We're going to be learning a lot of things not taught in class it seems, and that just makes for more knowledge, which is a great thing. I've found the projects are even more educational and exciting in this class, since much of the python taught in class is review after taking Julian Bishop's one hour python class.
Sunday, October 2, 2011
Week #5
Looking back on this past week, there was nothing really memorable. It was a bit of a slow week after a test. I needed a refresher on some python stuff. I had definitely forgotten little things like the ability to loop through two lists in a list comprehension. We did get back our test scores, and I think I did better on the first test than I ever did in OOP, so I'm happy.
The project is going fine. I wish we could get it lower, but at least it's below 1.0 for now. It's actually an interesting project. Like I said last week, there just isn't enough time to make it as good as we could with more complex stuff. I was wondering if there was a time limit on the programs that were competing for the netflix prize though. I was in a really-wanting-to-program mood this past friday afternoon, but my partner wasn't available to work, so I coded some of the WiCS admin panel instead. I found a downside to pair programming. :P
The project is going fine. I wish we could get it lower, but at least it's below 1.0 for now. It's actually an interesting project. Like I said last week, there just isn't enough time to make it as good as we could with more complex stuff. I was wondering if there was a time limit on the programs that were competing for the netflix prize though. I was in a really-wanting-to-program mood this past friday afternoon, but my partner wasn't available to work, so I coded some of the WiCS admin panel instead. I found a downside to pair programming. :P
Sunday, September 25, 2011
Week #4
Test
The test was pretty much what I expected format wise. I think that it was missing some of the more current stuff we had taken a bit of time in class on. The reading questions are never my favorite, but remembering potty names for pair programming was probably my least favorite. Knowing the proper way to pair program is important, knowing the exact analogy being made in a section of a paper is less important.
Database Design
I've never had the experience of working on a large project dealing with a database. During one of my summers, I had a very small database shared between three people and it was understandably not a huge headache. :) The mention of a DBA (say what?) or database administrator was new to me. I've never encountered one in my summerly adventures. I do see how databases make rapid development a lot more difficult even from my 3 person database adventures, so normal databases must be pretty bad. It seems like a good thing to know how to handle.
Project
I'm looking forward to the next project. This is one that I've heard mentioned in the lab many-a-time. It seems like another one of those projects where you kind of wish you had all the time in the world to play with it and speed it up, but sadly, you don't, and there are other things to be doing.
The test was pretty much what I expected format wise. I think that it was missing some of the more current stuff we had taken a bit of time in class on. The reading questions are never my favorite, but remembering potty names for pair programming was probably my least favorite. Knowing the proper way to pair program is important, knowing the exact analogy being made in a section of a paper is less important.
Database Design
I've never had the experience of working on a large project dealing with a database. During one of my summers, I had a very small database shared between three people and it was understandably not a huge headache. :) The mention of a DBA (say what?) or database administrator was new to me. I've never encountered one in my summerly adventures. I do see how databases make rapid development a lot more difficult even from my 3 person database adventures, so normal databases must be pretty bad. It seems like a good thing to know how to handle.
Project
I'm looking forward to the next project. This is one that I've heard mentioned in the lab many-a-time. It seems like another one of those projects where you kind of wish you had all the time in the world to play with it and speed it up, but sadly, you don't, and there are other things to be doing.
Sunday, September 18, 2011
Week #3
Unfortunately, I missed a day of class this week. The code samples at least showed me what the we covered, and some of the material came up again in the next class, so it should be fine except for that -5 pts and +1 to missed quizzes. :( We're still covering basic but invaluable things to know in the language you're using. Not knowing how efficient your code is can absolutely destroy the usefulness of all your hard work, and the sad thing is we don't get taught about surprisingly inefficient things (like string concat) even after we've used it many, many times.
On the project side of things: My partner and I got a simple solution accepted by Sphere pretty quickly, but it was really really slow, so we're working on getting our faster solution accepted.
On Extreme Programming:
Honestly, I was really happy to be done with the XP book we were assigned. It has a lot of great advice about getting a product out there and then some wishy-washy stuff. In the end, it just got to be ridiculously repetitive. I wish there was a book that was exactly the same but about half the size, because they could manage to fit it in that amount of space if they didn't repeat themselves that much.
The Afterword was the combined most enlightening/frustrating part of the book. It was enlightening because of the point he was making about it being validation centric. Releasing things that work is important. Nobody can argue that. (The huge problem of releasing things that pass all the tests but still aren't that great still exists though.) On the other hand, the "because XP does everything to the extremes" being repeated drove me absolutely crazy. NOOOO! I know XP has extreme in the name, but to do everything to the extremes is never a good idea. Whenever the book mentioned taking something to the extreme (and then softly mentioning in the background that its actually impossible to do it that way), I cringed so much. If pretending works for you, then it works, I just don't like pretending in this kind of situation. I'll stay with my Almost Extreme Programming.
I don't know where the line gets drawn between good ol' programming practices and extreme programming from the book, because they speak like they created everything. Nevertheless, the goals of XP seem like great things to get done: improved communication, constant validation, changing design. If anybody is under the impression that there are people out there doing pure waterfall method right now, that is sooo wrong. Employees and teams and companies have evolved. Some better than others. Some companies do pick up Agile/XP. The team I was on at Cisco Systems was changing to Agile shortly after I left. Others take bits and pieces (but I don't give XP credit for those bits and pieces, I give credit to multiple people figuring out the same thing because it tends to be the right thing). In my opinion, all of the things that are good about XP can be achieved in other ways, without this weird system.
I'm actually going to spend more time looking into other methodologies when I have more time. Somebody out there has probably already created what I see as the perfect programming methodology -- I kinda hope nobody has because I prefer the way I work not having a name that can be hyped and sold. Need to get some rest for the career fair for now though. :)
On the project side of things: My partner and I got a simple solution accepted by Sphere pretty quickly, but it was really really slow, so we're working on getting our faster solution accepted.
On Extreme Programming:
Honestly, I was really happy to be done with the XP book we were assigned. It has a lot of great advice about getting a product out there and then some wishy-washy stuff. In the end, it just got to be ridiculously repetitive. I wish there was a book that was exactly the same but about half the size, because they could manage to fit it in that amount of space if they didn't repeat themselves that much.
The Afterword was the combined most enlightening/frustrating part of the book. It was enlightening because of the point he was making about it being validation centric. Releasing things that work is important. Nobody can argue that. (The huge problem of releasing things that pass all the tests but still aren't that great still exists though.) On the other hand, the "because XP does everything to the extremes" being repeated drove me absolutely crazy. NOOOO! I know XP has extreme in the name, but to do everything to the extremes is never a good idea. Whenever the book mentioned taking something to the extreme (and then softly mentioning in the background that its actually impossible to do it that way), I cringed so much. If pretending works for you, then it works, I just don't like pretending in this kind of situation. I'll stay with my Almost Extreme Programming.
I don't know where the line gets drawn between good ol' programming practices and extreme programming from the book, because they speak like they created everything. Nevertheless, the goals of XP seem like great things to get done: improved communication, constant validation, changing design. If anybody is under the impression that there are people out there doing pure waterfall method right now, that is sooo wrong. Employees and teams and companies have evolved. Some better than others. Some companies do pick up Agile/XP. The team I was on at Cisco Systems was changing to Agile shortly after I left. Others take bits and pieces (but I don't give XP credit for those bits and pieces, I give credit to multiple people figuring out the same thing because it tends to be the right thing). In my opinion, all of the things that are good about XP can be achieved in other ways, without this weird system.
I'm actually going to spend more time looking into other methodologies when I have more time. Somebody out there has probably already created what I see as the perfect programming methodology -- I kinda hope nobody has because I prefer the way I work not having a name that can be hyped and sold. Need to get some rest for the career fair for now though. :)
Sunday, September 11, 2011
Week #2
Another week in Software Engineering. Finished Collatz, and it wasn't as stressful of an experience as it was last year. It still took longer than I expected because I attempted to make it faster, but it didn't actually make much of a difference. I'm very glad that the extra credit was only required for one of the languages, since I was having trouble with the python being accepted, and I heard it was a problem with the skeleton which I would have been very unlikely to find.
V2 was also very weird, since it forced you to give the wrong answer. Comparing it with the readings for this week, I would say it's teaching the wrong lessons. "Only make the size of a number as large as it needs to be" = things exploding in space, but on land we're forced to do it. =)
Still going over the basics of Python in comparison to Java. Haskell is also thrown in there and I'm not exactly sure why we're including it also. It's a really weird language.
I'm looking forward to getting into pair programming even though its another OOP project.
Monday, September 5, 2011
Week #1
The first week (plus the little half week beforehand) was very very similar to Object Oriented Programming CS371P. Pretty much take the same content and swap in some Python for C++. I'm sure the repetitiveness will end quickly as we move past the first project, but I don't have much to say about the content of the class currently. I expect all the arm twisting by now. :)
I'm as excited about this class as I was for OOP. For OOP, I took the class to improve my C++, plus I had heard that it was a good class to take because you learn things you actually use out there in the real world. I had wanted to take Software Engineering since before I took OOP, for no other reason than "That's the title of my future job. I might want to take that class". Of course, I've learned more about what the course is actually about, learned how much you get out of a Downing class, and think it sounds like a great class to take. I took a one hour python class, but I still have much to learn on that front. The whole entire situation with group projects puts you in an environment that resembles the real world much more than any other part of this CS program which is something I'm looking forward to.
The Downing Experience of class is still definitely there, and I don't think I'll ever be fully prepared to be called on. :P
I'm as excited about this class as I was for OOP. For OOP, I took the class to improve my C++, plus I had heard that it was a good class to take because you learn things you actually use out there in the real world. I had wanted to take Software Engineering since before I took OOP, for no other reason than "That's the title of my future job. I might want to take that class". Of course, I've learned more about what the course is actually about, learned how much you get out of a Downing class, and think it sounds like a great class to take. I took a one hour python class, but I still have much to learn on that front. The whole entire situation with group projects puts you in an environment that resembles the real world much more than any other part of this CS program which is something I'm looking forward to.
The Downing Experience of class is still definitely there, and I don't think I'll ever be fully prepared to be called on. :P
Subscribe to:
Posts (Atom)