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.

Interfaces and APIs is what you give away to others. If you keep changing them, you'll make everyone's life sad.

If you're worried about learning some new programming language, you can bet the one with a better documentation is the one that is born with a document processor.

Same goes for the frameworks/libraries of that language.

When you start the code by writing the general flow as steps and making each step a function, you're actually making a contract (probably with your future self): I'm saying this function does this and this is what it does.