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! :)
Subscribe to:
Posts (Atom)