I read an interview with Linus Torvalds recently and he had this to say about why he's spent so long developing Linux:
...one reason I've done it for 15+ years is that I like concentrating on something, and don't like flittering from one project to another. And I simply like doing Linux.
So, I was thinking about learning to code. (I do this far too often.) There are two ways you can go about learning and developing your skills: breadth-first or depth-first. That is, you can learn one language or family of languages or programming design methodology really really well at the expense of not learning much about others, or you can learn a lot of different ones at the expense of not quickly becoming a master of any single one. I think both will get you to the same place eventually, just as either search algorithm will find the correct node in a tree if you let it run long enough. But depending on your search space, one approach may get you where you want to go faster than the other.
So which is better? It seems like most of the "good" programmers I know or know of take a depth-first approach. In terms of producing valuable end-results, depth-first is almost certainly better. It's as Linus implies: you can pick a project or an idea you have and develop it over time and keep at it until you've produced something really high-quality, or you can flitter back and forth between projects and get a whole lot of nothing done. It takes time to produce good software. Time and patience and a long-term attention-span.
I almost always seem to take a breadth-first approach, for better or worse. I don't have the attention span to stick with any one thing for a very long period of time, but I always come back to things over and over, and each time I com back to something I seem to understand a bit more than the last time.
What about in the job world? Which is better there? At my job, I write a bunch of throw-away scripts almost every day to get things done. I'm never solving the same problem twice. I have code and modules that I re-use whenever possible, obviously, but there's often not much overlap between today's work and yesterday's work. A breadth-first approach to this kind of job is good, because I know a lot of different approaches to every problem, using a lot of different tools, and I can pick the best from among the options. If my job was to produce a complex product long-term, I'm not sure I'd do quite as well with this approach.
I'd like to be able to say that I've mastered at least one language. Ruby is the language I know best right now, but I'm not a Ruby guru by any stretch of the imagination. Someday maybe.