"Code Monkeys" and the "Software Eunuchs"

Its odd given the historical roots of programming - and in many ways its growing complexity -that the term 'Code Monkey' should have arisen.

You don't get 'Lawyer Monkeys' or 'Financial Monkeys', so why has this derogatory term emerged? 

My view is that this is the result of a 'devaluation' of the role of programmers and the increased demarcation of roles that has arisen - at least in part - from the introduction of the Waterfall methodology.

The demeaning term of "Code Monkey"  suggests that coding is just a basic and simple process of churning out lines of code according to the specification. Rather like a copy typist or a translator taking a specification and transposing it onto the computer. The "real brains" being with the analyst, the designer or the architect (in fact anyone but the person who built it). No wonder many coders want to become something other than a coder because they don't feel their role is valued. 

It may seem a rather minor point to be making, but actually I believe this has contributed significantly to poor software. Naturally it is demoralising to programmers to be thought of as "Code Monkeys" (either explicitly or implicitly), but more than this, it disengages and divorces them from the analysis, the design, the user, in fact everything except the lines of codes they are "cutting" (not sure I like that expression either).

From a coders perspective, they feel more like a "Software eunuch", a coder without involvement, influence or power over their project. 

So product development is reduced from being a creative team effort to a production line effort ('A' doing what 'B' passed down the line) and unidirectional.

This is where you get the typical "swing" characterised so well in the cartoon.

You can just hear the programmer turn round saying "but I'm just the code monkey" not as a badge of honour, but to excuse their involvement in a project they had no influence. 

There are many lessons to take way from these experiences, one of which is the need for team work and joint ownership of outcomes not simply isolated ownership of processes or individual deliverables that might be expected in a production line environment.

The other is the recognition that coding is an intellegent and creative activity not best suited to monkeys of any description, and that intelligent creative people have more to contribute to the development process than simply cutting code.  

This is one reason why I believe the Agile methodology has made a significant positive impact on development due to its much higher involvement and engagement with developers. Certainly this is my experience.  

My Three  (R)evolution Rules...

1) Don't hire code monkeys.

2) Don't treat coders like monkeys and

(coders)

3) Don't work like code monkeys.

p.s. they never did get any monkeys to type the works  - or even words - of Shakespeare.