4 ms·
Must I choose? May I choose the smarter, faster thinker with domain knowledge? :P I do not think domain expertise should be marginalized, especially when the d
by dlo 16y ago
Must I choose? May I choose the smarter, faster thinker with domain knowledge? :P
I do not think domain expertise should be marginalized, especially when the domain is deep. Someone who is smart and fast but who has only ever thought in Spring and Hibernate isn't going to be able to start collapsing strongly connected components in call graphs. There is far too much distance between a blank slate and being able to do that effectively.
And how can a person who is able to achieve mastery of a particularly difficult domain be unintelligent? Truly becoming a master at something is a rare trait. I read in _Coders at Work_ that Ken Thompson, the inventor of Unix, looks specifically for the ability to acquire mastery: He picks an item on the candidate's resume, whether or not he himself knows anything about it, and proceeds to grill the interviewee about it. He reasons that, if the candidate is unable to convincingly convey mastery to someone who is entirely uninitiated to the topic, then how can this person be an effective programmer and team mate (at Google)? On the other hand, if this very same tactic actually sets the candidate off -- that is, the candidate starts waxing romantic about the topic while deftly dispatching any technical concerns -- then not only will this person be effective but this is someone who will be a pleasure to work with.
BTW, I believe that knowing the terminology is of only secondary importance. Its purpose is to effectively verbalize fine distinctions to team mates and often serves as a marker for greater sophistication. (Note that plenty of people throws terms around _incorrectly_, often very much so; I am specifically not referring to these people.)