logoalt Hacker News

the_otheryesterday at 10:06 PM3 repliesview on HN

(JS/TS is my main language) I love reduce()! It's a hammer/nail method for me. Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).

I really like taking the implementation away from the call site, so that the call site reads

    const myNewValue = data.reduce(doSomethingMagic); 
(and then `doSomethingMagic` is defined somewhere else). So simple.

I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop. Loops are easier, for sure, but they sprawl and are open to hacking. They can bring in state from outside the loop. They make the call site long (you always have to read the implementation to learn that you don't need to read it). The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier). That's the kind of "clever" I find unpredictable and hard to think about. Probably a good thing he rejected me.


Replies

kenferryyesterday at 11:29 PM

> Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).

I agree, but I think that’s kind of the objection. It can be tempting to write your code as little brainteasers but…

xp84yesterday at 10:22 PM

> The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier).

Wow. That is the kind of monkey business that would have me running for the exits. Yikes.

anyfooyesterday at 10:08 PM

> I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop.

Honestly, sounds like the reviewer failed the interview, not the other way around.

show 1 reply