In Does Writing Code Matter?, I proposed that developers spend less time on the technical stuff, which they're already quite good at, and more time cultivating other non-technical skills that developers tend to lack. One commenter took issue with this approach:

I don't agree with the premise of improvement of weaknesses. I like the premise of enhancing talent and being aware of weaknesses. "Know yourself" doesn't mean go learn everything and become a Swiss Army Knife.

It's easy to take my modest proposal to an absurd extreme: either you write code all day, or you become completely non-technical and never touch a compiler again. Or maybe you spend so much time pursuing related interests that you become a jack-of-all-trades, master of none. In other words, a Swiss Army Knife.

First, a clarification. Cultivating non-technical skills is, first and foremost, about becoming a better software developer. If you wanted to be rich, famous, and get girls, then you picked the wrong profession. I'm sorry I had to be the one to break this to you.

Instead of a Swiss Army Knife, you should strive to be a generalizing specialist.

A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas. When you get your first job as an IT professional it is often in the role of a junior programmer or junior DBA. You will initially focus on becoming good at that role, and if you're lucky your organization will send you on training courses to pick up advanced skills in your specialty. Once you're adept at that specialty, or even when you've just reached the point of being comfortable at it, it is time to expand your horizons and learn new skills in different aspects of the software lifecycle and in your relevant business domain. When you do this you evolve from being a specialist to being a generalizing specialist. Generalizing specialists are often referred to as craftspeople, multi-disciplinary developers, cross-functional developers, polymaths, or even "renaissance developers".

A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few. Big difference.

Too much specialization is a pitfall of its own. Have you ever worked on projects where you had "the database guy", "the testing guy", "the web guy", and so forth? Wayne Allen refers to this as a process smell-- waiting on specialists.

A common process smell in new agile teams is more and more stories/backlog items incomplete at the end of the iteration. There are a couple of different reasons this might happen, but the one I'm interested in today can be detected by the claim "I finished my tasks". The clear implication is that "I got my stuff done, but someone else didn't".

A little additional research usually shows that people are waiting for other people with some kind of specialization such as database, QA, UI, or any other skill that isn't widely distributed among the team. As an agile team this is where specialization gets in the way. In a more traditional project the measure of delivery is the task, however, in agile projects the measure of delivery is working features. Specialists typically don't deliver working features, thus the problem. Note I am not saying that specializations aren't needed, but they do need to be balanced with other needs that help deliver features.

How do you know if you're on the road to becoming a generalizing specialist? Well, as in any good exercise regimen, you should be regularly exceeding your comfort zone. Sometimes you have to stretch a little:

The generalizing specialist is willing and able to learn new skills - to stretch as the needs of the team change. And since change is natural, this is an essential attitude for team members. However, we are usually trained, and strongly encouraged to have a deep specialty. This approach to education and training is a natural consequence to the typical organizational model for work and society. Therefore, if a team is converting to agile work methods, people need to be coached to stretch themselves and learn new things.

I see too many software developers burrowing themselves deeper and deeper into the same skillsets and specialties. It's all too easy to fall into that rut. There's an entire universe of software engineering skills outside the narrow realm of coding. To be a better software developer, grow from a specialist to a generalizing specialist.