It is relatively easy to find very young people who are brilliant programmers, who seem to know every detail about a particular language, platform or technology. Some of them will be able to implement a nice Android app in a few days, others can write cool Facebook games in a week.

These bright young programmers are frequently very quick learners as well. Give them a new programming language and they will grasp its syntax in a couple of hours. Present them a new API and they will very soon understand all the differences among similar methods and the roles of each parameter.

Now the question is: Do their knowledge and ability to learn transform them into expert software developers?

Whenever I meet these young programmers, I remember this quote:

“The young man knows the rules, but the old man knows the exceptions.” – Oliver Wendell Holmes

So my answer to the previous question is “No”. Knowing the rules of a programming language or platform can make you very effective when working in a particular environment. But to really be an expert you must know the exceptions. You must know when to violate the rules.

1^st Example: Composition versus Inheritance

I once worked with a good Java programmer that followed the rule “favor composition over inheritance”. The problem is he was fanatic about it: In all situations he used only composition. In his programs you could not find a single class extending another class. If he wanted to reuse a class, he would just encapsulate it in a new class and forward most method calls. A rule with no exceptions allowed…

2^nd Example: Const-Correctness

I once participated in the development of a very large C++ system. I noticed that almost none was using const methods, and as a consequence they could not pass const parameters, even if an object was not supposed to be changed by a function.  I was surprised; it seemed that most people were not aware of the importance of const-correctness.

But then I discovered another reason for this mystery: Most programmers didn’t know about the possibility of declaring a data member as mutable. Then, many classes that used synchronization mechanisms had not const methods, even when the state of the object was not being changed. Even the accessor methods could not be declared as const, because they were changing some lock.

The rule says that const methods should not change the values of data members. But the real intention is that they should not change the object state. Hence the exception to the rule is that Semaphores and Mutexes can be changed by any method, because they are not part of the object state. They should be declared as mutable.

Conclusion: It is relatively easy to learn the rules, but only experience can teach you the exceptions. If you know the rules and the exceptions, then you are an expert.

I will be happy to hear in your comments more examples of rules and exceptions. Please share your experience. Thanks!