Archive for the ‘tutoring’ Category

Why tutoring PHP is painful

Tuesday, May 6th, 2008

del.icio.us Reddit Slashdot Digg Facebook StumbleUpon

Alright, here comes a rant. Sorry about this, but tutoring a student in PHP is painful. In fact, it’s not just PHP, but I am using PHP as an example.

Don’t get me wrong, I love PHP, but there is a single reason why tutoring people in it is so hard. The people.

People can need help with various technologies, and that’s fine. In fact, I really adore helping someone that knows how to program with a small problem. The problem with PHP is, most of the people that require assistance, don’t know how to program.

Setting people up for failure

PHP is used in the multimedia / web realm here at RIT. Sure, it’s used in database as well, but I rarely get asked for assistance from database students on how to use PHP, and when I do, it is more of a technical issue. The problem is, most students that focus in multimedia / web are not programmers. In the Information Technology program at RIT, you are required to take 3 courses in Java. Once you complete these courses, it is relatively easy to avoid programming in most of your courses for the rest of your tenure here. Students that did poorly in Java tend to go towards multimedia / web because it is easy. You can get away with almost no programming (writing HTML is not programming), and you are not forced to push yourself constantly when it comes to programming.

Enter PHP. As students hit the mid level courses, after trying to avoid programming for a long time, they have a new paradigm, stateless programming. Each time you post to a page, you lose all the data from the last page (unless you pass it along through POST or GET). Students struggle. Constantly, I have to work through basic programming concepts, and these frustrations are made worse by the lack of understanding of the state problem. Combine these weaknesses with a grasp of simple programming with the introduction of a database (which happens in some mid-level courses) only having phpMyAdmin as a guide, and students begin to drop like flies.

What is the problem?

Students pass the initial Java courses, and they are expected to be programmers. Unfortunately they aren’t. In fact, I know first hand that many students that finish the last course in Java couldn’t program anything remotely complicated if they were required to. Beyond this, with a weak foundation, they can not easily grasp another language. They never learned what makes a good programmer, and spend most of their time shotgunning their way through. Professors in later courses never cover the foundations again, and students get lost.

How do we solve it?

I suppose if I had a say, the Information Technology department would be much smaller. What it really comes down to is, students should be flunked in the early Java classes if they are not solid programmers. Yes, it’s a mean thing to say, but if you can not be solid at the core concepts, you are going to be struggling for the rest of your career. Programming is a major part of Information Technology. I will make a claim now that goes against what many of the “higher ups” in the department think, and what they would hate for me to say…

If you can not program, you will not be successful.

I admit, there are likely some people that couldn’t program their way out of a paper bag that are successful in the IT industry, but this is rare, and partly dependent on the definition of ’success’. Someone that gets a job isn’t necessarily successful (my definition may differ from others on this point). However, someone that can be innovative and inventive in the industry is what I would consider to be successful, and frankly, I can not see someone that can meet my criteria for success in IT without being at least a ‘decent’ programmer.

Whole rant aside, I want to make it clear that just because someone is in the IT program here at RIT, and focusing in multimedia / web, it doesn’t make them a slacker or bad at programming, because the concentration is, as with life, what you make of it.

Crunch Time

Monday, February 4th, 2008

del.icio.us Reddit Slashdot Digg Facebook StumbleUpon

I have been going to RIT for a while. Grad school is still fairly new to me, and it really has been the first time I have been challenged. The work isn’t particularly hard, but the most difficult part is the intense amount of work expected. Throw in the 20 hours of tutoring and teaching I do, and I start running out of time fast.

What does this mean? It means that I spent last night’s exciting superbowl in my living room with my laptop coding (although, to be fair, I was pretty much only paying attention to football by the 4th quarter). I was hoping to draw a comic last night after the game, but since I was experiencing a delightful bug with glassfish, I was unable to get to it. This is a direct side effect of “crunch time”.

Weekends are assumed to be spent in the labs now, be it for tutoring or to try to get my projects done. I knew this coming in, but it starts to get worse and worse as the quarter ends. Since RIT has 10 week quarters, when the crunch starts to come, the best students are the ones that are adept at the art of triage. Which assignment is worth most? Which assignment has the closest due date? How much will not doing this assignment hurt me? These are not good questions to have to ask, but in a student-academic setting it happens a lot.

(several paragraph rant on homework assignments deleted, perhaps I will write an post on it another day)

So, it is crunch time here at RIT. You can see it in the eyes of the students, you can start to hear the sense of urgency in their voices. General grumpiness levels are up due to lack of sleep, and labs are starting to get more and more crowded as the final weeks tick away. Not much can be done to prevent the inevitable, but some thing can be done to keep yourself sane.

  1. Set aside 30-60 minutes a day to have fun
  2. Have one fun thing to do a week that takes up a little bit of time (usually Friday or Saturday night)
  3. Smile, at least a little.

Making sure that you get to at least spend a little bit of time a day to do something fun (be it playing pool, playing a video game, watching TV, or hanging out with a friend for a meal) is vital to keep yourself from burning out, and burn out is the worst thing that can happen here. Shutting down at the worst possible moment, the last week of the quarter, is what needs to be avoided at all costs. So, grab that cup of coffee with a friend, let your brain reset before getting back to work.

Do at least one big thing that is fun a week. If it is going to a party on Friday night, or maybe going out bowling with friends, it is what you have to use to drive yourself to make it through the week. Think of it as the reward for accomplishing the work you have been doing all week. Make sure you don’t get too crazy, because I know programming with a hangover sucks, but make sure you relax.

Smile. Please Smile. This is the toughest one for me. Despite the scientific proof that smiling is actually good for you, this is just as much about keeping everyone around you from getting more and more down. Seeing someone smile is… rare… here at RIT. Try to make the last few weeks of the quarter as painless as possible for yourself and everyone around you - if you smile, it adds that little bit of happiness to the environment you are in… and if enough people do it, maybe the end of the quarter will just be busy and stressful, but not depressing and painful.

Shotgun Debugging

Sunday, January 27th, 2008

del.icio.us Reddit Slashdot Digg Facebook StumbleUpon

One of the most painful things I experience with the students I tutor is the practice of Shotgun Debugging. The practice will generally give the student horrible, unreadable code. After today’s tutoring, I determined it was time to write about some common debugging practices. So, here are the things I tell my students every week - and they quickly forget.

Only change one thing at a time.

This one is hard for beginning programmers. They get a logic error (or sometimes even a compile error) and then change 5-6 things in their code before they try again. If the changes work, they have no idea why, and will change 5-6 things next time they get a similar error. Which leads me to the next point:

Learn what the common errors mean.

….and how to fix them. When you get the error in Java for “cannot find symbol”, what does that really mean? Look at the text associated with it! It will tell you if it doesn’t understand the class you are looking for, or the variable, or even the method. Got a “null pointer”? That really does mean that something you are referencing is null! The JVM does not lie! Sure, some errors are a little more complicated, for those:

Actually read the error.

The biggest problem I see with students is they simply do not understand the code that they are working with. Reading the errors and understanding what is actually happening when you manipulate a line or two of code is the first step in becoming a better programmer. Every good programmer has spent a significant amount of their time learning how to debug, not just how to code. Lastly, I find myself telling my students:

Make sure you catch every instance of the error.

Let’s face it. We try to teach reusable, generic code, but it just doesn’t happen. I have learned to accept that some students are just going to copy and paste branches of code, over, and over, and over again. So, if you must do this, when you realize there is a logic error in the branch you copied, it will exist in every branch… no matter how much you think you “just fixed it”.

Sometimes tutoring can be very frustrating, but I really do enjoy the moment when a student finally has it click. I suppose there is nothing I can do sometimes, because some students just really hate code, but I hope that they can at least take a little bit back from what I help them with.

Holy Classwork, Batman!

Wednesday, December 5th, 2007

del.icio.us Reddit Slashdot Digg Facebook StumbleUpon

Wow.

It’s only been a couple days, but I am already feeling the heat from classes again. Generally speaking, each class isn’t too bad from a coursework perspective (except project management, which is my first, and likely last, online class). However, the problem I have is I have a lot more on my plate then I really should. Working as a Tutor, TA, Lab Instructor is 20 hours of work. Add to this, the ‘16 hours’ I am supposed to dedicate to each graduate course (taken from my project management syllabus), times 3 courses, will give me 48 hours of coursework. Add to this, I need to finish my independent study which will take… many… hours of work, but for the sake of doing fun math, lets assume it will be 8 hours a week. 76 hours a week is what I am ‘expected’ to perform. Lets not even talk about my side projects!

That’s not that bad. Right?

Tutoring Hours

Tuesday, November 20th, 2007

del.icio.us Reddit Slashdot Digg Facebook StumbleUpon

I figured I would throw this up while I still remembered. The other day I used the spiffy tool at Crappy Graphs! to make a graphical representation of how I feel about my tutoring hours sometimes. Here it is :)

Tutoring Hours

The best part was when I made it my facebook profile picture.