Generalist Vs Specialist
Generalist: Someone who knows every/most areas of the development cycle frontend, backend, database, devops, management, business, ux, etc. Specialist: Someone who focuses on a single area of development and goes very deep into that topic becoming an expert in it.
In software engineering there is two types of work required:
- Broad shallow work: best done by generalists (full stack developers)
- Deep work: best done by specialists
Examples of broad shallow work:
- Minor production fixes like a service has stopped and needs to be started
- Putting existing pieces together frontend, backend, cicd, database, etc
- Most communication eg Meetings, emails, chat apps, etc.
Examples of deep work:
- Software design and architecture
- Complex problems
- Single massive task
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?
- Generalists see the big picture and are able to bring the pieces together.
- Generalists keep the boat floating no matter what and generally take on any task.
- Generalists are able shield and manage specialists.
Why have specialists?
- Specialists dive deep into topics and understand the finest details.
- Specialists solve major problems and are innovative.
- Specialists are able to make the individual moving parts easy for generalists to use.
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.
Forcing specialist to becomes Full-Stack
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
I have worked at small companies and worked on my own projects where I work as a full-stack dev. When working full-stack I do the frontend and backend dev work, the QA, the database admin, the DevOps and server setup. I have no problem working on peripherals and enjoy being able to do everything myself but is this good for a large company of for a team?
|Only Full-Stack Pros/Cons|
More handsFull-stack developers can help other members when they need help. for example if the DevOps load is too much, then a full-stack developer can jump in and help because he knows a bit of DevOps.
Waste of resourcesFull-stack developers may be able to help outside of their specialized field but that means they are not doing what they are specialized in which is a waste of resources. Where a specialist could be focused on constantly reaching new hights within his specialty, instead he may be distracted by having to learn the basics of other areas.
Shared knowledgeFull-stack developers need to learn a little bit about everything which promotes knowledge sharing and allows members within a team to work together more coherently. Because each member is more aware of what other members need to do, they are able to work on better solutions from their side.
Inefficient and Reduced qualityFull-stack developers will be doing peripheral work slower and more inefficiently compared to their specialized counter part. Full-stack developers won't have the specialized skill in every area, therefore a specialist will produce better quality. A simple analogy: Do not hire the best brain surgeon in the world to look at a paper cut. A paper cut example is way too ridiculous but where do we draw the line of what you should use a brain surgeon for? Can he assist with your flu or with heart surgery? Or would you rather hire a GP for your flu, and heart surgeon for your heart? I would not like to hear "the Brain surgeon is busy, so the heart surgeon will do your brain surgery".
To make things worse there is a movement of generalists using the phrase "code monkey" as a weapon.
Stop saying code monkey
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:
- Construction workers would say they are not just construction worker monkeys and would tell the architects they should put a balcony on the third floor.
- You would send your product design to a factory for production and a factory worker would come back to you and say he is not just an assembly line monkey, and your product would look better in red.
- The burger flipper at mcdonalds would say he is not just a burger flipper monkey and tell the franchise they should put banana on the burger.
How is it that this arrogance only applies to software development? I don't know but that's my rant.