> Someone not familiar or comfortable with "map" should not be working as a professional programmer today.

I completely disagree - you are measuring the quality of a programmer on a single dimension.

I have worked with very weak programmers that produce gold e.g. great at pulling a team together, great at producing outcomes that clients love, great at focusing on features that sell.

I have also worked with great programmers that just stick to what they know - they don't know map() because they concentrate on being productive rather than continually chasing the next greatest language or library.

I have also worked with technically awesome programmers that produce absolute crap e.g. struggle to communicate, struggle to make good engineering compromises, struggle to understand requirements. One smart guy was so creepy no women could work with him which meant he was actually pretty useless - I saw one friend who worked as a consultant there hide under her desk to avoid him!

I almost fully agree. A professional programmer, how can such a person not know about stuff like map, filter and reduce? It can only happen, when they never cared to learn programming languages, paradigms or concepts of various kinds. This would betray an attitude of not continuing to learn. Even, if they have not come into contact with other programming concepts, how can any professional not have heard anything about map-reduce stuff at some point somewhere? Seems very unlikely to happen without learning-resistance or disinterest towards learning or informing oneself.

However, I would exclude junior software developers from this, as they might have just come from university, where they might not have learned about this at all, depending on the university. Still computer programming is then what they do as "profession", so we would have to count them as "professionals".

That was more of a "it's not universal" comment. Sometimes the right solution is self obvious, other times it needs PR.

If I write a piece of code so others don't have to, then it's a service I'm providing. If they don't 'get' the code then the problem is not always with them. It's important to watch for patterns in the questions or complaints you get. There are often multiple acceptable ways to solve the same problem and everything goes smoother if the one you use doesn't trip people up.

In this case I pointed him to some documentation on filter and map.