I believe there are three types of developers.
When you think of it, you probably divide this working group into Front-end, Back-end and Full-stack specialists, while I would like to categorize them differently, not based on technology but on their approach to coding and how they answer the question: What for do you code?
Type no. 1 will answer: to learn how this technology works.
I will call this group Experts. Those are developers who pick a single technology and invest time and effort into knowing every single aspect of it, all its advantages and disadvantages, security holes, performance issues and so on. Their goal is to become masters.
Type no. 2 will answer: to learn how to build a good application.
I will call this group Designers as those are developers who do not care about the technology itself, but how applications are built. They will learn a lot about application design patterns, new architecture standards and ideas. Technology itself is not so important and will be picked depending on the context. Design and doing things right do matter.
Type no. 3 will answer: to solve business problems.
I will call this group Problem Solvers. Those are developers who do not care about technology nor design patterns as such but are rather focused on solving business challenges with the right application of the right technology. Technology and architecture are only treated as tools which are used to build a working solution. They will invest time into understanding the business and doing the right thing. (About the difference between doing things right and doing the right things, see here)
Is there any type better than the others? No!
Should scrum teams compose of representatives of one group only or maybe contain all of them? No!
It is although important to realize these types, because depending on the scope your team works on, some may just fit better.
If your dev team implements out-of-the-box systems, it is better to have more Problem Solvers. The most important challenge for them will be to figure out how to best address business problems within frames given by the already existing solution. They will also not get bored too quickly – business challenges may be of the same interest for them as technical ones.
On the other hand, when the team creates a brand-new custom product which will serve millions of users, then having Experts who can tune application to its limits is important. To keep them engaged you need to feed them with purely technical problems, which can be solved using technology they know.
Designers should mostly support teams which cover multiple domains and where the flowless communication between different components is a key. They fill in the space between Experts and Problem Solvers. What drives them is high-level application design, integrations, and architecture.
Thinking of the team you work in – how is it composed?