October 24, 2006
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.
Posted by Jeff Atwood
The "MacGyver and a paper clip" extreme isn't Jeff's point, but you're close; McGyver built what was needed out of what was available. You should be able to do the same so you don't have to depend on others anytime you have to step outside your specialty.
No wonder programmers like McGyver, I always thought it was the mullet. ;)
From yesterday: Programmers should become good technical writers, because it's the process of fitting ideas into the fewest words, without becoming cryptic. Coding should be the same: Simple, easy to follow and skim, not too wordy or too terse. Sidebars for complexity and tangents.
One problem with the McGyver analogy though... and it goes back to another favorite quote of mine:
"When your only tool is a hammer, every problem looks like a nail."
Or something close to that. The point is that if you limit yourself to very few tools, then yours solutions are less likely to meet the requirements that are presented to you. That's not to say that you can't do it... but the solution will often times be far from satisfactory.
As a wealthy programmer with a surplus of girls, I must contest your derision of our profession's ability to get laid. I think its more of a question of our personal qualifications than our business savvy, which might actually have something to do with the common occurrence of single-minded programmers, and the lack of robust and intuitive code. Though I agree with your general theme!
well what the heck is wrong with being a swiss army knife?
i think that metaphor is a total compliment. i think a swiss army knife style and a balanced approach to technical and soft skills can land you at "jack of all trades, pretty damn good at most.. able to master when needed" :)
I'm reminded of one of my favorite quotes...
"Every man gets a narrower and narrower field of knowledge in which he must be an expert in order to compete with other people. The specialist knows more and more about less and less and finally knows everything about nothing."
- Konrad Lorenz
Screw the article, where can I get one of them swiss army knives? ;)
It is not a one size fits all.
Knowing your strengths and weaknesses helps you move in the direction where you can be the most effective. And guess what? Being a “Swiss-Army-Knife” may be somewhere, at some point in time the most effective.
The important thing is to be effective in getting/doing what you like and that may not fit any model or recipe of success.
One aspect that is missing:
The generalizing specialist is willing and able to learn new skills - to stretch as the needs of the team change.
What I've seen happen too often is that "learn new skills" really means "jump on the latest brain damaged bandwagon". I offer XSLT, and most everything related to xml. The XML database is especially offensive. But then, I know how databases really work. The lemming masses don't, but are willing to follow people like Ambler.
We're supposed to be smarter and better informed on technology. We're supposed to be able to call BS when needed. We don't. Mostly, we just follow the au courant trend.
Learning means more than learning French words; it means being able to write Proust as well as he did.
I think the best approach is, serve you client, user and customer, improve in the way that you can help them better.
"Cultivating non-technical skills is, first and foremost, about becoming a better software developer"
I would go so far as to say cultivating skills such as writing and speaking is about becoming a better person, something worth striving for regardless of profession
"If you wanted to be rich, famous, and get girls, then you picked the wrong profession"
I think the best analogy is a mix of Don and Buggy Fun Bunny: the key to finding new solutions is understanding why existing solutions work.
You could say McGyver didn't look at a paperclip as a paperclip, but as a handy length of wire with certain useful properties.
Similarly, BFB's standby rant is that very few people actually understand how relational databases work, or even the problems they were created to solve. Rather than seeing databases as powerful tools, they instead are faced with yet another pile of frameworks to learn and data interchange problems to solve. Like a McGyver wannabe who understood that paperclips could be useful but tried to utilize them by turning every problem into a stack of papers.
Hysterical that you wrote a blog entry complaining about "direct-link image bandwidth thieves" (http://www.codinghorror.com/blog/archives/000561.html) , showing how to prevent this and then steal image bandwidth yourself in this blog post. Unless you happen to be affiliated with outdoorlife.com?
You're misreading the image-- look again. The hyperlink takes you to the site, the actual image is hosted here.
Hmmm ... you're right, I'm wrong. Sorry.
Although McGyver had a swiss army knife, he was the master of paper clips.
One man, one tool - the paper clip.
An ordinary man can use a paper clip for example to clip papers together. But McGyver could use a paper clip in myriad of applications. He knew science and tricks, and a paper clip was just a tool.
So is it better to 1) be a master of loads of science and to have a simple tool with which you can do different kinds of tricks? Or is it better to 2) have a big library of different kinds of tricks, that you try to master?
Of course, if you know all the tricks in your library, then it would be handy. But what if you have to change the tricks in order to make new tricks? Well, then it would be better to have just one simple tool that does not need to be changed. You just make new tricks based on your knowledge of the science, and the simple tool suites everything you do.
McGyver did not see every problem as papers when he used paper clips.
Maybe a problem would be, that when it comes to programming, there is just lots and lots of libraries available from what to build. McGyver had limited amount of stuff and he still built amazing things. Surely he was in some odd situations and normally there would be more stuff around as building material. But too big libraries can be overwhelmers. I really do not need too much building blocks, I need just what I need to accomplish some tasks.
Often I find some libraries or programs too limiting. Some fancy programs offer great features, and still those programs are dumb in some way, and that makes me nervous. And there are the bugs, too. Few simple tools would be very very tested and functional.
Specialists are not needed for common work, but we still need specialists, too.