Should developers be specialists or generalists?

Question

There has been some discussion of late within my organisation about whether we should be technical generalists - as we currently are, doing a bit of analysis, a bit of design, a bit of testing and a bit of coding - or whether we should be specialists - specialising in a particular discipline(s).

There are obviously pros and cons to each approach, particularly in a large (non-software) organisation where teams are typically quite small.

How do you think development teams are best structured? I've been working as a process analyst for the past year (the exception to the rule), and loved it for awhile but am now growing weary of doing similar things day after day and feel like being a generalist would provide more opportunities for interest and growth.

Answer 1

I think that everyone should be good at more than one thing, but it's OK if they specialize and you put the specialist in their speciality.

Think about it this way...if I'm a designer, I need to know about development and testing and QA and everything else in the lifecycle because it might impact my designs. I also need to be able to communicate with everyone else in the language they use to talk about things.

So I guess a mix of both is the way to go. You don't want people so general that they can't do a specific task really well, and you don't want people so specific that they can't handle tasks outside of their specialty.

Answer 2

I think the generalist approach is best. It is more flexible, in case someone decides to leave the team. Also, it makes the job way more interesting, and it adds to the value of the team if everyone has at least some notion of the bigger picture of your development pipeline.

This doesn't mean people can't be specialized, but the should at least be able to do several (or each) of the aspects.

Answer 3

It depends what you want out of a career.

I have gone down the consultant / contractor route so I have become a bit of a generalist to maximize potiential income. I get a buzz by learning new technologies and languages so sticking to one area wouldn't suit me.

But I can see how being the expert in a certain area would be great too - just don't pick an area likely to die off. I've worked with plenty of Cobol or Informix or RPG developers over the years who have hung on too long and have become virtually unemployable unless they retrain.

Answer 4

I think there is room for both, but it does depend on the technology.

Web development in particular, I think is something that is best served by generalists, since there is a fairly broad overlap of usability and interaction design skills necessary to build good experiences, not just coding chops.

On the other hand, stuff like VM architecture, hardware, optimization, compilers, etc... is best served by specialists, since there are so many minute details in each area, that a generalist who flits between different skills will never have the same intimacy and day-to-day experience with deeper areas of knowledge.

One thing you might want to consider is roles vs specialties. It's possible for generalists to still assume a very specific role on a project, and maybe swap roles on subsequent endeavors. In reality, I think if you're already working as generalists, it may be too late... you just never stop learning new things.

Answer 5

I think it depends a bit on the company that you're at...

Consultancy Be a specialist... why? Let Seth Godin explain that to us.

Small company In a small company it's usually better to be a generalist. That being said I do not mean to take this to the limit, but as for a programmer one should be able to do some design, testing, SQL, insert your favorite programming language here etc.

Big company If you're in a big company I think (at least for a software development company) it depends on the methodology that is being used. For the more Agile methods a team of good generalists is best. When a more 'classic' approach is being used about 50% of specialists and 50% of generalists is (imo) the way to go.

Answer 6

This is a great topic. I think development teams are best built by having at least one string generalist on the team. The rest of the team may be better served by including specialists and/or building specialization in the other team members.

I did notice that your original question is more focused on generalization in terms of roles played on a team as opposed to technology strengths or focus:

... as we currently are, doing a bit of analysis, a bit of design, a bit of testing and a bit of coding ...

I have often heard this discussion around specialization within a particular technology or space. E.g. "Should we have a generalists around .Net or specialists for WCF, WPF, ASP.Net, etc, etc."

Answer 7

You could always specialize in being a generalist.

Answer 8

Maybe the answer is to be a generalising specialist? Multi disciplinary craftspeople?

Scott Ambler talks about this here

Answer 9

I'm a strong proponent of the generalized approach, but I also recognize that any good company needs a healthy mix. For me, I like to have a broad knowledge not only across different technologies but also across different aspects of our business. I find it makes me more valuable as a resource, gives me more opportunities, and keeps me energized. I can't stand doing the same ol', same ol' every day.

Some of it depends on your position/role, too, and what you want out of your career. I know a lot of people who just want to play with technology. They're good specialists. I know others who have gone into management or become architects. They're good generalists.

IMHO, being a generalist opens up a broader range of career opportunities.

Answer 10

Both. Being a specialist means you know a lot about a particular subject. It doesn't mean you know nothing about anything else.

That's what Chad Fowler says in My Job Went To India.

The two relevant chapters are free downloads (PDF):

• Be a Generalist
• Be a Specialist

(The book has been superseded by The Passionate Programmer. It's chapters 7 and 8 in that book. The two links above, from the first edition, are still available as of this writing.)

Answer 11

See also http://stackoverflow.com/questions/122493/is-it-better-working-on-a-single-technology-or-working-on-different-ones

Answer 12

If there is only one specialist at each type of work, e.g. analyst, designer, programmer, tester, and that person wants to go on vacation for a month, what happens? This is a nicer way of stating the "If so-and-so got hit by a bus before tomorrow, how bad would it be" sort of situations.

In a really large organization where there are typically multiple people on each type of work, then specialists can be great without a lot of risk. As you shrink the size of the department doing this work, it becomes a bit more challenging if there is say one analyst who has to do analysis for a handful of projects where there are developers waiting to code. The need for versatility increases but generalists can be somewhat vague as there is the generalist that does a bit of everything and then there are those that have 2 or 3 areas that they are fairly comfortable handling. The other issue is how well does the team know the architecture of the company's internal big back-end systems, e.g. Enterprise Resource Planning, Customer Relationship Management, Supply Chain Management, Content Management System, as if there were only 2 people working in the department developing that are still there years after the company started, they may too many things as they can solve some of the issues quickly by remembering various tricks and hacks that were done to fix this issue or that one that came up.

The structure of development teams can vary dramatically in terms of what is optimal. For some small projects like building a simple web form to add or edit data in a database, this may take one developer a couple of days to go from initial thought to specification to design to implementation to testing to deployment. On the other hand, if you are replacing thousands of pages by changing the content management system your company with a dozen web sites each sporting hundreds of pages, then one developer may take a while to get things done.

I'm reminded of the 3 sides to a project that determine the quality: Time, money and people. Some projects can use more money to buy a better piece of technology like a machine or some off-the-shelf software to get things moving more quickly than if the company built their own solution. Time and people are obvious ways to impact a project in good and bad ways as has probably been written about over and over again elsewhere.

Answer 13

I really like this question so I'll put in an "answer" even though the question is old and it will be lost forever.

At first I thought, "what a stupid question, if everybody is a generalist then nobody will know the intimate details of anything to be able to solve the hardest problems." However, most of software development is not about "hardest" problems but rather about problems. These problems usually have multiple (or infinite numbers of) solutions, stretching all the way back to the design of the context in which the problem occurs (the architecture, really). So I think -- and this is what I've done through the years -- that you should aim to be a generalist at heart.

That said, there are limits to what you can know well at one time. For my own software, I do everything from the cheesy "marketing" to the talking to the web hosts, the "getting my computer to run," and then all the architecture, Web design and all the programming from the DB to the front end, deployment design, packaging, deployment... And I think that there are probably DB experts who run circles around me, but the application is developed as an integral whole, and the concepts are consistent at all levels of coding.

But your question really translates for me to, "would I rather have 5 more people like me, or 5 guys with different skills?" So if somebody would just give me the money to try this experiment for 6 months with a "control" and "experimental" team (I know what we'll build), I think I could really answer you better :)

Answer 14

A human being should be able to change a diaper, plan an invasion, butcher a hog, design a building, conn a ship, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve an equation, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

Robert A. Heinlein

Answer 15

in general, be whatever you want to be

to be specific, concentrate on what you enjoy most and/or seem to do best; hopefully these are the same thing

for the OP's specific question, increasing specialization in the team as proposed would greatly inflate the "bus factor", so it might not be a good idea (at least not without some cross-training) for the enterprise to take that approach. From the developer's perspective, it might not be much fun, either, being pigeonholed as an 'analyst' when you yearn to code - or vice-versa.

In truth, most people are neither one nor the other - unique experiences give us insights into areas that others may not have; this gives the appearance of being a "specialist", but the term itself implies limits that are usually not appropriate. You may have recently done a lot of difficult work with regular expressions in Perl; does this make you a Perl RegEx Specialist, or is it just an interesting facet of your general abilities? I submit that it is the latter - we are all generalists, in that we use tools to solve problems. So a "specialist" would be someone who only knew a few tools, and was best at a certain kind of problem. There are people like that, but the vast majority of developers that I've met are not so limited.

The comparisons are almost always relative, but sometimes they are quite stark: on a project a few years ago we had a kick-off meeting so everyone could meet everyone else before we went back to our home offices (all across the USA) to start work. The lady to my left was an AI programmer specializing in Lisp and image recognition that had recently worked with Marvin Minsky and Richard Feynman at Thinking Machines Corp. The gentleman to my right developed the guidance system for the Apollo rockets - yes, a real rocket scientist! The rest of the team was equally impressive, and everyone had a unique specialty that made it obvious why they were present on the team. After a few minutes of sitting there thinking "I am not the smartest person in the room here by far, why am I here?", I realized why I had been invited to join the team - compared to those around me, I was the token generalist!

This turned out to be a great thing to be, because I got to work some with everyone and it forced me to learn at least a little bit about what everyone else was doing, how it worked, and how it integrated with everyone else's work - with the net result being that while the specialists learned some new things and improved their skills a bit, I learned a lot about a great many things. When the project ended I was still "just" a generalist, but I left with a much bigger bag of tricks than I came in with.

So, I like being a generalist - you get to have a lot more fun!

Answer 16

My experience has been that you're going to have to to both:

Specialize: You'll have to pick more than one technology. Employers/Clients don't typically like folks with only one or two skills.

Generalize: You can't possibly know everything, but know as much as you can (Specialize) and know as much as you can about those things you know as much as you can about. {-o)

Answer 17

The question appears to be a bit loaded in that it asks if a person should be a specialist or a generalist, and most of the answers here seem in congruence with being both. I think the best way I've heard this defined is "Developers should have a T-type skill set - a shallow understanding of a lot of different skills, but one or a few skills that you know intimately well."

We adhered to this at the last place I worked at, a web development consulting shop, and it worked really well. Every developer was responsible for writing code, from SQL at the backend all the way to JavaScript on the front-end. People excelled differently in different areas, and through various "Programming Nugget" meetings and emails, the cumulative knowledge would permeate. The knowledge transfer was like a localized, ad-hoc StackOverflow - confined to the domain knowledge of web development, but a cumulative ignorance that we collectively improved upon.

I've only worked for small shops and I think this works admirably in these situations. My current workplace employs partitioned skill sets amongst the developers, and that places explicit bottlenecks on people when certain skills are required. In a small company when being able to be flexible is important, this rigid skill structure creates roadblocks that slow the entire development cycle when someone is sent bombarded with high-priority tasks that no one else can manage.

Learn something well, but be cognizant of everything else that goes on around you, and you'll be just fine.