On studying for your upcoming job: objections and replies

Here I collect objections that arose on Hacker News in response to this short argument. Thanks to everyone who replied.

Q1. "But of course studying a language is good!"

A1. Yes, it is. Mastering a language is wonderful, and being totally ignorant of the language you'll be using is bad. The question I was answering, however, is whether a given hour is more efficiently spent learning a language or a tool, supposing you want to use that hour to prepare for an upcoming job. For the reasons I lay out, and especially because it's very hard to predict which parts of a language will be used and how, studying tools is likely a better bet.

Q2. "Everyone should know [language X]."

A2. See A1. Also, here as elsewhere, you can't infer from "any programmer would benefit from knowing X" to "every programmer should learn X." The latter requires an argument that X is not just good but better than anything else a programmer should be doing with that time.

Q3. "If you ask the hiring manager how to study the language, you'll be studying just what you need."

A3. Yes, this is better than just guessing. But the hiring manager (i) might not know exactly how the language is used and (ii) often has strong incentives to oversell the quality of the existing code base. The last time I tried this, Effective Java was recommended to me. The Java I encountered was... not "Effective."

Q4. "This is just your experience."

A4. I should have been clearer about this. Although I've made this mistake many times, I'm not just writing about myself but about many other people I've seen do this. The impetus for writing this up was a person asking me what they should do to learn language X, having accepted a job offer to work in that language. So, this doesn't come out of rigorous research. But it's definitely not just me.

Q5. "But in Python, there is only one good way to do things."

A5. That's less true than people say, and less true than it used to be. (Just one example: whatever else you think of structural pattern matching, it creates more ambiguity about which is the best tool when.) More importantly, most code is not written "the good way." Yes, be ambitious and aim to improve things. But you will be working on the code base you have, which is probably not the code base in which everything is done properly.

Q6. "This doesn't apply to the very basics of a language."

A6. That's probably true, and I should have been clearer. Having some basic fluency in the languange will help. (This is a great use of spaced repetition, by the way.) But beyond "some basic fluency," the argument still applies.

Q7. "My team does use language X beautifully and idiomatically."

A7. Great! Good for you (sincerely).

Q8. "But the use of a tool is as idiosyncratic and unpredictable as the use of a language."

A8. The premise is false. There are different ways to use various tools. But it's pretty hard to study Bazel or Splunk or Jenkins or whatever without learning things that will help you basically anywhere those tools are used. Databases are, arguably, an exception here. Those get used all sorts of ways.

Home page