In software engineering there is two types of work required:

  1. Broad shallow work: best done by generalists (full stack developers)
  2. Deep work: best done by specialists

Examples of broad shallow work:

Examples of deep work:

There are many more tasks to do in the broad category but when you spread that thin you lose depth of knowledge and skill, compared to being specialised and focused. Should you build your team of specialists or generalists?

For a well functioning team you need both specialists or generalists since they provide different value to the team?

Why have generlists?

Why have specialists?

When managing a team keep in mind the agile principle: "The best architectures, requirements, and designs emerge from self-organizing teams." A team member may switch roles between specialist and generalist work. Deep work is satisfying but exhausting, so specialists may take breaks and do general work. Generalists may find a topic which interests them and want to dive deeper into it, doing deep work. Make sure your team consists of specialists in different areas and some generalists and allow a natural work cycle to take place.

Unfortuantly modern environments are not kind to specialists. Open plans, constant meetings, broad work biases and expectations of immediate response time to emails/chat applications make it difficult for specialists to do what they do best. To better understand creating the right environment for specialists see Context switching vs deep work

To make things worse there is a movement of generalists using the phrase "code monkey" as a weapon.

In the work place I have come across the belief that "If all you do is code then you are a code monkey." Due to the insulting manner of the term, developers are quick to jump up and say "I'm not a code monkey". Why is being specialized an insult. Nobody calls Renaldo a soccer monkey or refers to Einstein as a physics monkey.

I find this "code monkey" idea very narrow minded because some of the best developers I have worked with would be considered "code monkeys". They did not want to collaborate with anyone or make any business decisions, but yet they produced the most amazing code at phenominal rates. They just needed to be managed differently to obtain maximum benefit from them. It is important for the development team to collaborate with business, UX, clients and other departments to produce the best possible software. Note that I said the "TEAM must collaborate", it does not have to be every single individual all the time. While most of the team can collaborate more regularly the strong coders or "specialists" should be briefed of the decision and left alone in a room.

The term code monkey is often used by developers arogant enough to think that they know better than the specialists in business, UX, and other fields. A developer is not qualified or experienced enough to make decisions around business or UX, yet will be called a code monkey if they stick to their own field of specialilzation. There are specialists which have studied for many years, spent years working at their craft and do loads of research and investigations into their decisions... and then a developer comes along and thinks the first idea off the top of his head is superior.

Martin fowler gives an example of a developer doing his own A B testing to compare his idea to the idea of business. The story has a positive ending where his idea worked. To me that's just a fools mate, where the story is NOT proving that developers are qualified to make business and ux decisions, it's a story about a poor business department. Besides that this an anecdote which has not been my experience. In fact I regularly experience the opposite, where developers over step with poor decisions in areas which they should not be making decisions. Like I said before, collaboration yields fantastic results when everyone in the team are skilled professionals which have honed their craft. The collaboration between the dev team and business should be like a brain surgeon and electical enigineer building cybernetics, the engineer should not be telling the brain surgeon how the brain works. If that is happening its does not mean the engineer is good but rather the brain surgeon is shit at his job. Sure business should take ideas and explore them, but that does not mean a developer should be doing business or ux functions, and they certainly should not be called a code monkey if they don't. The job of a developer is to develop, not analyze business functionality or research the mind of the users, there are professionals which do those things, which are far more qualified and experienced. A company hires a developer because they are qualified and experienced in writting code. A developer can take a business specification and turn it into software. "taking a spec and just coding it makes you a code monkey. A developer knows how the software works so they should be involved in the decisions". This is absurd... Think about if other industries had this mind set:

How is it that this arrogance only applies to software development? I don't know but that's my rant.