Simple Ideas Explained

This is the preface of a series of articles I intend to post in the coming weeks about simple ideas, ubiquitous among all programmers, but rarely understood, and too often preached for without any justifiable reason.

Follow me in the coming weeks to understand, once and for all, what's so important in the following concepts, and why.

Do that, and you'll be able to explain, both to yourself, and to your friends and co-workers, why you, as a programmer, make all those (somewhat intuitive) design decisions that you make.

What I'm going to talk about is why and when the following concepts are considered a bad thing:

• Global state
• Global access
• Tight coupling
• Multiple responsibilities per class
• Operator overloading
• Bad or inconsistent naming conventions

But first, a few key notes you should be aware of:

Intuition

It turns out that, as programmers, we rely heavily on intuition. Why is that? Simply because we can never be bothered to learn and understand all the smallest peculiarities found in Computer Science. We often feel competent as soon as we think we get the general idea of something, without bothering to philosophize about it, which can be quite a time waster, accumulatively.

However, it is fundamental that we understand that that's exactly what makes up our intuition. Things which we kind of get, but not entirely.

This may often prove to still be valuable and useful, but we must never assume that it is unquestionably correct.

Dogmatism

One obvious problem resulting from reliance on intuition is dogmatism.

When we don't understand an idea to its core, but know that it is preached for and is widely considered a good idea, we tend to apply it even where it's redundant or even harmful.

One side effect of not knowing how to explain such ideas is transitive fanatic evangelism. Meaning, if you manage to use your charisma to persuade other people that an idea is good, without explaining it thoroughly, they will often listen to you, and evangelize others in exactly the same way.

This is how many common bad ideas are formed.

Context

We often find ourselves asking such unnecessarily general questions, such as "Is this idea important?".

It is vital to understand, once and for all (get it in your head) that there is no such thing as "important things".

One must always define a context. When a context is not defined, or implicitly and unambiguously rendered, one should not bother to answer questions.

Self-rationalization is a disease. If you wish to open yourself to practicality, you must embrace objectivity. Nothing is good or bad without a context. Nothing!

While subjectivity may often lead to quite humorous catchy mnemonics, such as this quote from some guy at CodeReview.SE:

"Daddy, Daddy, he defined a global!"

"Now son, what have I told you about using language like that?"

It should also be explicitly taken into consideration that, for example, defining a global variable might not always be a bad idea, until it is proven otherwise.

A lack of practical examples justifies avoidance, but does not constitute groundless aversion.

First-Hand Experience

I would like to clarify that everything I say is based on personal first-hand experience.

If anything portrays me faithfully, it is the ability to never skip making impulsive mistakes, but, quite fortunately, to learn from some.

I hope that you find sympathy, understanding, and enlightenment in the upcoming posts.