The title of this document refers to a street entertainer, once common but now rare, known as a Hurdy Gurdy man or Organ Grinder. He used to travel around with a hand-operated organ, or hurdy gurdy, playing tunes for anybody who would listen, and hope that his grateful audience would drop a coin or two into his tin cup. As entertainment he would usually have a pet monkey, often dressed in a cute little costume, who would dance for the audience and sometimes perform simple tricks, like doffing his cute little cap, or "playing dead for the Queen".
The organ grinder was the man in charge. He turned the handle to grind out a tune, and all the monkey had to do was dance to that tune. The monkey could not make a move without the consent of his master.
This relationship between man and monkey led an irate customer, when confronted by a lowly underling when he wanted to speak directly to the man in change, to utter that immortal phrase: "I want to speak to the organ grinder, not his monkey". As an alternative to this some people say "I want to speak to the engineer, not his oily rag".
In the world of software development, just like many other areas of human endeavour, there are people with real talent who are at the top of their profession, up there with the organ grinders, while there are a great number who are stuck on the bottom rung of the ladder down there with the monkeys.
Which one are you? An "organ grinder" who calls the tune, or a "monkey" who can do nothing but dance to somebody else's tune? Are you a "top dog" or a "bottom feeder"?
Another term for a code monkey is Cargo Cult Programmer.
Here are some clues to look out for:
Teaching is when knowledge is passed from one person to another while learning is what a person does on his/her own. Learning is what comes from personal experience, not the second-hand experience of others. Learning comes from trial and error, from making mistakes. Although there may be some cases where the documented experiences of others may prevent you from repeating tragic or costly mistakes, in a lot of instances it is nothing more than "this is the way that *I* do it, so this is the way that *you* should do it". A monkey will follow what he is taught to the letter and without question.
As a real-world example, I remember that when I was a young boy I was taught that When a girls says 'No' she really means 'Yes'
. However, when I tried to put that theory into practice I quickly learned that When a girsl says 'No' she REALLY means 'No'
. That lesson has stuck with me ever since.
An organ grinder, on the other hand, will not take everything at face value. He will take the time to explore other possibilities and compare their individual advantages and disadvantages. He will want to discover if other, and perhaps better methods exist. He may sometimes find that a particular method was rejected not because of a fault in that method, but because the critic's implementation of that method was faulty.
Original thought means putting aside of set of ideas of others and trying something new for a change. Without trying something new it will not be possible to find something that may be better. A monkey is incapable of original thought, or perhaps is afraid of expressing that thought for fear of being mocked by his peers.
An organ grinder, on the other hand, has confidence in his own abilities. He is willing to try out new ideas, new methods, and if they produce better results he will not be afraid to stand up and say so. He may be mocked by those who refuse to listen, but he also knows that, sooner or later, the fact that his results are superior will be recognised by those with open minds.
Those who imitate others are followers, while those who are imitated are leaders. Progress cannot be made by hordes of imitators and followers, all they can do is maintain the status quo. Progress requires an original thought, a change in direction, a different approach, someone who can compose a new tune instead of constantly grinding out the old tune.
A monkey can only imitate, play "follow my leader", and will never be able to make improvements, to make progress. An organ grinder, on the other hand, will stand up and say "This may be the best that you can do, but it is not the best that I can do".
Rules are drawn up by one individual or group to cover the circumstances encountered by that individual or group. But what if a new set of circumstances arises, one not encountered by the original rule makers? A monkey will try to bend the existing rules, or to offer different interpretations of those rules, in order to fit the new circumstances, with often less than optimum results.
An organ grinder, on the other hand, will recognise that the new situation cannot be covered by any existing rules so he will use his experience, his intelligence, to explore the new situation to see what new rules, if any, are needed.
A monkey will follow a set of rules blindly and without question, and assume that whatever is produced must be acceptable. He will not be able to tell whether the results are good or bad, just that the rules were followed. He is the kind of person who says "the operation was a success, but the patient died".
An organ grinder, on the other hand, will see that the results are not as good as they should be and seek out the reason why. He will seek out the places where the rules were applied incorrectly, or the wrong rules were applied, or where new rules should have been created. He will then take whatever action is necessary, including the making and breaking of rules, until the results are acceptable.
Take a code monkey and promote him to project leader, then ask him to produce a set of development standards for the entire project. Watch him flounder like a fish out of water. I have seen development standards produced by such people, and they have got nothing at all to do with "best practice", just "the best that I can do (which is not much) practice". Their idea of everyone working to the same standard is "this is the way that I do it, so if everyone does the same that will be good enough". All the programs were consistent, sure enough, but consistently low quality. Their rules are full of "do this" and "don't do that" without any word of explanation or justification.
An organ grinder, on the hand, knows the difference between "good practice" and "bad practice", and can explain why something should or should not be used. He can explain why the quick solution sometimes is prone to errors while the long solution is better because it avoids the same potential for errors. Not only does he know why a rule exists and the circumstances for which it arose, he also knows when a rule is inappropriate or ineffective because of a change in circumstances.
This idea is not new at all. It has been recognised by others and given various names such as:
A monkey is used to doing things in a particular way, in the way that he has been taught, and is resistant to change. As soon as he sees something different he will immediately pounce on the difference and proclaim "That is not the way that was taught to me by my masters, therefore it must be wrong". He will not even bother to examine the results, to see if they are an improvement or not. Rules are rules, the results are irrelevant.
An organ grinder, on the other hand, will see the different result and want to know how it was achieved. He will want to see how this new method actually works, to see if it can be incorporated into his own work so that he may produce a better result.
A wiser monkey may say "I didn't know that it could be done that way", in which case you have just identified a deficiency on the part of his master, an area where your knowledge and experience are obviously greater than his.
A monkey does not have what it takes to recognise that a particular method or a particular rule is a hindrance rather than a help. His motto is "I've always done it this way" or perhaps "This is the only way I know". When moving to a new language or a new paradigm a monkey will want to carry forward as much of this old baggage as possible. He will not recognise that what worked in the old language may be inappropriate in the new, or can be done in a new and better way. He will not recognise that the new language has a different way of doing things and consequently a different set of rules apply.
An organ grinder, on the other hand, will recognise a new language for what it is - new and different. He will seek out the differences, the different ways, the different rules, and adapt himself accordingly. He will recognise that an old rule is now inappropriate, a hindrance instead of a help, and discard it without a second thought.
To a monkey the only way to create reusable code is by the old copy and paste method, which results in copies of the same code being pasted in numerous places throughout the application. This also means that any bugs are also duplicated, and any bug fixes have to be duplicated in every single copy. Even if such a person can see where code is being duplicated they don't know how to extract it and put it in a reusable library, or they can't be bothered to make the effort.
An organ grinder, on the other hand, can spot instantly where a piece of code has been duplicated, and knows how to add that code to a reusable library. He also knows that any time spent in creating and testing a new library function is an investment that will reap rewards in the future.
If a code monkey cannot produce coherent and effective development standards, or cannot produce libraries of reusable code, just watch him try and produce an entire development framework. He will try to start with a set of rules, then write code that conforms to those rules. If the rules are poor quality, or his understanding of those rules is faulty, then his implementation of those rules will be enough to make a grown man cry, or a saint swear. Just watch what happens when a code monkey tries to use as many design patterns as possible, but doesn't know how to use them effectively or appropriately. You may think that it's impossible to write spaghetti code using OO techniques, but a real code monkey will astound you with his culinary expertise.
An organ grinder, on the other hand, knows what results are expected and knows the best way to produce those results. He knows what design patterns to use, when to use them and how to use them. More importantly, he will know the circumstances in which their use is appropriate and when it is not. He will know the shortcomings of other frameworks and seek to eliminate them. He will know what rules to accept, and more importantly, what rules to reject. When exposed to the results of a real artisan, a code monkey is often heard to explain "I didn't know you could that!"
That's the difference between an organ grinder and a monkey - one knows, the other knows nothing.
Everything else, as far as I am concerned, is secondary and entirely optional. There are some add-on features in other languages which are entirely irrelevant in PHP simply because of deficiencies in those other languages which do not exist in PHP. Interfaces are a prime example. Other languages may need them because of how they deal with optional arguments, or arguments of different types, but PHP has its own method of dealing with these which makes interfaces a waste of time.
Instead of saying that PHP does not support OOP perhaps what they really mean is that PHP does not support their style of OOP. If this is the case then I would argue that it is their style which is questionable.
When these purists tell me that my methods are wrong they are making a fundamental mistake - my methods cannot be wrong for the simple reason that they work. My methods may be different, but since when has being different been a crime?
Those who choose option #2 are demonstrating that they do not have enough of option #1.
I do not need foreign key constraints to access tables within my application. I do not need foreign key constraints to construct an SQL query with a JOIN. I do not have to move logic out of my application and into the database. Because I do not have to do those things I am simply exercising the option not to do those things. I was taught to write applications with databases which did not have any of those "features", so I know how to write code which does not rely on them. This person obviously does not, yet he has the nerve to question my methods!
For another view on code monkeys please read Monkey business by Gregory Golberg.
Start with a cage containing five monkeys. In the cage, hang a banana on a string and put stairs under it. Before long, a monkey will go up the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all the monkeys with cold water.
After a while, another monkey makes an attempt with the same result - all the monkeys are sprayed with cold water. Turn off the cold water.
If, later, another monkey tries to climb the stairs, the other monkeys will try to prevent it even though no water sprays them. Now, remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his horror, all of the monkeys attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.
Next, remove another of the original five monkeys and replace it with a new one.
The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm.
Again, replace a third original monkey with a new one. The new one makes it to the stairs and is attacked as well. Two of the four monkeys that beat him up have no idea why they were not permitted to climb the stairs, or why they are participating in the beating of the newest monkey.
After replacing the fourth and fifth original monkeys, all the monkeys which have been sprayed with cold water have been replaced. Nevertheless, no monkey ever again approaches the stairs.
Why not? "Because that's the way its always been around here."
| 27 Apr 2022 | Added A monkey follow rules without understanding how and when they are supposed to be applied. |