How to be disastrous at programming

by Adim Ofunne

Chess is my favorite board game of all time! Growing up I played a lot of Chess. From time to time, all that thinking gets a bit tiring and sometimes I just want to play the game but in a different way. Suicide Chess is my favorite Chess variant. The aim of the game is to suck! To win, you have to lose all your pieces before your opponent does. The rule of the game is that your opponent MUST capture any piece that is in their path. What I find stimulating about this game is that to succeed, you need to strategize, which is interesting when you think about it... because the aim of the game is to lose. Why would you have to strategize to lose?

In life, we spend a lot of time measuring how far away we are from being perfect at a skill and never take the time to measure how far away we are from actually sucking at that skill. It actually takes some effort to truly suck at something. So this is a post about how to write terrible code. Hopefully, by the end of this, you can tell how far away you are from sucking at coding but if everything applies to you... now you know what you are doing right.

  • Give your variables cryptic names. This is similar to mislabelling the condiments and spices in your kitchen. It should yield some interesting dishes.

  • Never format your code. If the code works, why does it need to look pretty? It is gonna get compiled anyway!

  • Do not account for edge cases in your code. This will make your program fool proof, why would you want fools using your software?

  • Do not use version control. Using systems like git will back up your code and every version of it there was in the past. Only cowardly people have insurance.

  • Never comment your code. You know what you wrote, and if someone is trying to edit your code and cannot understand it. They are not 31337 enough to be touching your code anyways.

  • Do not use a code editor. That stuff shows your code in bright colors... what are you... in kindergarten?

  • Copy and paste as much code as you can. This is the best feature from the digital age, use it with abandon.

  • Never architect your code. Move fast and break things! That is what facebook said we should do, look at where they are today and then look at where you are.

  • Never listen to older programmers. Old dogs only know old tricks. You gotta stay bleeding edge.

  • Never test your code. Testing is for people that are insecure about their code.

  • Do all your changes in production. If something is wrong and needs to be changed, or hell you just want to add a new feature just do it LIVE.

  • No Code reviews. You should always be moving forward and never dwell on the past... besides the code is already live!