It’s week five of edX’s 6.00x: MIT’s Intro to Computer Science MOOC. I’ll give a review when the course is finished, but in the meantime I wanted to provide two interim tidbits.
The first: co-creator of the Ethernet protocol and founder of 3Com Robert Metcalfe is taking the course along with his son. He tweeted the following:
Son Max, I, ~50K taking MIT “Introduction to Computer Science and Programming” (6.00x<MITx<edX) for free. Expect 5K-10K to finish.
— Bob Metcalfe (@BobMetcalfe) March 2, 2013
The number Metcalfe cited came from one of the professors of the course, who predicted that 5,000-10,000 students would finish it. However, the completion rate sounds awfully high in the wake of a flub Monday night.
Which brings me to my second tidbit: weekly homework is due at 10 p.m. Eastern. The homework is code-checked by an automated grader two weeks after the assignment is given. The assignment was to code a function that would simulate a hangman game.
With nine minutes until the deadline, so many students submitted responses at the eleventh hour that the grading servers crashed. Now, how many people do you think found their inner programming Michael Jordan and were going to hit the last minute shot? Or how many had just given up and were grabbing code online somewhere as the clock ran out?
Just procrastinating? Or cheating? Or did MIT have weak servers? The class is very thorough and the problems are meaningful, so it will be interesting to see how they address this issue in the future.
Full email text, sent from the 600.x course team at edX on Tuesday morning, follows:
Dear Richard Kain,
Last night around 21:51 EST, the grading servers for 6.00x code response questions went down. This happened primarily because there was a sudden surge of submissions, far more than we’ve ever received in the course, which caused our servers to overload.
We are disappointed that this occurred. Problem Set 3 was released for two weeks; waiting until 10 minutes before the due date to submit is a common but potentially unsustainable learning strategy.
On future problem sets, we strongly suggest that you carefully plan your time. Give yourself at least a few extra hours – if not a few extra days – to finish up the problem sets. Understand that many things can go wrong, on both your end and our end, such as internet outages and grader outages. The safest policy is to make sure your problem set is fully completed a day or two before the due date.
That said, we will extend the due date for Problem Set 3 by 24 hours. You now have until Wednesday, March 6th at 2:00 PM (14:00) Boston time to submit Problem Set 3. We do this in hopes that you will plan to do your part by working ahead to avoid overloading our grading servers in the future. We’ll leave you with these paragraphs from the Week 4 Reading Notes. Be sure you are following this advice:
Guess and check is an interesting strategy but it must be used wisely and in the right places. As soon as you write a function, test it. When you finish coding up a problem set, test it with your own data. Then use the test cases we provide. All this testing should be done on your own computer.
Once you believe your is correct, then paste it in the box and have our servers check it. You will not learn to code by simply guessing what might be correct and seeing if it is right. That is not what we mean by guess and check. Thinking through the problem fully, and testing things out on your own computer, is the best way to learn.
We have noticed that many students are abusing the large number of checks we give you on problem set problems, which makes us worry that many of you are trying the guess-and-check approach to coding. Note that we provide 30 checks per problem because we understand that there are numerous things that can go wrong: poor or intermittent internet connections, temporary overloaded servers, copy-paste indentation errors, or some other random issue. We assume that no more than 3 checks should be needed for any given coding problem, because we expect our students to be running their code locally, testing and debugging as just described. To be safe, and to account for the aformentioned issues, we multiply that by 10.- Larry and the 6.00x Course Team