Don’t run with scissors.

Exercise extreme caution when removing data.

One must be very careful when deleting data. It’s far too easy to delete the wrong data by mistake. This kind of error can lead to extensive system downtimes and upset clients.

Before removing any data, query the data set to be deleted and examine it closely. Sometimes this simple action can reveal data elements that you should not remove. For more massive data sets, sample the data multiple times. Also, one can summarize the data to be deleted and look at counts and totals.

Also, make sure you have backups. It can be extremely unfortunate to delete the wrong data accidentally and then learn, too late, that your backups are not functioning correctly.

Even highly experienced people make mistakes. Don’t get cocky!

Some bugs are caused by bad assumptions.

These assumptions can cause widespread problems.

When you fix a bug that was based on a bad assumption, look for other areas of the code where those bad assumptions where used. Chances are good that there are additional bugs caused by the assumptions, bugs you haven’t found yet.

You may find many other bugs that have gone unnoticed as a result.

Always question your assumptions. It’s very easy to get the assumptions wrong, as they are often communicated to you through several people, each of which may accidentally alter it slightly.

Make you sure you document your assumptions in a shared knowledge base. An internal wiki like Confluence or other similar products is good for this.

Find the first error.

A large series of errors is usually triggered by a single error.

When problems occur and you have a long stream of errors, try to find the first error. Most of the time, everything after that is a side effect. Like a chain of dominoes, the first error causes all the others to occur.

Sometimes that first error is hidden, or lost in other noise in the log. It’s not always obvious, but definitely dig for it.

Try to solve the root cause instead of treating the side effects.

Write a test for every fault you find.

It’s a simple way to avoid repeating mistakes.

You get this for free if you follow the highly recommended practice of test-driven development.

If your code base doesn’t have that kind of coverage, always be sure that there is a test to cover fault, bug, mistake, error and unexpected result that you encounter.

There’s nothing worse than having bugs come back later. When you repeat the same mistake twice, did you learn nothing the first time? Avoid this.

Don’t count on others to test.

Do your job and be responsible.

Test everything you write and review. All of the code you work on, whether you are the primary developer, the pairing partner, or the code reviewer, you need to test. Be responsible for all the code you are participate in.

It’s extremely bad behavior to depend on others to test. This usually results in certain parts of the code not being tested, and bugs introduced into the production code base. And then you’re no longer delivering working software. And if your’e not going to deliver working software, then why are you here?

It’s your job to ensure the quality of your code. Own it.

Testing can find bugs, but it can’t prove the absence of bugs.

It can certainly find bugs, but it is not proof that all is well.

Getting all green lights on a test suite does not necessarily mean that everything is okay. It is quite possible for bugs to still exist in a system, even when the code coverage is quite extensive.

Still, it is worth trying to cover all the known cases. More coverage and test cases is better than less.

You just have to remain vigilant. Don’t put all your faith in the testing machine.

Never ignore an error.

You can’t simply pretend it didn’t happen.

Silent failures will screw you over. They will lead to corrupt data in the system, and it will be incredibly hard to track down the source of the corruption. It can also lead to huge financial losses as well.

If you can’t handle the error, signal the failure up to the calling method. The buck has to stop somewhere. Pretending things will be okay is a major rookie mistake.

Comments should discuss the current functionality.

Don’t let your comments ramble on about the past or future.

Don’t have comments describing what a function used to do. That information is in the version control. Instead, the comments should only discuss why the current functionality is the way it is.

Similarly, don’t speculate on the future. You don’t know what the future business requirements will be. (cf. YAGNI)

When you update your code, update the comments as well. Don’t turn the comments into lies.

Don’t use comments as version control.

Instead, use version control software, like git.

Some developers leave blocks of commented-out code. Maybe that’s the previous version of the code, or maybe it’s the future version. In worse cases, multiple versions are commented out. This confuses the reader greatly.

Blocks of commented-out code are confusing, misleading, and trouble. Someone will uncomment the code and reintroduce it at the wrong time. It will lead to bugs and faults.

If you don’t need code anymore, delete it. Deleted code has fewer bugs.

And if you really need to look back at prior versions, they are available in the git history.

Avoid comments at the end of a code block.

Your block is probably too big.

If you feel the need to put comments at the end of a block of code then your block of code is probably too big. Some developers put this at the end of for and while loops to indicate which block is actually ending. If this isn’t obvious at a glance, then your block is probably too long.

Extract out the logic in the block to a method. This will make it a lot smaller, or possibly eliminate the need for a block altogether. It’s okay to have more methods, the code will be more readable this way. Plus, the new methods can be tested separately.

Also, never trust the comment you see at the end of a block. Errors in coding or later changes can turn such a comment into a lie.