Those concerns are orthogonal to the type of mastery Rich is talking about.

If neither of your developers has mastered software development, it doesn't matter which you pick - they're both going to need a lot of training and handholding.

If they have both mastered software development, then you may as well pick the specialist if you have a specialised task, or the generalist if you have a general task.

The point is that someone's ability to add business value (or practical value if you aren't in a buisiness, maybe artistic value in some settings) isn't a function of their programming languages and platform experience.

Realistically, nobody has mastered programming because they 'know X platforms'. All that experience guarentees is that they can reach their skill cap really quickly in any setting. This means nothing. It might even be a negative value-add if their skill cap is low enough. More information is needed to say if they are good programmers.

I agree. If you have someone who shows mastery in one area, you see what level they can attain. With a generalist (assuming no mastery), it's a gamble. They might not be able to master anything.

This article has an idea of what a "Better Developer" is, which is kind of like a True Scotsman that must eat Haggis (or not!).

If you are hired as a developer you may be useful to have a "smorgasbord" of experiences, depending on the role. Working for a small company needing to hack something up quickly. Oh you've used AWS, Azure, React, Node, Haskell etc. You can pick the best tech for the problem. Someone who has only used C++ but 'gone deep' might be less useful here.

OTOH the C++ girl/uy might be more valuable in another company / team, whatever.

>This article has an idea of what a "Better Developer" is, which is kind of like a True Scotsman that must eat Haggis (or not!).

Nope. It's not even about being a "better developer". It's about being (and becoming) a master developer.

>If you are hired as a developer you may be useful to have a "smorgasbord" of experiences, depending on the role.

Then that company doesn't need a master, but just a generalist that can wear many hats with some competence.

>Someone who has only used C++ but 'gone deep' might be less useful here.

Which is neither here, nor there. The advice is how to become a master programmer (e.g. in C++), not how to become useful in a company that needs devs to tackle many roles.

You can’t ever be a master if you worked for the whole life in the same programming language doing the same thing. You will be a narrow-sighted, maybe even very good, C++ developer that thinks to be a master. A master has to have a huge amount of experience in a lot of different problems, domains and programming languages. Otherwise he is just a specialised plumber, it won’t have the wide experience needed to engineer any kind of system.

>You can’t ever be a master if you worked for the whole life in the same programming language doing the same thing.

The "doing the same thing" part, you added it.

You can very much be a master if you "worked for the whole life in the same programming language" and doing multiple things with it.

But even limited to a narrow scope, you can also be a master C++ programmer doing only games programming or network services programming.

You don't have to do some of this and some of that to become a master programmer.

You might not have the domain expertise to write a database or do DSP, but a domain expertise is something different from C++ mastery.

You’ll never be a master because you are missing a lot of solutions, paradigms and techniques that are common in other languages and that you will never learn staying forever in the same language. Also I would like to see how you can become a master in web development using C++. You will always be castrated compared to someone else that has a much vaster experience with multiple languages and domains.

I think I can support this notion with something a little more concrete. I program C++ (13 yrs) and I learned javascript and web dev 8 years ago. don't consider myself a master at either. But, having broad coverage over and aptitude in both of these realms has had a huge impact on my ability to make an impact in the real world, working at a robotics company that heavily leverages these technologies. There are large rifts between teams that form due to the relative scarcity of "cross-pollinated" contributors.

I think that Linus Torvalds is a master of operating system development, even though he's done all his work in C. And I'm pretty sure that he doesn't care about ever being a master in web development (just as most web developers are probably not interested in becoming kernel developers).

It's an odd analogy. Musicians frequently advance by learning multiple instruments and genres. Your drums example is good, and there are lots more. Piano's a very common instrument to start with, because it teaches you a bit of everything: rhythm, melody, harmony, coordination, sight reading, and leads easily into learning music theory, and musicians on all instruments often have a piano background. I don't know a single concert violinist that isn't at least competent at strumming out a few chords on an acoustic guitar. Woodwinds players often follow a path of increasingly difficult embouchures, e.g. recorder -> flute -> oboe.

And learning varied "easy" pieces is exactly how anyone practising one instrument advances! The whole grades system used by the RCM is founded on that idea. What's "easy" to you at the time increases slowly with practice, but you learn a variety of pieces in a variety of genres that's at the level you're currently comfortable with.

If someone's going to pick an analogy, they should make sure it doesn't support the exact opposite of the point they're trying to make.

Let's say chess players don't get to top level by playing checkers or Go ;) Actually some grandmasters do, eg. Ivanchuk does play checkers and Morozevich does play Go - and it may have mildly beneficial effect, broadening your horizons etc. - but it's not the primary training you need

That is because unlike programming, chess nowadays does not utilize too many general skills. Good positional play for instance won't help you enough against an opponent who has memorized many patterns. This is why it was so easily tackled by computers compared to Go or more complex grand strategy games.

Programming is much closer to grand strategy than to rote pattern memorization, though there are patterns to be recognized in it.

Likewise performing music is a much broader subject than say just moving the pick across strings to a remembered melody. Even more so, composition.

Someone who's bilingual can have meaningful conversations in both languages. Beyond that they can see the connections/differences between the two languages and gain a deeper understanding.

However someone who's learnt 15 can probably only order a coffee in each one.

>However someone who's learnt 15 can probably only order a coffee in each one.

Talk to Ioannis Ikonomou who's considered to be good at 32 languages and has cursory knowledge of a few more: https://en.wikipedia.org/wiki/Ioannis_Ikonomou

He's even a certified Chinese translator, and that was one of the later languages he learned.

I think you'll be surprised if you go to Europe how many people you'll find who can do a bit more than order coffee in at least 5 languages.

Or in Africa. It's very common, depending on the country, to know 2 or 3 colonial languages and then speak a handful of different tribal languages on top of that. And all very competently. It's simply a necessity of life in a lot of places.

I did say 'probably'. If someone can speak more than 12 languages they're a hyperpolyglot. You'll probably find as many living Nobel Prize winners as hyperpolyglots.

Plus I live in Belgium and my partner speaks 5 languages.

I think the comment still stands for most mere mortals.

Yeah, I agree, most people can't speak 15. But more than bilingual is very common at a somewhat good level.

Most people I've met who have studied 10+ languages learned at least two or three to fluency before they developed a "language collecting" habit. But one does come across the occasional total dilettante, too.

First try several things to find something you like, then focus on one thing to become good, then go back to trying out several things to get better at your general skill.

But don't:

- jump on the first tech/instrument. It's a lottery.

- keep changing again and again. You'll never develop mastery. There is so much you can do by being a jack of all trade.

- stay on what you master and never go out of your comfort zone. Still will make you stale.

I wouldn't. The code I wrote as an experienced backend engineer is much nicer and easier to understand compared to someone generic who knows the basics but not the finer details of the language.

Musical instruments don't change nearly as much as programming frameworks, environments etc.

How many will become obsolete during a musician's career? When is the last time grand piano underwent a significant upgrade? : )

Latest update on the general idea was somewhere in 80s with the advent of polyphonic multitimbre keyboard synthesizers.

If you go to music school to learn violin, saxophone etc. you will have mandatory piano class, but pianist won't have mandatory violin class.

This is mostly because solo violin does not teach enough coordination. Though concert performance practice may help with that it is still less involved. Performing sequentially compared to parallel.

Accordion is closer but still rarely uses polyphony.

I don't think this has anything to do with coordination. Piano is considered the master instrument. You can pick something which require more coordination and you still need to take piano lessons.

It really depends. Sometimes a specialised developer would be more helpful than an general developer.