Frame Switching and What Not

    6 minutes read | 1245 words by Ruben Berenguel

Two weeks ago it was the beginning of this years lectures. Currently I’m solving problems in the blackboard, 2 hours per week and take care of one computer lab (programming in C, but they have already done a C programming course and another course of numerical computations with C), all for our Numerical Analysis course (7th semester). This is the same schedule I had 3 years ago, also last year I had one computer lab each semester. I hate it.

What’s the problem, you may think? The problem, my friend, is frame switching (more on this later, let me rant a little first). In this computer lab we have 2 big assignments split in smaller pieces (like coding a LU decomposition, implementing a Runge-Kutta integrator), all to be done individually. This results in lots of questions from students. And now comes the frame switching, when a student just rings your bell and asks Do you have 10 spare minutes?. I used to concede. No more.

Questions from students are not bad. It is what they are supposed to do when they don’t understand something. The problem usually is the amount of previous thinking they do. There are people who just were the code does not compile and I don’t know why. Keep in mind that these are not first year students. They have already coded in two previous courses. My answer could be summarised as The compiler writes things on the screen, read, only in a more tactful way. Luckily this question stopped appearing, but another one is pervasive in this course My code just did a segmentation fault and I don’t know why.

If you have done any amount of C programming, you know that a segmentation fault can be a nightmare to find (without the proper tools, of course). Our usual approach was to just printf all over the place (remember that we are there to teach mathematics, not computer science…) until we find which value goes out of range. I got fed up of this method and started to use GDB. And last year we started using valgrind (a life saver!) and we gave our students a small example to see how it worked. With valgrind you can find segmentation faults in less than 10 minutes. At most.

But they still don’t get it. I had one student send me an email the other day (she was not even in my class!), sending me her code and asking whether I was able to find where it seg-faulted, because she could not. It was a rar file, hinting at using Windows. I answered her email suggesting to either use valgrind (not available in Windows, but coding for this classes is supposed to be done in a Linux system), fill the code with printf’s or just read the code carefully (and asking her teacher, not me, but that is another story). Then, out of curiosity I opened the code. I didn’t even need to compile. She was using an index without proper initialisation in the 5th line of the algorithm. WTF?

And now we can come again to frame switching. When a student comes asking for just 10 minutes, you are usually doing task X. This task X started 1 hour earlier and you plan on finishing in around 30 minutes (be it a proof of a theorem or just TeXing some stuff). The student comes, and you have to listen to the question. Then you switch from your theorem-prover mode to your C-checker. You open the file. Compile, run valgrind, find where the index m should be a n. Answer so, the student does not get it, you explain it again. The student goes happily without ever doing anything to solve his own problem (they have the tools and the wits, they just don’t care). Now you have to come back to your problem, 20 minutes later, because usually these just 10 minutes grow to 20.

How have I solved the frame switching? My solutions are far from optimal. Roy van Rijn wrote a nice overview of his almost perfect solution in his blog (read it here). Mine is just a hack.

  1. Have just one hour of questions. By University requirements we need to have at least one hour of presence in our office, to allow students to come by and ask. The first step is to have an hour and just an hour. When the hour is over the questions are over. Even better if you have to go somewhere when it ends.
  2. No random appointments. If someone drops an email asking for an appointment to ask just a question, answer No. And then ask them to write the question down in an email.
  3. No random questions. If someone drops by asking for 10 minutes, answer No. If they ask when you will be available, make it as long as you can (which usually is true), and get them to send questions by email.
  4. No code. I won’t look code unless it is extremely necessary. If someone drops by in my scheduled time and has tried her best to find her error – i.e. if she has a clear written overview of how the algorithm works, how her code works, has checked previous functions, is not leaking memory and so on – then I will have a look at her code.

Why should this work to stop this time and concentration bleeding? Let’s see it point by point

  1. Parkinson’s law says that a task will grow to fill any time available. And student questions are no different. Make them come with a well thought question. Get them to do some work.
  2. 9 out of 10 questions can be solved in a 5 minutes written answer, whenever you feel like you have the time. Also, putting the question in writing usually means they have to think it over. Then they can solve the problem and don’t send the email. If they do, then they can read my answer over and over until they understand what I tried to say (yes, some stuff is better explained in a blackboard, but…).
  3. This is what I most want to avoid, saying No is then the best answer. Then it goes back to point 2.
  4. There is a breed of students that think that learning is an osmotic process. They just sit, the teacher solves stuff and they learn by Sponge Bob’s magic. Unless you fight with your code, you won’t be able to do it alone.

And this is how I’m avoiding frame switching in this aspect of my life. Other aspects of frame switching are a little harder, but usually easier to cope with.

  • My office mate only asks questions or starts chatting when she sees me idling.
  • My advisor passing by usually means talking about what I am currently doing.
  • Someone from the department asking a quick question could have a delayed answer, but usually does not take more than 5 minutes and by giving an answer I can come back when I need my own answers.

Related posts:

Natural Productivity Ebook Review: the ADD Productivity System in Depth

Book Review: The War of Art, by Steven Pressfield (highly recommended book)

Personal Development for Smart People: a Not So Short Review

Luck favours the procrastinator (guest post in The Friendly Anarchist)

Time boxing: you will work like never before

Winning Against Your Reading List

Book review: How to be #1, by Vince Lombardi ParseList(ScrambleList(Relateds(Productivity)),4)