People ask me what is my “specialty” in software development. My specialty, if I have one, is in not having a specialty. I feel like I can contribute on any task.
That answer throws people off. They repeat the question, explaining that everyone is best at something. Managers especially like the idea of specialists because it simplifies the assignment of work: UI tasks go to the UI guys (or gals), SQL tasks go to the SQL guys, middle-tier tasks go to the middle-tier guys, and so on.
Before launching my illustrious career in software development, I worked on a union construction site. Everyone’s job was defined in excruciating detail — what each union member could and couldn’t do.
For example, if we needed to move a pallet from here to there, we had to find a teamster to drive the forklift. There were a few exceptions to that rule, depending on what was sitting on the pallet. In the exceptional cases, we had to find an operator to drive the forklift.
If we couldn’t find a teamster or an operator, the pallet had to sit where it was. We couldn’t move it. It didn’t matter how many other guys were standing around who knew how to drive a forklift.
Since then, I haven’t been a fan of specialization on work teams. It leads to some people having more work than they can possibly do while other people are standing around idle.
I’d make an exception if work demand could be guaranteed to match the available allocation of specialists (i.e., never), but if not, then give me a team of generalists every time.
Thus spoke The Programmer.