How to Write Bad Code
I’m sorry to say that I clickbaited you. You don’t need to learn how to write bad code. You already know it. It comes instinctively. You just go with the flow, and the result will be a mess. Guaranteed.
The One Man Wrecking Crew
If you are a programmer at the beginning of your career, and you’re not good enough yet to be part of a team, or manage one, chances are that you write all the code on your own. With any significant project comes complexity. During the prototyping phase you most likely focus on making things work. You want to see your concept working. The drive to achieve a working state is so strong, that it blurs one’s sight. It often takes us to the point where we think: ‘what do I need to hardwire to make this crap work?’ Because of this irresistible urge, you’ve probably already met with the state of code, where everything is ad-hoc, vulnerable, hard to follow, easy to break, difficult to change, and continuously requires time to figure out what you were trying to achieve there.
Congratulations, you’ve just achieved to write bad code! But worry not, because you still can build a decent developer career without having to write a code any better. I tell you how.
Dead Letter Office
So you’ve managed to get hired, because you trained yourself long enough to answer stupid questions you will never meet again, and already know how to use some code written by somebody else. Believe me, that’s all it takes. Now you’re facing another challenge. How can you communicate the least effective way, so that nobody actually understands the other? You will work with at least one person who tells you their idea, and expects you to read their mind also. Whenever you’re talking about technical details, their minds conveniently shuts down, so that they grasp no word what you utter. Most often questions will be reduced to ‘can you do it?’, and ‘yes’ is expected as an answer. They don’t care about the how. They didn’t hire you to teach them. So you can continue to work alone with the mess you created before, as long as it works, and they don’t care. This is also valid to bigger teams with more developers, except that they only don’t care if they don’t need to touch your code. So writing bad code is still the default, and without putting extra effort into communication, it also remains that way. Just stick to the old habits of trying to solve everything alone, and often imagine that you’re a terminator to solve all the problems of humankind.
Keeping up Against Quality
From there on, you only need to apply a little resistance to whatever it insists you to improve your style. Stubbornly ignore reading books and articles on any topic. Solely rely on StackOverflow, and never spend more than five minutes on getting answers. If you need to learn anything, then restrict yourself learning about technology only, like libraries, framework, programming language, low level APIs, but by no means approach anything that claims to provide a bird eye perspective, any higher level stuff. At all costs avoid everything that has ‘best practices’ in their title. Let ‘clean’ be a swearword for you. The word “opinionated” should also be suspicious.
Best Practices for Worst Code
Here I collected some guidelines to start with, just to name a few. The list is far from being complete, but the good thing is that you can add your own techniques and reorder the list, and still it wouldn’t lose its validity.
- One safe place to rule them all
Ask for a place to write your code, and never leave that place. That is your safe haven. Write everything that comes into your mind into that place. No matter how long it gets stretched, you can be certain, that that place works. Who knows, it might crash when put into another file. If you write a function, write everything into that function, if you write a method, write everything into that method, if you write a class, write everything into that class. It’s definitely a bad sign if you need more than one of anything. Such a waste!
2. Code like YouTube recommendations
If you happen to learn something by chance, then overuse it immediately. If it worked in one situation, then use it as much as possible, trying to solve everything with that, no matter what. It should feel like getting flooded with YouTube recommendations until your eyes bleed, just because of that one video you once opened carelessly. But don’t forget, that learning is discouraged. Whatever you learn, use it for the benefit of making your code messier, not cleaner.
3. Always cut that Gordian knot
Bumped into some code that is well structured and actually does what it seems to do? Don’t leave it like that! Try to add more features to it, and enable/disable them by options. Don’t forget that you can call anything from anything. Always change access modifiers, if they don’t fit. Best to keep all methods public. goto was banished unfairly from most of the programming languages, but that doesn’t mean you can’t jump around the code by calling functions or methods whenever and wherever you like. You can even call the same method again. Don’t be scared to use recursion! Jumping from one class to the next, from one method to the next is like cutting the Gordian knot. It’s just skips the unnecessary parts. Another way to cut things short, is to use asynchronous functions whenever possible. Parallelization just makes everything faster, right?
4. Code must be canonical
Never reconsider your approach. Code like it’s carved in stone. Whatever is written, it’s written for eternity. You can only expand it, but cannot change it. This is how canons evolve. So if your function does not do the thing you want it to do, just add another parameter, and an if inside of the body. Having less than three conditions in the function’s body is not healthy. Same applies to methods. If you have a class, make sure you have have as many options as constructor parameter as possible, but let methods be configured with their own options. Feel free to reuse anything, as long as you add new parameters and conditional blocks to it. If you can’t do that for whatever reason, just duplicate the original, and tailor the duplicate to your needs. Your best friend is the flag, the boolean variable. Did you know that you can even have flags as bits in a binary coded number? Imagine how many flags you can squeeze into a long int!
5. You can only count on yourself
As already mentioned, the good mentality in programming is like that of the characters in Mad Max. How could you rely on anybody else other than yourself? It just makes you vulnerable. Never consider accepting help from anybody. It’s a trap! They want to deceive you, exploit you, rob you. Just implement everything yourself. Don’t be shy to reinvent the wheel everyday. It just increases the company’s reliance on you. In an ideal world every code is so entangled, that not even its creator can have a clue what it does when checking one day after writing it.
Blame it on the Paradigm
When you’re in the industry long enough, it can happen that others will recognize your talent. They may finally give you the attention you deserve. Others might even reward you with placing you back to the labor market. Finally you can be free! This is what you were working for. Enjoy your well deserved freedom. But never forget, you cannot be blamed for anything. Whatever you might have done in code, it was for the greater good. For the benefit of the society. To pay back a little for the pleasures and enormous joy you get just by being a programmer.
Even if some bad things happened, for example the company went bankrupt because of unmaintainable code, this is by no means your fault. It’s always the technology to blame. It was because of that framework. Or that clunky programming language, the zealous colleagues, or the programming paradigm. Yes, it was because of Object Oriented Programming. This paradigm is responsible for everything. And before that, it was Structured Programming. And after that it will be Functional Programming, no doubt about that.
Just never take them seriously. Follow my wise advises given, add your innate instinctive solutions to them, the possibilities are endless. You can ruin a program in infinite different ways. With just a pinch of luck, you can effortlessly evolve into the worst programmer ever!
