Trees and Branches

First of all, getting those midterm marks back was a bit scary I'd say. The first one is honestly always the worst one for me because it sets the pace for the rest of the semester. So I guess it's a good thing I didn't do bad on this midterm. The class average is in the high 70's though, and I think that's a pretty decent mark for us all to be averaging around.

Now getting back to the more important stuff, the implementation of recursion in data structures, namely Trees. To be fair, I did learn the basics of this in high school comp sc so I can't really tell how difficult a concept this is right now for everyone to grasp, but I feel like it's not that terrible. The whole idea behind recursion is to break down a problem into smaller versions of itself and that is exactly how we apply it to trees. Break the branches down till all you have left are trees with just one single node. The terminology involved with trees is a bit more confusing than I thought it would be, with arity and branching factor, and the height and the depth but I think it'll become pretty clear after a while of working with trees. 

Midterm + Recursion

First midterm done, I think we all deserve a pat on the back. To be honest, I had not expected such a detailed class construction for the first question, but then again when I finished it I realized it wasn't too bad. The only problem I had was finding enough time to complete the paper. I DID complete it, don't worry, but it was a bit of a rush at the end. The designing threw me off a bit and I don't really think that the time we had was enough to do all the question well, especially if we got stuck on one question or one part. Basically, what I'm trying to say here is that there wasn't too much time to think, you had to write it all down pretty fast.

Midterm aside, the topic we're at now is one of my favourite, because lets face it, the power of Recursion is pretty darn awesome. Its 10 lines of code fitted in just half or less of the space. Pretty mind blowing. And calling upon a function form with itself!? What! That's like inception right there. I wrote a bit about this in my last post too and I'm pretty sure I just repeated some of the stuff I said there. Nevertheless, now that we've understood the power of recursions we're also supposed to use it in our assignments and labs. That was something I forgot to do this lab because I'm not really used to coding recursively all the time. But I guess it's just a habit we all will have to get ourselves into because recursion is just that bad ass.

First Impressions

For a lot of the people I have talked to so far, this course has been a pretty big jump from 108. From having to write only basic code and comments to designing entire classes and dealing with inheritance, all in just the first assignment of the course, people seem to be getting worried about how its going to be in the future. But if you think about it, the topics we have covered so far are not that complicated. OOP is the basic way in which most of the commonly used programming languages work and understanding the concept is very important for anyone in CS. The other topic we've covered till date is Recursion. My initial attempt at understanding it was basically this.

But when I finally got it, it was pretty amazing. Doing complicated problems in just 4 lines of code and that too by having something call on itself seems like a pretty cool thing to me. Once you trace it in your head you see the simple brilliance of the method.

Lecture topics aside, we had our first assignment due this Thursday. And boy was that an unexpected struggle. The main problem when it comes to design I think, is that there are so many ways to go about the same problem. Even with the specifics we had given to us at the start of the assignment, what gave me the most trouble was making decisions as to how to make my classes, specially their methods. Also, given that we didn't have to make too complex a strategy to actually play the game, we ended up over thinking the rest of what we had to do. That inevitably led to a lot of confusion and meaningless stress. But at the end I think we pulled through pretty nicely.

Why Geeks should write

Given the technical nature of CS, most people think that words do not have much use in the field. However, communication skills are not to be underestimated for us self proclaimed geeks. As Joel Spolsky says on his blog 'Joel on Software', "The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it's not whether they prefer Python or Java. It's whether they can communicate their ideas." It matters not how well you can write in the language of programmers if you cannot write in the language of Humans.

One of the ways in which writing comes in handy to a programmer is in keeping track of what you do and how you do it. Despite what some people(like myself) may believe, you cannot possibly keep track of every single thing you did in every single line of your 100 line program. Having written up code for any assignment, there will come a point where you will hit an error and then you shall be left wondering where you went wrong. So when you go about debugging you code and maybe trying to find out where you messed up, writing out your process would definitely help. Furthermore, the whole point of making apps, advancing technology, all what we do in CS, is to make things that we want people to use all the time. How can anyone possibly use something if they don't understand what it is or what it does? A good programmer should be able to write and communicate to their peers as well as their customers what their code does. Without that, no matter how brilliant the code, nobody will understand its value.

So do yourself a favour, and pick up those writing skills you left behind in High School English.