Code Monkey

code monkey:n 1. A person only capable of grinding out code, but unable to perform the higher-primate tasks of software architecture, analysis, and design. Mildly insulting. Often applied to the most junior people on a programming team. 2. Anyone who writes code for a living; a programmer. 3. A self-deprecating way of denying responsibility for a management decision, or of complaining about having to live with such decisions. As in “Don't ask me why we need to write a compiler in COBOL, I'm just a code monkey.”

Some claim the etymology of the phrase derives from the famous Infinite Monkey Theorem, where a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type a given text, such as the complete works of William Shakespeare. To be sure some of the WTF code I have had to try to fix or maintain brings that imagery to mind.

There are quite a few references to the term Code Monkey: c2,  etc.

I started out computer life as a code monkey, 12 years old, learning to automate basic mathematical curiosities such as Fibonacci series and prime numbers in BASIC (circa 1970) as part of an experimental computer mathematics class in grade 8. When I graduated from University my first job was as a "Programmer/Analyst" which is effectively a Code Monkey. These days I pretend to be a Software Architect (whatever that means) but there are still days when I feel like a Code Monkey and other days when I want to go out and kill me some Code Monkeys.

Writing code can be a daunting task - as you are not just writing code your are building and/or fixing a machine. People often forget the programs, software, applications are machines and not prose that some artificial intelligence reads and deals with in any reasonable way - except the reason of Garbage In, Garbage Out.

When I am in full Code Monkey mode I am usually struggling with concepts or mechanisms that are just beyond my reach of groking, and in frustration I behave very much like a monkey trying random things and praying to the Robot God that the next run will be the one that compiles and executes correctly. However, at this point people's behavior diverges:

• Myself I believe that if I struggled with something hard then I need to make sure the code is clean and readable and that there are sufficient comments describing what is going on so that the next person to come this way does not hurt their brain - because it is usually me to forgets the context when I have to come back and look at my own code again
  
• Other people seem to have this cherished attitude "Well if it was hard for me to figure out it should be hard for the next person to figure out too." In reality sometimes people are just too burned out solving the problem they need to distance themselves from the pain as soon as possible and move on to trying to meet their deadline.

One of the most common Code Monkey patterns I see is the copy-paste pattern where

1. Code Monkey needs to implement featurebut does not know where to start.
2. Code Monkey searches code base for similar feature for example.
3. Code Monkey copies and pastes other code and repurposes it to make new Code Monkey feature.
4. Code Monkey makes boss proud by completing feature in half the time estimated.

The basic flaw with this pattern is that it tends to replicate really back stinky Code Monkey feces-style code everywhere in code base. By contrast the Code Master pattern might be

1. Code Master needs to implement feature but does not know where to start.
2. Code Master searches code base for similar feature for example.
3. Code Master copies and pastes other code and repurposes it to make new Code Master feature.
4. Code Master refactors new feature code to conform to more sane and up-to-date coding practices and conventions, so as to leave behind better examples for other Code Monkeys and Code Masters to follow.
5. Code Master does not seek acknowledgement or praise from boss as boss can never understand ROI Code Master provides. This last part is humor (mostly).