Most of the times I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern.

A lot of times I heard "We should use the right tool for the job!" Most of those times it was just a way to push an agenda.

Maybe you're in a project that needs to process some text. Maybe you're tempted to say "Let's use Perl" 'cause you know that Perl is very strong in processing text.

But that may still be not the right tool.

You may be tempted to use a list (or tuple, if your language allows) to keep your data if it has, say, only 2 fields. Don't.

Although that sounds weird, it's better to not add any error handling than silently capturing errors and doing nothing.

Memory is just a sequence of bytes; bytes are just numbers from 0 to 255; what those numbers mean is described on the language type system.

If you know an error can occur, then you should handle it properly, instead of ignoring it.

Picking a programming language is much more than just picking the words that will generate a code. They come with a community, a leadership, an ecosystem and a thread the binds them all together.

When you're designing a function, you may be tempted to add a flag (a parameter in a function that it is a boolean). Don't do this.

Functions should do one thing and one thing only. I clear indication that you're breaking this principle is the need to add an "and" in its documentation.