Attaining a degree in computer science is not an easy task. It consists in equal parts of mastering theoretical knowledge and honing your practical skills through solving problems that become progressively harder as you move through the college program.
So maybe one day you decide that you’ve had enough. You want a way out of this misery, and for some mysterious reason, changing your major or dropping out of college as a responsible adult is not an option. Then your choice is failing assignment after assignment until they get sick of your face and kick you out. That’s a valid way out of getting a degree, and if it suits you, read my no-hassle 10-step guide on failing your coding homework.
Leave it till the last minute
Here is a pearl of wisdom from your auntie E. If I have to submit my essay in three months’ time, it doesn’t mean I have three months to write my paper. Oh, no. I have a couple of all-nighters, a week – tops. Three months are for living like tomorrow doesn’t exist. What am I? Some neurotic overthinker or what? Same with coding!
You will be able to ace this assignment in one night, so why bother? Enjoy your life as the free spirit that you are. When the deadline comes – then it’s time to spring into action and dazzle everyone with your inspired last-minute dash. Until then, just forget all about this assignment. You know what? Don’t even waste your time reading this article through. Just go and enjoy yourself, chop-chop.
Planning is overrated
Since you are going to do it in a couple of nights anyway, you don’t need to map out the timeline, set milestones, carefully choose the most fitting programming language or the tools you will use. Python-shmython… who cares? The assignment details probably prescribe these things arbitrarily anyway, so you will just do as it says.
Oh, it doesn’t specify anything and gives you the freedom to choose the language? Well, isn’t it typical? One time you actually read it was for nothing. You just have to make a wild stab in the dark and hope for the best. YOLO, amirite?
Don’t study other people’s code
You are not some voyeur to go online and look at other peoples’ codes, ugh! I mean, Github has “git” in the name for a reason. Don’t go there. Don’t research if someone has already done a similar program, don’t analyze their solution.
You can never improve your code by reading what others have written. How can you develop your own unique style if you imitate? No, that’s not the way. You know what is? Sitting down and just letting your fingers fly over the keyboard like you are some divine-inspired Bach of bytes! That’s what they do in the movies anyways, so it has to be true, right?
Who needs READMEs anyway?
If by any chance you do go to GitHub or StackOverflow and find an open-source doc that might be of use to you, don’t bother to read the README file. Alice drank from the bottle labeled “Drink me!” A fat lot of good it did her. Ended in a bad trip – serves her right for doing everything that labels tell her to do. You are smarter than that. You know how to install and run the code base without some stupid files. You don’t need a file to tell you how to contribute instructions.
The same applies to writing READMEs. Just don’t. The Internet has enough rubbish floating around. Don’t contribute to this entropy.
Thinking is for losers
Thinking is just another word for doing nothing. You are a person of action. Just do it. Sit down and code like a pro. Don’t waste your time scribbling notes on a piece of paper – it’s pathetic. You are building a program, not writing a novel, FFS. Let the coke and code flow. No interruptions. Code on. Don’t stop to test anything. It will just break your concentration and throw you off track.
If an error message pops up, you just make a random change to the source code. If not, sort it out later when you finish writing the code.
Who reads error messages anyway?
While we are on the topic of error messages – don’t read them. It’s basically the computer talking to itself like a senile octogenarian, just leave it be. You are too busy coding to notice it anyway. You are a pro, remember? You know that it all will work out in the end. Your masterpiece is yet unfinished – that’s all. You are not some wet-behind-the-ears noob to be scared of errors. You are confident and laid-back, so there.
Remember the first rule of a productive programmer: if you ignore it, it will go away. Just keep churning out the code, line after line after line. That’s the only way to finish this godawful task.
Specifications are just a formality
I don’t say you must not read outlines and specifications. Take a peek if you are so curious – but just a quick one to get the gist of it. Don’t get into the details of those long-winded, tedious drivel. And most definitely, don’t reread it if you value your time. Tell you what: instructors don’t remember what they write there anyway – and nor will your clients when you code for a living. So don’t cultivate this bad habit of reading their fanciful wants and wishes. You are a pro here. You know better what can and what cannot be done.
If, for some reason, your instructor asks you why you didn’t follow the assignment, challenge them. Dare them to show you how you were supposed to follow this ridiculous requirement. You pay tuition to learn from them, right? Make them sweat to earn their salary.
Version control is for the weak
Version control is busy work they make people do in big companies for appearance’s sake. You don’t have to engage in these futile rites. You don’t have to review your code to ensure it meets some arbitrary standards. You won’t need to branch out for experiments – you know what you are doing. Why would you need to resurrect older versions of the codebase? It’s over and done with. Who needs backups, anyway? Coding cowboys like you don’t. Nothing can go wrong with your code!
Ultimately, version control is a thing they do for long-term maintenance. This assignment is a one-off thing that serves no other purpose than earning you a grade. It doesn’t have to really work, really. No one expects it to.
Compiling bit by bit is so last century
You are a professional, not an amateur, tiptoeing your way forward. Nah. You are good at what you do. You will compile it when you’re done writing code because you’ve cracked it. You are a computer whisperer. Machines know what you mean. They understand what you say. Strike that – they understand what you think.
Syntax errors? – What’s that? Bugs? – Don’t exist in your world. Compatibility with different hardware and software? – It works on your computer, that’s the important thing. If the app crashes on your instructor’s machine, that’s not your problem. Code optimization? – You can’t optimize what’s already perfect. Nuff said.
Grow up and just cheat
Ran into a problem? Here is what NOT to do. Don’t go to see your prof during office hours. Don’t email them. Don’t seek advice from professionals. Don’t order a sample solution. Just cheat. Copy pieces of code or even entire programs from all over the Internet or from your classmates. If it works, does it matter how you got here? It’s called “following the best practices” in the industry.
Your instructor will probably thank you for this. After all, familiarity is comforting and welcome when they have to grade dozens of assignments. If, for some reason, they disapprove and point plagiarism out, deny everything. Act insulted. Take them to court, if necessary, but never cave in.
And that, my friend, is how you set yourself for disaster. I hope you appreciate the sarcasm and can reverse-engineer your way into nailing your assignment instead of failing it from these tips. Don’t forget that you can always ask our experts for help if the task seems uncrackable. Stay curious and love coding!
