Maybe you’ve never written a bug. But you’ve heard about other people’s bugs and you want in on the action. It is for you that I’ve put together this collection of handy hints that will have you writing ninja-level bugs in no time.

Rules are made to be broken.

The standard says I can’t put a <div> in a <span>.

Pffft.

<span>

<div>Like hell I can't</div>

</span>

Tested in Chrome and it works fine.

Now, you might be thinking I’m about to give you a concrete example of the bug this particular behaviour creates but that’s the wrong mindset.

Because then you would know a concrete example of a bug, and knowing exactly where the problem will occur is not the best way to write bugs. To be a truly great bug-creator you need to ignore rules like ‘only put phrasing content in spans’ and get code out in the wild that will probably work in most places most of the time.

ASI is there to help

Nothing ruins a beautiful piece of code more than seeing a semi-colon at the end of every statement;

Ugh;

I have to question the sanity of the developer that feels the need to put the ugliest of all the punctuation marks all over the shop when they’re not even required.

The classic cars of code

Maybe you’re not into classic cars, maybe a good vintage armoire is more your style. Perhaps you prefer vinyl over mp3, or the golden days of cinema.

Regardless, most people can appreciate that we’ve lost something in modern society, and it’s the same thing with deprecated methods. I like Node’s util.debug(), I don’t want to use the Johnny-come-lately console.error(), it just seems so clinical.

If you’re using a method that some library owner has decided to deprecate, simply don’t update that library any more, you know you’re sitting on the classic version that’s only going to go up in value.

Halve your code

A sickening fact: almost half of all code written by so-called ‘programmers’ doesn’t even make it into production. I’m talking about unit tests.

Stupid unit tests.

Think of it, you write a function that adds some numbers together, then write a test to test that the function adds some numbers together?

It’s madness. You know your code works, you can see it working. Push to prod, get onto the next task and keep shipping!

Copy paste

Stackoverflow: the snippet library by professionals, for professionals.

Want to write an ajax request?

Google ‘how to do an ajax request’. Click on the first stack overflow result. Copy/paste the first answer.

I’ve heard there’s people out there who will tweak the code after copy/pasting it or even type it out themselves so as to better understand it!! Who are these weirdos? By messing with the stackoverflow snippet you’re messing with fire.

Pro-tip: when there are no stack overflow results, w3schools is a great resource.

Think globally

I’ve heard that there’s people out there talking smack about global variables in JavaScript. These people are buffoons.

If you have a variable that you want available everywhere in your code, then chuck it on window, my friend. That’s what it’s for.

Obviously if it’s a common word like ‘promise’ or ‘screen’ or ‘status’, put a ‘2’ after it or something.

But if it’s something specific to your app, like ‘speaker’ or ‘config’ go bananas. As will all things, test that it works in Chrome (and Firefox if you’ve got the time) before pushing to prod.

For the non-coders

Even if you’re not writing code yourself, you can still contribute to creating bugs. Let’s say, for example, that you’re in the sales team, spreading the word about your company’s awesome piece of software. Don’t forget to spread the word about that hot new feature coming out soon. You will find that most new customers are far more willing to pay if they can have a verbal guarantee that a particular feature is coming out in the next few months.

You will need to create a situation whereby if the developers don’t produce a particular feature by a certain date, the company will lose a specific and significant amount of money. I probably don’t need to say this, but please don’t bug the development team about realistic timelines for that hot new feature, they would much rather be coding than talking to you about timelines. If it gets close to the deadline and things are looking grim, they can just work faster.

Never forget that all developers can always just work faster.