But the gist of it is: the industry prefers to work with dumbest tools possible and throw cheapest bodies they can get at a problem, instead of expecting people to keep learning, improving themselves, and applying these improvements to their work. This article is an example of that - it advocates discarding advanced tools given to the programmer by Haskell, in favor of writing dumb code that's easily digestible for beginners. Most of the advice about avoiding "clever code" is a form of that too.

I find it a penny-wise, pound-foolish approach, because when you do this trade-off, you're losing in two places. First of all, you handicap your skilled team members. But secondly, the cost (in terms of time, money and incidental complexity) of a project grows faster than linear with the number of people you get involved in it. It'll be O(n!) if you do it naively, O(n logn) if you arrange people into hierarchies, but the problems still grow faster than they're solved as you scale up.

The alternative approach I'm encouraging is to make responsible but full use of the power of the tools you have, and if this goes over the head of some new hire, then teach them until they understand and can make use of that power too. Embrace and encourage learning as a part of this job (actual, expected, and paid-for part). Push the industry upwards, instead of dragging it down.