Teams that lack the element of craftsmanship in their culture will likely not care if a programmer knows grammatical rules of natural language (much less if he is a master of natural language). To simplify, whether you agree with the author correlates with what type of programmer you are (or want to hire). In this simplification, I'll call them "productive programmers" and "craftsmen programmers".
Productive programmers ship lots code, create lots of value, and by business standards are model programmers. They're driven by quantity, volume, getting things out the door, and the solvency of the business.
Craftsmen programmers also "produce" and ship code, but they equally value maintainability, and therefore clarity in code. They're driven by the customer as much as the other consumer of their code, the maintainers.
From my experience, these very different types of programmers have very different priorities and values. Generally, the first set emphasizes clarity in communication only as it impedes progress along the critical path. They JIT there eloquence, whether it's essential business communication or unstable/volatile/certain-to-change code. JITing is hard and not guaranteed to produce the optimal (most clear) output. The second group feels obligated to be clear in communication at all time, because any corners cut now may create pain for a fellow down the road. To excel at this, the second group is self-motivated to learn deeply both the spirit and the mechanics of communication (empathy and grammar). They spend more time analyzing the available solutions for potential misinterpretations, and therefore generally produce a clearer output.
Thus, the applicability of the article depends on the culture and environment of the team.
Productive programmers ship lots code, create lots of value, and by business standards are model programmers. They're driven by quantity, volume, getting things out the door, and the solvency of the business.
Craftsmen programmers also "produce" and ship code, but they equally value maintainability, and therefore clarity in code. They're driven by the customer as much as the other consumer of their code, the maintainers.
From my experience, these very different types of programmers have very different priorities and values. Generally, the first set emphasizes clarity in communication only as it impedes progress along the critical path. They JIT there eloquence, whether it's essential business communication or unstable/volatile/certain-to-change code. JITing is hard and not guaranteed to produce the optimal (most clear) output. The second group feels obligated to be clear in communication at all time, because any corners cut now may create pain for a fellow down the road. To excel at this, the second group is self-motivated to learn deeply both the spirit and the mechanics of communication (empathy and grammar). They spend more time analyzing the available solutions for potential misinterpretations, and therefore generally produce a clearer output.
Thus, the applicability of the article depends on the culture and environment of the team.