Are you a Code Monkey?

Colapsar
X
 
  • Tiempo
  • Mostrar
Limpiar Todo
nuevos mensajes
  • MoaLaiSkirulais
    ^^(V)^^
    • 08-07-2003
    • 23268

    #1

    Are you a Code Monkey?

    ... or are you an Organ Grinder?

    By Tony Marston, 17th March 2006


    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".

    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"?

    [img]/carne/diablo/media/organ-grinder-and-monkey.jpg[/img]

    Here are some clues to look out for:

    1. A monkey knows only what he has been taught, not what he has learned.
    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.

    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.

    2. A monkey is incapable of original thought, he can only echo the thoughts of others.
    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.

    3. A monkey can only imitate, never innovate.
    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".

    4. A monkey does not know when to break the rules.
    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.

    5. A monkey is rules oriented, not results oriented.
    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.

    6. A monkey sees anything "different" as automatically "wrong".
    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.

    7. A monkey likes to perpetuate bad ideas "to be consistent".
    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 is totally inappropriate in the new. 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.

    8. A monkey can only follow rules, he cannot make them.
    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, he also knows when a rule is inappropriate or ineffective because of a change in circumstances.

    9. A monkey cannot write reusable code.
    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.

    10. A monkey cannot build an entire framework.
    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. 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.
  • MoaLaiSkirulais
    ^^(V)^^
    • 08-07-2003
    • 23268

    #2
    esta es la nota original:


    fíjense al final hay mas de 20 "Examples of code monkeys" y un relato final....

    Comentario

    • Piluex
      Away
      • 10-10-2004
      • 3038

      #3
      There are rumours that one of the "enhancements" in PHP 6 will be that all function names and method names will become case sensitive for no good reason other than to be "consistent" with other languages. What these simians fail to realise is that other language may have the ability to hide their case sensitivity by auto-correcting the case of any variable or function names as they are keyed in, thus making it impossible to make a mistake. PHP does not have this capability as (a) it s not a compiled language, and (b) it does not have an IDE with this capability. As far as I am concerned any language which allows you to use the same function name or variable name with the same spelling but different case to mean totally different things is a BAD language. Can you name me any language which supplies the same function name in different mixtures of case to mean different things? You can't! Then take a guess as to why not. BECAUSE IT IS NOT A GOOD IDEA, YOU CHUMP!
      =/ che es re n00b el chabon, no sabe escribir una palabra 2 veces con el mismo case?. Es mucho más óptimo para el interprete que sea case sensitive, solo que no creo que sepa eso. Ni remotamente.

      There are some poor deluded souls who proclaim that it is not possible to write object oriented code with PHP. This is absolute rubbish. All that a language requires to offer in order to say that it supports object oriented programming is the following:

      * The ability to define classes.
      * The ability to create instances of those classes.
      * The ability to support encapsulation, inheritance and polymorphism.

      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.
      No tiene ni idea de lo que dice el chabon, si php tubiese esa opcion (como todo en php es "opcional") estaría muy bueno para varias cosas el poder definir MEJOR lo que uno quiere asi optimizando la interpretación, después de todo una de las peores cosas de php es que en páginas de MASIVAS visitas, o scripts muy largos esto ayudaría de manera considerable. Sin embargo yo considero que php es en parte OOP, pero la forma en la que lo argumenta es totalmente estupida.
      There is another group of confused individuals who will insist that encapsulation means "information hiding". NO IT DOESN'T! If you chumps bother to read the manuals carefully you will see that encapsulation is about hiding the implementation (the code which processes the data) and not about hiding information (the data which is processed by the code). I know the words have similar spellings, but they actually mean completely different things.
      En realidad la encapsulación tiene la finalidad de no permitir que el "usuario" de la clase modifique datos, asi evitando posibles errores en ese proceso, entiendase que no oculta nada sino más bien restringe acceso a los datos y/o procedimientos pertenecientes al rol de la clase para que estos sean SOLO cumplidos por la misma y asi sea más facil de rastrear y corregir un problema.

      There are one or two OO purists out there who think that I should be burned at the stake for committing the ultimate heresy - the breaking of their precious rules. Take for example my practice of creating a separate class for each database table. According to the purists this is totally wrong! Why? Because they have been taught that it is wrong. Luckily I wasn't taught such stupidity, so I followed my instincts and wrote code which works. My logic is as follows:

      * A class is a blueprint for one or more instances. Is not a table schema a blueprint for one or more instances (records)?
      * Each object which has a different blueprint requires a different class. As the structure and business rules of the CUSTOMER table are totally different to that of the PRODUCT table, then it follows that they should have different classes.
      * To cover the fact that there is quite a lot of processing which is common to all database tables I created an abstract class to contain all this common processing. Individual database tables then extend this superclass into separate subclasses, one per table. Each subclass contains the specific implementation details for one database table.

      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?
      No son un crimen pero no podes decir que es OOP, para eso que vos haces existe lo que le falta a php (según vos, nunca lo comprobe) en tu texto anterior, vos creas una clase "madre" que maneja tablas, "genericamente" después implementas cada caso x separado como clases hijas de la misma, aunque quiza solo sobrecargando 1 o 2 funciones alcanze, supongamos que no, y de esta manera todas pueden ser tratadas por igual (osea manteniendo su parecido como tablas q son), eso si querés hacerlo OOP y codigo REUSABLE cosa que criticabas a los monos, quiza seas un mono más.

      There are some programmers who insist that it is "clever" or "cool" to be able to write code using as few keystrokes as possible. They think that this qualifies as "efficient programming". What these poor dears fail to realise is that program code is written to be read by humans and only incidentally to be executed by a computer. Programmers, especially maintenance programmers, spend more time reading code than they do writing it, therefore it is absolutely essential that it is readable. By this I mean that anybody other than the original author should be able to look at the code and understand what it does and how it does it so that they can fix it or enhance it without too much effort. Most of the people who look at a piece of code do not have the same experience as the author, so it is better to invest in a few more keystrokes up front so that a new reader can get to grips with the code as quickly as possible. It is a waste of time having some really clever code if no-one but the original author can maintain it.
      Ok, hay ESTANDARS(notación hungara x ejemplo) para la notación de variables, escribir poco, o escribir de más son los dos errores si lo que querés es código mantenible, el programador de "mantenimiento" esta entrenado para seguir estandars.

      Me cansé-

      Comentario

      Trabajando...