Junk Drawer
For all those little papers scattered across your desk
Junk DrawerFor all those little papers scattered across your desk
The identified problem may be missing the mark.
Noah Snelson articulates a common theme of functional programming (FP) discussions: the (dis)advantages of hiring engineers for less-well-known FP languages. I personally appreciated the time Snelson spent crafting their article, but I’ve got one issue with it: I think they missed a class of candidates.
Snelson believes that when hiring for languages such as the fictional Gooby, you have 3 pools of applicants:
I agree that these are 3 types of potential Gooby applicants! I disagree that there’s a meaningful difference between converted undergraduates and senior engineers in the context of the article’s problems.
The senior engineers certainly have more Gooby expertise than the converted undergraduates. Snelson’s characterizations reveal that these engineers are still drinking the Kool-Aid, though:
This does not, in my mind, a senior engineer make.
All the noise of technical obsession obscures the missing 4th class of applicants: those who have the nuance of thought we expect from leaders. Those who understand that simple questions have complex answers.
The obsessed-senior problem is not particular to FP, either. Languages that encourage imperative or OO style have the same type of zealots (JavaScript, Java, C, C++, etc.). Rust has its own zealotry and is markedly harder to classify. Shriram Krishnamurthi argues that such classifications are not a useful concept: the features of a language and how they interact provides a better discussion frame. (I recommend the whole video series).
This raises the question: if you’re selecting for problematic “senior” engineers, are you selecting right? The problems of zealotry are correctly identified (my personal experience agrees), but maybe “not selecting for zealots” doesn’t mean “not selecting for language experts.” Selecting for senior Gooby engineers does not require relaxing criteria for critical thinking.
If your hiring process filters for “personnel issues” of the kind Snelson describes, then fix the hiring process. Look for candidates who consider multiple angles and respond “it depends.” “Anyone who is certain about what is and isn’t true about software is probably wrong.”
Snelson concludes by citing Cromwell and a Tumblr user as a reminder that sometimes we are wrong. Ironically, the Tumblr post’s “it depends” aligns with exactly my argument: hire developers who understand and appreciate nuance. They are probably still deep experts of some domain. Nuance typically comes from expertise.