Apparently, someone doesn’t really get what makes functional programming hard to understand? It’s not writing the occasional pure function.

Code review or pair programming might help here, to learn the team’s common idioms.

(2016)

By the looks of the code snippets he should have explained that he’s not doing functional programming, he’s just writing unnecessarily non-idiomatic python code. I’m sure his manager would have understood.

When did method chaining become 'functional programming'?

It's not 'functional programming' that makes the code unreadable, but overly long chains of array-processing functions. Sometimes a simple for-loop which puts all operations that need to happen on an array item into the loop-body is indeed much more readable.

There's only one universal lesson that I've learned over my 25+ year career so far and it's that software engineering types are fragile creatures whose egos must be tended to. Delicately.

This is becoming increasingly true as the years pass and the number of times I've had to drop whole mature architectures and reimplement something worse because some engineer's feefees got hurt can no longer be counted on my fingers & toes.

Using Scala and then complaining about unnecessary complexity is a bit much. Like, if you made the technologically brave decision to use a niche language like Scala that isn't just a slightly better Java like Kotlin then you'd better expect to accommodate the inexperienced developers by training them, possibly via pair programming, instead of constricting the experienced developers.

If this code is too complicated for you then you should reconsider your career.

Beyond the satire, one is supposed to write code which is readable, and like often with written works, one has to think about the "audience", the readers. When you write technical documentation, you have to decide ahead of time the expected skill level of the reader - often that decision is written too in the intro as "prerequisite(s)".

When writing code you have the motto "don't make me think" in mind, but how to know what's the maximum level of trickiness for readers? There are familiar techniques and idioms when it is your main programming language, but they are not for someone using this language on the side.

In any case, neither code nor comments should be tutorials. To a reasonable extent, it is up to the reviewer to do their homework or just ask. Then based on that interaction you can add a comment or a parenthesis, or uncompress a bit the code. But not to the point that it means to "dumb down" things, because it is a downward spiral.

The manager solved the wrong problem. People should be sharing their tricks with each other. This was a perfect time to set up some peer-to-peer training.

Missed chance to do something like:

  class User:
    def calculateCoworkers() = {
      this.coworkers.clear()
      for { d <- this.departments }
        this.coworkers ++ d.employees
    }

and then, somewhere else...

  user.calculateCoworkers()
  ... many lines after ...
  for { c <- user.coworkers }
    ... do something ...

Yes, I've seen code like this many, many, many times where class members are used as "global variables" to pass state across functions. And I've noticed AI likes to generate code like this too (possibly because of the former (large presence of this "pattern" in the training data), which means I'm encountering this now in pull requests...

FP code is often easier to read (the article provides a case to that point).

What gave FP a bad rep is, i guess, Haskell (and the "pure functional approach w/ monad transformer stacks").

Every shop I worked at the devs were already at a level that they'd appreciate FP code: easier to read, refactor and test.

The tendency is also towards FP: see the features in recent Java/C# version. Or languages that gain popularity recently (Kotlin, Rust) are more FP'ish than their predecessors (respectively Java and C++).