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.

We all know writing the damn docs for functions and classes and modules is a pain in the backside. But realizing what you were thinking when you wrote the function will save your butt in the future.

When developers try to solve a problem, they sometimes try to find a way that will solve all the problems, including the ones that may appear in the future.

If you write a test for every single function on your system, and your system keeps changing, how will you know when a function is not necessary anymore?

You can be sure that if a language brings a testing framework -- even minimal -- in its standard library, the ecosystem around it will have better tests than a language that doesn't carry a testing framework, no matter how good the external testing frameworks for the language are.