Although I had similar apprehensions before I started reading Hume, I have found his writing approachable. For "Enquiry Concerning Human Understanding", I found this edition with explanations of certain words/phrases by Jonathan Bennett very useful: https://www.earlymoderntexts.com/assets/pdfs/hume1748.pdf
I agree with your call to study logic. There is something systematically empirical about logic & epistemological philosophy[1].
Over the years,I have read a bunch of critical thinking books and have found myself wanting something at a lower level of abstraction. A recommendation based on recent reading would be "An Enquiry Concerning Human Understanding"[2]
It was refreshing how open he was to accepting that his research, even decades after its original publication, could have lapses and errors. Research, after all, builds on corpus of knowledge existing at the time, and we should expect corrections as the underlying base shifts & corrects itself.
This past week I read a critical essay penned by George Orwell on Wells, Wells, Hitler and the World State (http://orwell.ru/library/reviews/wells/english/e_whws). It serves as a great supplementary read to this article.
I am grateful that I did not work remote at the start of my career (it was not an option offered to me), because it would have been hard to find the self-drive & hand-holding I needed at the beginning of my career all by myself. But I agree with you; remote work is better suited for people who are accustomed to working by themselves. It might not be for everyone. And I certainly do not recommend it at the onset of one's career.
Mostly in our conversations, in an informal way. I would say the assumption we make is that developers with a penchant for any form of functional prog and/or Lisps, and with an acute focus on testing have an easy time grasping Clojure. And we bias our rubric towards this.
Also, we encourage our candidates to choose Clojure for their take-home assignment, even if they do not have any prior taste of it. This, for those of them who choose that option, gives an idea of if they would enjoy working in it. Our rubric however does not have a bias against developers who do not choose Clojure for their assignments, and we make this explicit to the candidates as well.
What we have found is that it is enough to verify 'can get stuff done', and leave out 'in the language we use'. So, much of the interview turns out to be a process of validating two things:
1. can do what is claimed in the language of choice.
2. gauge enthusiasm and interest to pick up our language.
> While Storm's Clojure implementation served it well for many years, it was often cited as a barrier for entry to new contributors. Storm's codebase is now more accessible to developers who don't want to learn Clojure in order to contribute.
It is interesting to contrast this with state of affairs in Apache Spark. Spark has thrived well in spite of being a Scala project; Scala arguably has a higher barrier for entry compared to Clojure (although the flavour of Scala used within Spark closely resembles Java).
> I also consider this a success story for Clojure.
It is a success story for Clojure, but this move is a big negative feedback for the language. A team starting out on an open-source project will be mighty reluctant to start it with Clojure; because it might get rewritten not so much into the future. That is not good news for Clojure
> A growing Clojure shop in Seattle seems to be having success with this, onboarding the language is a small fraction of overall onboarding.
I can attest to this fact, as part of a unicorn upstart with dev offices in Sao Paulo and Berlin. Clojure onboarding has never been a major roadblock for new engineers. And we never hire asking for "X years of lang experience". Almost everyone in the (~300 strong) engineering team started with zero-to-little Clojure background.
Demsetz' Theory as a framework for the economics of open source was first used in 'Coase’s Penguin, or, Linux and The Nature of the Firm' by Yochai Benkler.