WRITE BAD CODE: 1001 WAYS

The WAYS

1. Spend 12-14 hours on intensive coding learning per day for a few weeks without any proper time management. Then burn out, and develop the (in)ability to think or function in day to day life.
2. Forget that you need to properly link your html, css, and script files and spend a few hours raging that nothing is working.
3. Do basically the same thing but with a twist: neglect to properly understand how a page loads so you can invest an hour of mounting shame and rage that your query selectors aren't selecting even though you KNOW the code is right only to think that maybe, just maybe, the script in your header is trying to select html elements that don't exist yet, thus resulting in null values. So you spend 3 seconds to type `defer` and voila! it's fixed and you laugh and move on.
4. Spend far more time watching other people code than coding yourself. This has the added benefit of not actually producing code, which we all no is the best bad code you can write.
5. Skim through every amazing free piece of information that you can find about computers and coding without any intention to understand. Avoid being attentive and focused while reading.
6. Spend zero time trying to learn about the essence of computers and their bits.
7. Read as many headlines as you can about how the tech market is in the trash/tank/toots.
8. Panic. Like all the time. Panic about every little thing that doesn't go your way. Panic about all the time you've wasted not coding. Panic about how much you don't understand but spend zero time on trying to understand. Just panic.
9. Save resources for later rather than learning from them now.
10. Worry more about how old your computer is and how that will TOTALLY hold you back, than on how your code is organized.
11. Always assume you know more than the computer and that you are always right. (this one goes a very long way)
12. Alternatively, always assume the computer is wrong.
13. Specifically alternatively, believe in your bones that error messages are there to anger you ad insult your great intelligence, not help guide you to a solution.
14. Never stop learning as fast as possible. Actually, faster than possible. Make sure to blast through every new concept like it's a meatball sub and you've just run a marathon. Just go through everything only once, just to give yourself the feeling of learning, but virtually garunteeing you'll never retain anything, and ideally confuse other concepts creating a disorganized soup of misinformation in your mind that resembles a blob fish but chunkier.
15. And as you power through every article and tutorial and video, make sure you do not under any circumstance code along! If you actually type things you run the risk of teaching your hands. You do not want this! Smart hands are an invaluable tool for programmers. You only want hands that can scroll through feeds and tutorials as fast as possible, not instantiate objects.
16. However, as you "progress' as a developer you'll be presented with new tools. Often you will find helpful tutorials that involve coding along. If this cannot be avoided, you are advised to simply pass the code like a hot potato from the tutorial to your text editor, never slowing down enough to understand how your code is working or why. Just type what you see. As long as it produces an outcome that matches the tutorial, you can feel accomplished and move on.
17. Assume that if you could just write better code, then the world would be a better place. People wouldn't go hungry, ecosystems wouldn't be collapsing, the lumps in your mother's chest will come back benign. Forget the outside world. Believe that code is the way, the truth, and the light. And for 4ucks sake, stop making everything political. Just focus on the syntax and semantics and everything will be fine. All there every was and all there will every be is cold, hard, code.
18. Make sure you always make things as complicated as possible for yourself, especially as you're learning. There is nothing more effective in writing bad code than to create problems for yourself. Bonus points if you can create problems in an effort to make things easier for yourself. At that point, you'll notice yourself reaching new heights of bad in the quality of code you write.
19. Listen to as many people as you can who are willing to give you advice about how to code and what to think while coding and what tools to use and how to use them and what you shouldn't do and just in general how to live. Then, while you are saturating your mind with other people's opinions, never spend enough time with any one way of doing things long enough to figure out if it works for you. Just jump from one person's opinion to the next. This should leave you utterly confused and completely lost. Which, as you'll find out, it the best mental state to be in to write bad code. You're welcome.
20. Spend more time thinking about what you would do, rather than on what you have done. In other words, optimize for things you haven't done, rather than for things you have done. That way, your code and your life will feel completely out of your control. This is highly effective in draining your creative capacities. It will also mean that you will not have much to offer others when asked for your input on any decision or situation. This is because you'll only have experience thinking about what you could do, and have zero experience to draw from regarding what you have done. A nice bonus feature of this is that you'll have sidestepped any feelings of failure, which as all experienced bad coders know, is the worst thing that could ever happen, ever. Period. Ever.
21. Always approach coding as a chore. As something you're required to do. Never, under any circumstances should you allow yourself to think that it's a privilege to code. Never think about how fortunate you are to be able to do such an amazing thing.
22. Don't give up on ideas. Treat every idea like it's a perfect, precious gem that you must horde and hold onto for all eternity. As a wise bad coder once said, "no idea is better than the one you just had". So make absolute sure that you run with it. Spend no time interrogating your idea, or even exploring off-shoots. Snuff out any tangential idea that springs forth from this idea. That is only going to confuse things. And not in a good way.
23. Avoid consequences in your learning. When applying something that you have learned to a real life scenario, make sure that there are zero consequences. Construct a perfectly safe environment where if you were wrong in your understanding, it's totally fine. You should never be faced with any consequences for implementing your understanding incorrectly, or understanding incorrectly in the first place. Construct an environment where you risk no loss of time, energy, and resources if you're incorrect in your understanding and implementation. There should be no risk in your learning. Any application of something you've learned should not manifest itself in the real world. It should all exist as some exercise, or experiment, or some project without material impacts on the world. In a word, avoid any sense of responsibility or real pressures from applying something new.
24. Make sure you are always in the mindset of "getting things right" rather than "solving the right problem" or "solving problems at all". Staying focused on trying to do the right thing is a perfect distraction. It all but garuntees you'll spend so much effort worrying about if your thing is correct or not, that you'll have no space to actually finish things. Finishing things is antithetical to writing bad code.
25. When people tell you "programming is solving problems", believe it. And then also believe that problems are bad, painful things, not opportunities for generative creative exploration.
26. Always assume that any code you write can never be deleted. So always know exactly what you are doing and what the next 7 steps are. Actually, if you don't have the whole project mapped out perfectly and with every edgecase accounted for straight out of the gait, don't bother.
27. Always always always make sure you have an empty inbox, no notifications, clean dishes, lint free clothes, dust free light bulbs, the latest tech, and optimized hydration before attempting any coding. It just makes sense.
28. Don't read any of that "good" code you hear about all the time. You're brain is clever in so far as it can't help but learn. So don't risk reading code that might teach you something. The less code you read from other people, the less opportunity you'll have to learn new ways of doing things. Which is good. You want to create a information environment that's completely closed and self-referential. Ideally, you want no new information coming in. Just the same bad ideas being kicked around, forgotten, and pick up again like new. Remember, the path to Bad Code is paved with the same bad ideas you forgot you had. Just packaged like new.
29. Draw this on your mirror and say it with me every morning, "I will not learn how to solve problems". Good. It is absolutely imperative that coding never becomes a creative problem solving game for you. Make sure your focus is fixed on the essentials: typing fast, being busy, and waving people away when they ask what you're up to. By definition, Bad Code does not solve any problems or manifest any coherent ideas. It should be a reflection of the disorganized mind and entitled power hungry spirit you've been cultivating.
30. The time spent on solving a problem is directly proportional to how important that problem is. Another way to put it is, the more time you spend coming up with a solution to something, the better that solution will be. Guaranteed. Period. Bonus points for a Complicated Solution. The importance of the problem is increased exponentially based on how complex it is to understand. Difficult ideas are inherently better than simple one. It's just science.
31. The best way to write Bad Code is to always seek worse questions. Make sure your questions get more and more superficial until eventually, if you're persistent, all you can learn from asking your questions are the bad opinions of others which are entirely based on the bad opinions others who get their bad opinions from the bad questions they ask. (something about shoulders and giants...idunno) Here's an example, let's say you want to know how the Web Storage API works. DO NOT under any circumstances ask, "how does local storage work?". NO! BAD BAD CODER!! You want to come at it like this. Here's the scenario: You've been hired to build a custom hybrid CMS-foodblog-mortgage-payment-notetaking app for $12 per hour by a client. And the client demands that the big like button in the bottom middle of the app be bigger. But you don't want to make the big like button bigger because then your really big like button wouldn't be the really big like button anymore, it would just be the other really big like button. And the chain reaction of that would alter your public API so much so that NASA would crash their satellites into the Moon causing it to alter it's course by 14 mm which would shift sea levels enough to swallow Nova Scotia, which is a dam shame because you hear it's nice country up there and you've been wanting to go but your passport is expired. So instead of all that hullabaloo, you need to ask a question like this, "So my parents are coming to town this weekend and I'm new here. Do you know any good sushi places near by? I've been craving a California roll for like a month!!! I really like them cause they're not too fishy."" You see? A much better bad question. And with that you'll be writing Bad Code like a champ.