May I suggest: you say you vaguely know .call or .apply or IIFE because they don't have use in real life.
May I suggest that it could be the opposite? Because you don't know them, they are not part of your toolbox and thus you're not using them.
In a former job, I was not using .reduce or .map and co. because I found them "too complicated to read". My coworkers forced me to rewrite my clumsy loops into proper readable .reduce or .map and improve my game. I ended up using them all the time.
Another time, 2 coworkers "forced" me to learn how to rebase git branches. I couldn't see the point. Well, now I'm using it ALL the time.
While I'm not using .call or .apply or IIFEs often, I still use them at least once every few monthes.
I think everybody should set aside hour or two here and there to check out new bells and whistles they didn't try before. When I find something that I didn't use before I set some time to read about the feature and then try it to see if it can be useful for something I usually do. It is always good to know that something exists so when you face some weird problem, you know you have one more tool in your toolbox to consider.
Sometimes it provides value, sometimes it is about just playing around with the things you didn't play before.
Curiosity is a great thing to have!
and yeah, git rebase.... I postponed that for way too long! Will play with it today!
I actually agree with you. And at the risk of sounding a wee bit nitpicky here, I'll point out that I said, "I can't honestly think of a single REAL-LIFE instance where I would, you know... USE them." Notice, I didn't say, "There is no use for these tools whatsoever." It's a subtle difference - but an important one.
The key here (in my mind) is that you can ask someone in their next JS interview about .call() or .apply() or IIFEs, but it shouldn't be much of a distinguishing factor about whether you want to hire that person - unless you're actually screening for a job that has an unusual focus on those tools.
I totally understand that sometimes, the tools we dismiss as having no use, are simply the tools with which we're not comfortable. And am I guilty of that at times? Of course I am. We all are.
But imagine that you never got to meet those 2 coworkers who "forced" you to learn about rebasing - because the interviewer asked you to demonstrate rebasing during your interview. And then, when you couldn't, they eliminated you from consideration. Not knowing about rebasing didn't mean that you were a poor developer and it didn't mean that you should've been eliminated from consideration for that job.
One of my big pet peeves about the tech hiring process - at nearly any company - is that the interviewers pick a handful of esoteric concepts and decide to use them as a litmus test for the candidates' abilities. And that's fine. They have that right. But it will end up eliminating some of their best candidates (which, coincidentally, was the central point of the first article that I ever wrote on this site).
Re-thinking developer experience • Product @Gitpod 🍊 Helping folks get their start in cloud • @openupthecloud ☁️ AWS Community Builder 🛠 Replies in GIFS 😃
"interviewers pick a handful of esoteric concepts and decide to use them as a litmus test for the candidates' abilities. And that's fine"
This is sadly, very true. Developers learn a concept, feel superior, then use that as their test for others, but if turned around the other way I'm sure the developer on the other side of the table knows some equally puzzling or tricky and esoteric questions. A very irritating aspect of tech hiring for sure.
This is exactly why we focus our dev interview around a creative coding challenge that forces the candidate to learn a new concept and apply it with a ton of wiggle room around how they want to approach the task. We just give some general goals to accomplish in the project, then we discuss how they solved the problem without nitpicking the tools outside what we asked them to demonstrate.
We also give them an appropriate window of time on their own to research the new concepts so that it's not an on-the-spot stressful thing.
Same here. I now use Array.prototype functions frequently. But too often, I first start out with .forEach() and then, once I've written the dang thing, I look back at it and think, "Oh... wait. This should really be done with map/filter/reduce/whatever." Then I spend a few minutes refactoring it.
Re-thinking developer experience • Product @Gitpod 🍊 Helping folks get their start in cloud • @openupthecloud ☁️ AWS Community Builder 🛠 Replies in GIFS 😃
Very rarely, if ever does something need to be a .forEach as opposed to a reduce/map etc. That said, as much as I do love functional (and functional-esque) programming, other languages do advocate for just using humble for-loop, and I see their point, it's not evil.
Oh, I totally agree! The thing is that my old-skool brain just kinda "fits" naturally into loops. So when I'm first thinking through the solution, I often reach for the forEach as the first thing out of the toolbox.
You're absolutely correct that a for loop is not "evil". But I've also learned that, as you pointed out, something rarely needs to be a forEach. And when I fall into a lazy habit of submitting code that's littered with forEach loops, the other devs on my team tend to notice (rightfully so).
So rather than beat myself up over it, I just write the logic the way it first "appears" in my brain. Then I give it a once-over, and I might refactor some of those forEach loops if they don't feel optimal. (And as you said, they rarely are.)
I used to be this way about ternary operators. I would write everything with traditional if/else, then I would look at it and think, "This should be a ternary" - so I'd change it. It took quite a while, but now I pretty much "think" in ternaries. I'm not quite there yet with all of the Array.prototype functions - but I'm definitely a lot closer than I was several years ago.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good post!
May I suggest: you say you vaguely know .call or .apply or IIFE because they don't have use in real life.
May I suggest that it could be the opposite? Because you don't know them, they are not part of your toolbox and thus you're not using them.
In a former job, I was not using
.reduce
or.map
and co. because I found them "too complicated to read". My coworkers forced me to rewrite my clumsy loops into proper readable.reduce
or.map
and improve my game. I ended up using them all the time.Another time, 2 coworkers "forced" me to learn how to rebase git branches. I couldn't see the point. Well, now I'm using it ALL the time.
While I'm not using
.call
or.apply
or IIFEs often, I still use them at least once every few monthes.Let's be open!
I think everybody should set aside hour or two here and there to check out new bells and whistles they didn't try before. When I find something that I didn't use before I set some time to read about the feature and then try it to see if it can be useful for something I usually do. It is always good to know that something exists so when you face some weird problem, you know you have one more tool in your toolbox to consider.
Sometimes it provides value, sometimes it is about just playing around with the things you didn't play before.
Curiosity is a great thing to have!
and yeah, git rebase.... I postponed that for way too long! Will play with it today!
I actually agree with you. And at the risk of sounding a wee bit nitpicky here, I'll point out that I said, "I can't honestly think of a single REAL-LIFE instance where I would, you know... USE them." Notice, I didn't say, "There is no use for these tools whatsoever." It's a subtle difference - but an important one.
The key here (in my mind) is that you can ask someone in their next JS interview about
.call()
or.apply()
or IIFEs, but it shouldn't be much of a distinguishing factor about whether you want to hire that person - unless you're actually screening for a job that has an unusual focus on those tools.I totally understand that sometimes, the tools we dismiss as having no use, are simply the tools with which we're not comfortable. And am I guilty of that at times? Of course I am. We all are.
But imagine that you never got to meet those 2 coworkers who "forced" you to learn about rebasing - because the interviewer asked you to demonstrate rebasing during your interview. And then, when you couldn't, they eliminated you from consideration. Not knowing about rebasing didn't mean that you were a poor developer and it didn't mean that you should've been eliminated from consideration for that job.
One of my big pet peeves about the tech hiring process - at nearly any company - is that the interviewers pick a handful of esoteric concepts and decide to use them as a litmus test for the candidates' abilities. And that's fine. They have that right. But it will end up eliminating some of their best candidates (which, coincidentally, was the central point of the first article that I ever wrote on this site).
"interviewers pick a handful of esoteric concepts and decide to use them as a litmus test for the candidates' abilities. And that's fine"
This is sadly, very true. Developers learn a concept, feel superior, then use that as their test for others, but if turned around the other way I'm sure the developer on the other side of the table knows some equally puzzling or tricky and esoteric questions. A very irritating aspect of tech hiring for sure.
Well said.
This is exactly why we focus our dev interview around a creative coding challenge that forces the candidate to learn a new concept and apply it with a ton of wiggle room around how they want to approach the task. We just give some general goals to accomplish in the project, then we discuss how they solved the problem without nitpicking the tools outside what we asked them to demonstrate.
We also give them an appropriate window of time on their own to research the new concepts so that it's not an on-the-spot stressful thing.
BINGO!
Pretty soon, I'm going to do an article on how I want to do interviews - and it's basically what you're describing here.
I'd love to hear how you are improving your reduce and map. I do use them, not sure I feel I really like how I use them...
Same here. I now use
Array.prototype
functions frequently. But too often, I first start out with.forEach()
and then, once I've written the dang thing, I look back at it and think, "Oh... wait. This should really be done with map/filter/reduce/whatever." Then I spend a few minutes refactoring it.Very rarely, if ever does something need to be a
.forEach
as opposed to a reduce/map etc. That said, as much as I do love functional (and functional-esque) programming, other languages do advocate for just using humble for-loop, and I see their point, it's not evil.Oh, I totally agree! The thing is that my old-skool brain just kinda "fits" naturally into loops. So when I'm first thinking through the solution, I often reach for the
forEach
as the first thing out of the toolbox.You're absolutely correct that a for loop is not "evil". But I've also learned that, as you pointed out, something rarely needs to be a
forEach
. And when I fall into a lazy habit of submitting code that's littered withforEach
loops, the other devs on my team tend to notice (rightfully so).So rather than beat myself up over it, I just write the logic the way it first "appears" in my brain. Then I give it a once-over, and I might refactor some of those
forEach
loops if they don't feel optimal. (And as you said, they rarely are.)I used to be this way about ternary operators. I would write everything with traditional
if/else
, then I would look at it and think, "This should be a ternary" - so I'd change it. It took quite a while, but now I pretty much "think" in ternaries. I'm not quite there yet with all of theArray.prototype
functions - but I'm definitely a lot closer than I was several years ago.