Trust the Code Not the Comment

One of the first things I learned while being a TA is that when code is not working do not read the comments, read the code. Why is this? The comments lie, more often than not when something is not working the comments will not say the same thing as the code. Why is this? Well the person with the issue in the code does not fully know how to get the code to work and thus will not document the non-working code correctly. If they did know how to get the code to work right they would not need to see a TA.

I find reading the code not the comments to continue to be true in the corporate world. More often then not the comments in the code do not tell the full story of what the code does or the comments are out of date or the comments are just flat out a lie. It is normally, best to just use the code as your guide to what the software is doing (or not doing). This is even true in OSS Projects. These projects are not written by software Gods and more often than not the person doing the documentation is not the same person that wrote the code.

When in doubt (and even when not in doubt) have the code be your guide and pay no attention to the comments. Now this is not to say do not write comments. I myself write comments all the time in my code (even for software that I write for myself). I normally trust my own comments and find them to be helpful for to speak on the reasons I write one line of code over another, but I write my comments in such away as to still let the code speak for it self. After all if the code cannot be read, then it should be rewritten in a readable way.

TAs and Samples of the Class

I got through Grad school at NIU by being a TA (and a GTA one semester). One thing I quickly learned was that the students that TAs see are by far not the cream-of-the-crop. If you think about it this would have to be true, if the student knew what they were doing they would not need to see the TA (unless they are smart and need some type of feedback about how smart they are). Now do no miss understand me, I not saying that see a TA makes you an idiot, but people that see TAs tend to be those that are having a hard time with the class.

One thing that most people that need to see TAs have in common is that they do not know how to figure out were their mistakes are. If these people could figure out where their mistake were they would stand a good chance of being able to find some help outside of asking a TA (e.g. Google). (This kind of thing contiues into the work place, with less apt people bugging compentent people for assistance.)

Every now-and-then, it does happen that a student will come in and say I am having such-and-such problem and I am very sure that the error is here. Most of the time these students are right, the TA can quickly assist them and explain to them what they do wrong and how to fix it. Normally this will be the last time that the TA has this student come in for office hours. More often than not a TA will see the same students coming in time-and-time-again saying that their program is not working and they have no clue why. The TA will have to read through all of the source code (or run it and see what is happening) to find what "looks" wrong. The TA will then either fix the issue for them and/or try to teach the student the solution to the problem. I normally did the later, I'd rather teach a person to fish than fish for the person.

Given that the students that see the TA are normally not the cream-of-the-crop, TAs tend to acquire the point-of-view that most of the students are idiots. The problem with this point-of-view is that it is very selective, the sampling is not repersentive of the whole.