12 Simple Steps to be Miserable(Parody)

I came across this funny video https://www.youtube.com/watch?v=xtTTENvS5F4(12 simple steps to be miserable, by Nathaniel Drew) and I liked it so much that I decided to make my own version/parody of it because that video was a good reminder for me to not be so hard on myself and not take life so seriously.

I had this programming project for school that I found very challenging, and I kept getting bugs. A fresh chance to panic, overthink everything and make every possible mistake. Being happy and learning something new is just to hard, too confusing, not worth it. Instead, take the easy route and follow these simple steps to be miserable.

• Step 1: Let impatience dictate how you feel
 Focus only on visible results and do NOT test your code at regular intervals so that when you run into problems it becomes impossible to trace it back to its root cause.


• Step 2: Do not face the problem
 Try closing your eyes tightly and just recompile a 100 times in the hopes that the problem just resolves itself instead of facing it in any way.


• Step 3: Dont test the dummy scenario
 Assume the problem is not just a typo or you misunderstanding how the algorithm is supposed to work. Always assume it is a very difficult problem to solve and never test the validity of this assumption.


• Step 4: Judge yourself harshly for your lack of experience doing this new thing even though the only way to gain experience is by doing it
  You must be stupid for having even taken this class and tried this project in the first place. What were you thinking, in the future only ever try things that you know for certain will work out on the first try.


• Step 5: Give up before even trying
 Trying anything could potentially break the computer so its best if you just give up right here and never write a single line of code ever again. Or even better never touch a computer ever again in your life because you are clearly not a tech person.


• Step 6: Give yourself really tight deadlines allowing for no margin of error
 When you inevitably realize that never touching a computer again is going to be even more miserable(wait isnt that what we're trying to achive? :) ) you proceed by reminding yourself of all the other things you have to get done today and that it is absolutely critical for you to have this problem resolved within less then 5min.


• Step 7: Expend as much energy as possible worrying
  Once the 5min are up tell yourself that it's the end of the world and that you will never manage even if you gave yourself infinite time. Also think about all possible consequences of not finishing the project.


• Step 8: Crumble internally
 You must hold yourself to the impossible standard of knowing what you were supposed to do while never having done any of this before.


• Step 9: Dont ask for help
 No one has ever had the problem you are facing, so there is no point in seeking help cus no one will know the solution anyway.


• Step 10: Expect solutions to come out of a vacuum
Dont look at what others on the internet have done and if you do make sure to copy their code without having any clue of how it works and get extremely frustrated if it does not work first try in your implementation.


• Step 11: Get stuck in a loop of trying the same thing over and over again
 Once you have downloaded lots of libraries where you have no idea what they really do. Copy the implementation of how to call and use this library. If this does not work go to the next website and do the same thing. Dont question the possibility that the library you are using might not do what you want it to do.


• Step 12: Never take any breaks and chase the result only, operating entirely out of fear of not getting the result you want
 It is at this point however that I decided to stop following this goddam list as I realized that enjoying the process is important no matter how tight of a deadline I have.
I threw my school stuff into the corner and went outside and enjoyed myself for the rest of the day. And amazingly enough the next day I actually wanted to program again and things went much smoother. I fixed the bugs and got the program to work.
Although this 12 step plan on how to be miserable is perfect and guaranteed to succeed, I'm really happy I messed up on this final step.
Its funny how when you think you have no time for breaks, thats exactly when you need to take a break.

A Few Problem Solving Tips

Coding is 90% debugging, 7% copying code, 2% thinking about the algorithm and 1% writing code.
In the second book of "the hitchhiker's guide to the galaxy" Zaphord Beeblebrox the ex-president of the galaxy has Peril Sensitive Sunglasses that are "specially designed to help people develop a relaxed attitude to danger. At the first hint of trouble they turn totally black and thus prevent you from seeing anything that might alarm you."(page 34). Now it is obvious that these glasses are the opposite of helpful, but I like this idea because it is a great analogy to how we sometimes act when we are afraid of solving the problem at hand.
Problem solving is hard because there is no systematic approach, every problem is different. However, in general there are some things you can do to put the odds of solving the problem in your favor.
My problem solving skills will always be a work in progress but here is a list in no particular order of some tips and tricks to make the process a little bit easier.

Coding

• Save your code at different stages so that if you want to restart because you have to many errors you can go back to the previous check point, the previous code version where things work instead of starting from scratch. This also allows to throw out code instead of commenting it out, which can create more comments then code, making the code unreadable. If you do need the code back you just go back to the previous version.


• When a bug occurs, put lots of sprint(oops, i meant print lol :) ) statements into your code or comment out everything except a few sections. This allows to narrow down where the root of the problem is. If you are programming in C or C++ you can use a macro so that you can keep your print statements for future debugging without displaying them all the time. Ex:
  
  //to compile: g++ -Wall -o outputname filename.cpp //to run: ./outputname #include <iostream> #include <string> using namespace std; #define dbg(str) (cout << "dbg " << str << endl)//debuging on //#define dbg(str) //debuging off int main(){ //code, code, more code int myvariable=0; dbg("myvariable " << myvariable); //code, code, more code return 0; }
  
  (Macros have the advantage that when you are not activating them they are not part of the compiled code. However, if you program in a different language where macros are not supported you can use an if statement instead. Here is an example for JavaScript:
  
  var debuging=false;//for debuging //code, code, more code if(debuging){console.log("myvariable ",myvariable);} //code, code, more code
  )


• Read your code line by line like a book, starting at the top. Does the logic make sense? Are the different blocks of code in the correct order? Any silly mistakes like if(x=1) instead of if(x==1)?


• If you code in a team then pass the code around. You work on it for a bit. Then when you get stuck you pass it to your teammate. Then they pass it back to you and so on.
  This is so freeing because while your teammate works on it, you dont need to worry about it.

Electric Circuits

• Does it have power?


• Use a voltmeter to measure voltage at spots in the circuit where you know from the circuit diagram what the voltage should be. This is like putting print statements in a code, it helps narrow down the location of the root of the problem.


• If a motor is not spinning then if it has been exposed to water it probably is rusty inside and needs oil.

Mechanical problem

• Carefully take it apart(take pictures or notes along the way so that you can put it back together again later.)
  Think about how things are moving or are supposed to move, what forces are involved, can something get stuck? If something broke, are the materials it is made out off suitable for this application?


• If gears or other moving parts are involved, oil is often a good idea.

Wood Carving

• Pivot if the initial idea does not work out. When carving you can only remove(ok you can glue stuff back on but it wont look the same) so if you are trying to make a cat and it ends up looking more like a race car then go with that instead, its art after all.

Relationships

• Communication

General

• Try things even if you think it wont work.
  (ex: You cant eat goldfish crackers with a fork right? Try it, if you stab them with the right speed and at the right spot you can pick them up.)


• Failure is an important part of the process.
  It sucks in the moment, but it needs to fail and break to give room for something better. The saying: "books are not written they are rewritten" applies to more than just books.

References

• https://www.youtube.com/watch?v=xtTTENvS5F4
-12 simple steps to be miserable, by Nathaniel Drew
• https://www.youtube.com/watch?v=BJ2NvjS7Aio
-Operate out of love not fear. If you chase the result only you operate out of fear of not getting the result you want. If you instead chase and enjoy the journey then it does not matter what the result is, you are not afraid of bad results.
• A book called "Momo", by Michael Ende
-A heartwarming story about the perception of time and the consequences of rushing and not taking the time to enjoy the little moments
• The books from the series "The Hitchhiker's Guide to the Galaxy" a triology of five, by Douglas Adams
A caricature of life and society but with a kernel of truth

Copyright © 2025, Jessica Socher ()