i.e. it made it possible to create objects without a prototype that carried the standard object methods.
I don't much care what the justification is. When you have to write hacks just to get around your linter, the problem is in your linter.
The "purple" squirrel" metaphor breaks down because real people are being hired, not "purple squirrels".
No. The metaphor doesn't break down, because I didn't say that there are no comb-shaped employees. I said that they're a stone's throw from purple squirrels. Obviously there are people out there with wide and deep experience. But the wider and deeper that you expect your candidates' experience to be, the closer you get to angling for a purple squirrel.
Now I can't say for sure but I suspect sentiments like that are a red flag for a recruiter. Because it doesn't convey a sense of curiosity/inquisitiveness in one's chosen occupational field that leads to a constant expansion of one's comfort zone and pursuit of knowledge that leads to iterative improvement of one's work.
If it's a red flag - for anyone - that I haven't happened to work in a shop that's chosen to use that particular ESLint configuration - then it definitely is a red flag. For me. Because I don't want to work for anyone who thinks that it's somehow a knock against me that my previous dev shops haven't chosen to use this configuration.
And as for curiosity, the last thing I care about is going through and learning about every possible ESLint configuration. I can learn more about... coding. Or I can memorize all of the ESLint options. I know which one I'm choosing.
And no, I don't much care about ensuring that I've covered all of the concepts in a JS book that came out 13 years ago. The "good parts" that existed 7 years before ES2015, are not the same as the "good parts" now. The language has evolved - greatly.
If it's a red flag - for anyone - that I haven't happened to work in a shop that's chosen to use that particular ESLint configuration - then it definitely is a red flag.
The comment was about call() and apply() - not no-prototype-builtins which in itself only served as a present day example for call().
The comment was about call() and apply() - not no-prototype-builtins which in itself only served as a present day example for call().
Look. I assume that we're having a cool/professional conversation here. So I'm not trying to get all pissy. But if you read the chain of messages in our thread, it goes like this:
I said, "I wasn't even aware of that (horrible, stupid, no-good) ESLint setting (cuz we've never used it where I've worked)." In other words, I was explicitly referring to ESLint when I said that we've never used it where I worked.
You then quoted, "cuz we've never used it where I've worked" and cited it as a reason why this might be a "red flag" for a recruiter, positing that it potentially displays a lack of curiosity/inquisitiveness in one's chosen occupational field. In other words, you quoted my comment about not having used a particular ESLint configuration, and used that as a basis to suggest a lack of curiosity on my part.
I then made it clear that, if my unfamiliarity with a given ESLint configuration disqualifies me for consideration from a given job - then I don't want to work there anyway.
And now you reply saying that your comment was about call() and apply() - not no-prototype-builtins. But that statement is completely inconsistent with the thread. You quoted my comment about a particular ESLint configuration and proposed that it may be a "red flag" because I'm not sufficiently curious/inquisitive.
I'm assuming that, when you quoted me saying, "cuz we've never used it where I've worked", you were getting confused about the context in which I said that. So you then replied as though I said, "I don't know/care about .call()/.apply() cuz we've never used it where I've worked." But that's absolutely not what I wrote - in any way, shape, or form.
Look. I assume that we're having a cool/professional conversation here.
Yeah, sure.
You then quoted, "cuz we've never used it where I've worked"
I quoted it as the last occurrence of a repeating pattern - in the body of the original article your stated:
but I can't honestly think of a single REAL-LIFE instance where I would, you know... USE them.
which expresses the same sentiment as the section I quoted. That said the reaction
I wasn't even aware of that (horrible, stupid, no-good) ESLint setting
is interesting in itself. Rather than simply judging the rule off the cuff there is an opportunity to investigate why it exists, discover that Object.create(null) can create objects without a prototype - at which point
it is possible to disable the rule OR
simply proceed to borrow methods.
if my unfamiliarity with a given ESLint configuration disqualifies me for consideration from a given job
Perhaps it's better to view the recruitment process less as an assessment of qualifications but more as an assessment of potential and risk. One could take the perspective that these type of questions are more suited to gauge the potential of working as a library developer or as a technical lead to more junior developers. Once the candidate turns employee, the employer may choose to "squander" that potential by having them work in an application developer role (at least temporarily).
So you then replied as though I said, "I don't know/care about .call()/.apply() cuz we've never used it where I've worked."
Again, I was responding to the general response of "I haven't used that before". In some contexts it's perfectly valid. People working with Oracle don't necessarily get curious about Postgres. But when it comes to programming language knowledge, claiming multi-year experience and not having ventured into the dustier corners may raise some eyebrows.
But when it comes to programming language knowledge, claiming multi-year experience and not having ventured into the dustier corners may raise some eyebrows.
As soon as you start playing that game, there is always some dusty corner that you haven't ventured into. I don't care how long you've been doing a given language or using a given tool/framework/whatever. So the idea that your unfamiliarity with a given feature somehow calls into question your claim of "multi-year" experience - is facetious.
I've been doing React very heavily now for about 5 years. In fact, it's pretty much all I program in. Am I the end-all, be-all expert in all things React?? Of course not. But that doesn't negate my experience. Dan Abramov can probably name 10 things about React of which I'm either unaware or only vaguely familiar. That doesn't mean I don't know how to do React. And it doesn't mean that my "claims" of 5 years of React experience are a lie.
there is always some dusty corner that you haven't ventured into.
Sure, but call() and apply() aren't as esoteric as you make them out to be.
Also my discussion isn't about assessing your personal qualifications - that's simply not my place.
But I'm trying to paint the view of someone who would rather pass over the "right" candidate than hire the "wrong" one.
I've been doing React very heavily now for about 5 years. In fact, it's pretty much all I program in.
Have they been explicit about looking for a Reactdeveloper?
JavaScript allows for some pivoting between technologies and there are lots of support technologies within the ecosystem that benefit from skills beyond React core.
I don't much care what the justification is. When you have to write hacks just to get around your linter, the problem is in your linter.
No. The metaphor doesn't break down, because I didn't say that there are no comb-shaped employees. I said that they're a stone's throw from purple squirrels. Obviously there are people out there with wide and deep experience. But the wider and deeper that you expect your candidates' experience to be, the closer you get to angling for a purple squirrel.
If it's a red flag - for anyone - that I haven't happened to work in a shop that's chosen to use that particular ESLint configuration - then it definitely is a red flag. For me. Because I don't want to work for anyone who thinks that it's somehow a knock against me that my previous dev shops haven't chosen to use this configuration.
And as for curiosity, the last thing I care about is going through and learning about every possible ESLint configuration. I can learn more about... coding. Or I can memorize all of the ESLint options. I know which one I'm choosing.
And no, I don't much care about ensuring that I've covered all of the concepts in a JS book that came out 13 years ago. The "good parts" that existed 7 years before ES2015, are not the same as the "good parts" now. The language has evolved - greatly.
The comment was about
call()andapply()- notno-prototype-builtinswhich in itself only served as a present day example forcall().Fair enough - see this treatment then:
Decorators and forwarding, call/apply
Hopefully that is more relevant in the present.
Look. I assume that we're having a cool/professional conversation here. So I'm not trying to get all pissy. But if you read the chain of messages in our thread, it goes like this:
I said, "I wasn't even aware of that (horrible, stupid, no-good) ESLint setting (cuz we've never used it where I've worked)." In other words, I was explicitly referring to ESLint when I said that we've never used it where I worked.
You then quoted, "cuz we've never used it where I've worked" and cited it as a reason why this might be a "red flag" for a recruiter, positing that it potentially displays a lack of curiosity/inquisitiveness in one's chosen occupational field. In other words, you quoted my comment about not having used a particular ESLint configuration, and used that as a basis to suggest a lack of curiosity on my part.
I then made it clear that, if my unfamiliarity with a given ESLint configuration disqualifies me for consideration from a given job - then I don't want to work there anyway.
And now you reply saying that your comment was about
call()andapply()- notno-prototype-builtins. But that statement is completely inconsistent with the thread. You quoted my comment about a particular ESLint configuration and proposed that it may be a "red flag" because I'm not sufficiently curious/inquisitive.I'm assuming that, when you quoted me saying, "cuz we've never used it where I've worked", you were getting confused about the context in which I said that. So you then replied as though I said, "I don't know/care about
.call()/.apply()cuz we've never used it where I've worked." But that's absolutely not what I wrote - in any way, shape, or form.Yeah, sure.
I quoted it as the last occurrence of a repeating pattern - in the body of the original article your stated:
which expresses the same sentiment as the section I quoted. That said the reaction
is interesting in itself. Rather than simply judging the rule off the cuff there is an opportunity to investigate why it exists, discover that
Object.create(null)can create objects without a prototype - at which pointPerhaps it's better to view the recruitment process less as an assessment of qualifications but more as an assessment of potential and risk. One could take the perspective that these type of questions are more suited to gauge the potential of working as a library developer or as a technical lead to more junior developers. Once the candidate turns employee, the employer may choose to "squander" that potential by having them work in an application developer role (at least temporarily).
Again, I was responding to the general response of "I haven't used that before". In some contexts it's perfectly valid. People working with Oracle don't necessarily get curious about Postgres. But when it comes to programming language knowledge, claiming multi-year experience and not having ventured into the dustier corners may raise some eyebrows.
As soon as you start playing that game, there is always some dusty corner that you haven't ventured into. I don't care how long you've been doing a given language or using a given tool/framework/whatever. So the idea that your unfamiliarity with a given feature somehow calls into question your claim of "multi-year" experience - is facetious.
I've been doing React very heavily now for about 5 years. In fact, it's pretty much all I program in. Am I the end-all, be-all expert in all things React?? Of course not. But that doesn't negate my experience. Dan Abramov can probably name 10 things about React of which I'm either unaware or only vaguely familiar. That doesn't mean I don't know how to do React. And it doesn't mean that my "claims" of 5 years of React experience are a lie.
Sure, but
call()andapply()aren't as esoteric as you make them out to be.Also my discussion isn't about assessing your personal qualifications - that's simply not my place.
But I'm trying to paint the view of someone who would rather pass over the "right" candidate than hire the "wrong" one.
Have they been explicit about looking for a React developer?
JavaScript allows for some pivoting between technologies and there are lots of support technologies within the ecosystem that benefit from skills beyond React core.
Interestingly the things that Dan Abramov admits to knowing don't seem to be React centric.