Software developers are a highly diverse group, in large part due to the wide variety of software types out there. One of the categorisations I see is how they fit on the scale between generalist and specialist and what impact this has on the kind of system you get from developers from different points along the scale.
A generalist is someone with a broad knowledge of many technical concepts, but with shallow knowledge of specific topics. At the extreme this would be someone who knows almost nothing about almost everything. A specialist has a much narrower range of knowledge, but their knowledge within this range is quite deep. At the extreme a specialist will know absolutely everything about a single topic.
These extremes are implausible and in practice developers will be specialists in some areas and generalists in others. Additionally due to the scope of software developers it is inevitable that developers will be completely ignorant of large topic areas. You can also apply the terms within a particular knowledge domain, for instance allowing someone to specialise in web development but be a generalist within this domain.
So which is best? Should you be looking for specialists or generalists, or does it really matter? Should you, as a professional software developer, focus on specialisation or generalisation? The simple answer to this is "It depends".
If you are looking to build a solution on a particular technology then a specialist in that technology is the obvious choice. A specialist will not need to become familiarised with the technology, will know the pitfalls and limitations and will generally produce a better implementation using the technology than a non-specialist.
When it comes to deciding what to build my argument (and it's probably controversial) is that specialists are exactly the wrong group to select. A specialist is going to try to fit your problem to their solution. They may produce the best possible implementation of that solution that can be built using their technology of choice. But their technology of choice may be inappropriate for the problem at hand, leading to a solution that is unwieldy, inefficient and overly expensive.
As an example, I'm going to pick on
Microsoft BizTalk Server. This is not because I think it's a bad product, I've been involved in a number of systems where it's used quite successfully. It's because I've encountered people whose immediate reaction on being handed a business problem has been "how do I apply BizTalk to solve this". What I found most concerning is that the "coolness" of the solution they implemented seemed more important than the ridiculous overengineering involved in applying something as ill-suited as BizTalk to these problems.
Before I get hate mail from BizTalk fans let me state that this is a) not the common behaviour of BizTalk experts I've encountered and b) BizTalk is a convenient example of a phenomenon I've encountered in many guises.
In my experience there does seem to be a tendency towards specialisation. Part of this is from the lower end "it's just my day job" crowd who know only that needed to do their immediate job, but we'll ignore them on the grounds that they don't meet my definition of professional. Of those left specialisation is inevitable because experience is inevitably specialised. Becoming a generalist in an area requires drawing on sources outside your current area to a greater extent than specialisation. Specialists must also draw on external sources but these tend to be more concentrated within their domain.
What route to pick in your own career really depends on your personal preferences and skills. My inclinations run towards architecture and system design, a path that demands a wide breadth of knowledge to make appropriate technical choices. I have colleagues whose interests are in specific areas, such as portals and data management. These people have specialised in these areas and know more of their implementation details than I am ever likely to. This kind of diversity allows us to draw on many strengths to produce better system outcomes.