How to Fail your Assessed Course Work

/
sunset 006.jpg

First a note. We don’t have many people that actually do fail their coursework (although, years ago I did manage it by using a variant of this technique involving punched cards). But over the years I’ve seen enough of these to be able to produce a comprehensive guide. This is the sequence that I have found works very well when it comes to failing a software development project. Just follow this fool proof set of instructions for guaranteed failure.

  • T-minus 8 weeks: Assignment distributed. Decide to ignore it for now. Put on desk.
  • T-minus 4 weeks: Happen to find assignment under pile of dirty socks. Take a quick look. Seems easy enough. Decide to do it later.
  • T-minus 2 weeks: Find the assignment again and experience a mild twinge of panic when you look at the submission date. But no time to do it because other coursework is due in now.
  • T-minus 1 week: Decide to complete entire program by performing herculean development effort over the coming weekend. Feel much better. Go to pub to celebrate.
  • T-minus 2 days: Fire up Visual Studio and write 300 lines of code in one sitting. Which won’t compile. And actually you’ve no idea what it does. Stay up until 2:00am trying different combinations. Ask a chum who has just come back from the pub to take a look. He suggests adding a bunch of curly brackets and semi-colons. Code now compiles and runs. But you still have no idea what it does. Fall asleep at desk and wake up after six hours with key shaped bumps in your cheek.
  • T-minus 1 day: Program now fails to compile again after you pasted in some code that you found on the internet that looked like it might do what you want. Decide to seek help. Post a plea for help in a question on Stack Overflow.
  • T-minus 12 hours: Check Stack Overflow for answers. “SuperDev99” thinks you should use recursion. “P-Guy” thinks you should really use Python. “Troll95” posts that all C# developers are ugly and stupid.
  • T-minus 6 hours: Having had no sleep for 20 hours you decide to re-write the entire system from scratch. It seems like the only way. You write another 300 lines of code. That won’t compile.
  • T-minus 1 hour: Program now compiles, but it is alternating between crashing instantly and causing the computer to lock up. Check Stack Overflow again. Find that someone has posted a complete solution to your problem. In Prolog.
  • T-minus 10 minutes: Submit program that compiles, runs and prints “Sorry about this” in large friendly letters on the screen. Oh well. There’s always the resits.

Now, of course, nobody actually does all of this. Although I’ve managed most of these tricks at one time or another. Please, please, if you get some coursework, frontload it. Have a crack at the code as soon as you receive the specification and then play with it in the run up to the due date. You don’t have to write all the code at once (in fact this is a bad plan) but you should keep noodling along with the system over the weeks leading up to the hand in. And seek help if you hit problems.

The internet is often very useful, but beware of using downloaded code. Often you end up trying to use some code you don’t understand to solve a problem you don’t understand and getting errors that, wait for it, you don’t understand. Much easier to take your problems down to the lab or to the person in charge of the coursework and get them to help. If you want to post questions, use the forum or departmental Facebook group. At least the folks there will have an inkling of what you are doing and why.

By the end of my university career I was getting reasonable marks for coursework, and this was mainly down to a “starting early” technique.