The idea of using grammar as a litmus test for all new hires is akin to saying that nothing is more important than natural language grammar. That could not be further from the truth. I've read plenty of extremely thoughtful, info-dense specs in the open-source community that had typos and grammar errors. I've seen countless emails from colleagues that were clearly quickly written and thus contained errors. The essential ideas were none-the-less transmitted. My mind is able to auto-correct when needed. Perhaps if the rules of english grammar were based on logic and reason rather than the memorization of arbitrary, capricious rules I'd be willing to attach more wait to the grammar skills of non-professional writers.
> I've read plenty of extremely thoughtful, info-dense specs in the open-source community that had typos and grammar errors. I've seen countless emails from colleagues that were clearly quickly written and thus contained errors. The essential ideas were none-the-less transmitted.
And because people tolerate it and allow for this to happen, we live in such ugly world, where people don't give a damn about quality.
Similarly, nobody has fine tapestries on the walls of their server rooms. Nobody cares about the insulation properties, apparently, but worst of all, nobody cares about the attention to detail and quality a fine tapestry represents. Thus we live in a terrible world with no appreciation of the finer things, because if you don't mind the lack of tapestries, how can you possibly care about a lack of code quality?
Getting basic grammar poorly is not like having no tapestries on walls of server rooms. It's like having a big mess in server room, where machines lie around in unorderly fashion and cabling is a mess. Yes, it works. But it looks terrible. Also add unfinished pizzas laying on the floor for accurate representation of people who don't care about spelling.
> If you're writing more code than natural language (documentation, discussion of specs, interaction with the team, etc) something is extremely wrong.
As long as we are just throwing claims around, I posit unless the code you write isn't 99% of what you write, something is extremely fucked up, and the orcs will take over the world.
I don't see how your claim is more valid or invalid than mine. None of the claims are backed by data, and personal perceptions are, well, personal. No one other than person experiencing it gives a damn.
Perhaps, except that hypothetical code-hungry orcs are imaginary and have nothing to do with anything while the value of any of my very real examples is well understood by pretty much anyone. (Though - if you'll forgive me drawing further from our mystical beastiary - trolls might be an exception?)
Edit to explain why I'm so dismissive:
I think that it's a fairly accepted axiom that specified and documented projects are easier to maintain than the alternative. Likewise with code size versus feature set. I think it's self-evident that teams that communicate in natural language (even if only via a ticket system) are more functional (or at least more tolerable to be a member of) than teams that do not.
Deriving my claim from these seems reasonable enough, to me, given the context of the discussion (a comment thread of a relevant topic on some website a minority of people care about).
Not everything is science and while it might be nice to have 5-sigma data to reinforce my opinon, it fortunately doesn't need to be so reinforced in order to be valid, or even valid to be worth sharing.
> Perhaps, except that hypothetical code-hungry orcs are imaginary and have nothing to do with anything while the value of any of my very real examples is well understood by pretty much anyone.
What does this even mean? I don't see any real examples, and all you are doing is throwing more claims around. I missed the memo where you, and whoever this "everyone" else is were appointed authority on the value of anything for everyone else.
> Edit to explain why I'm so dismissive:
I think that it's a fairly accepted axiom that specified and documented projects are easier to maintain than the alternative.
So a project with beautiful documentation and totally retarded code is easier to maintain? Documentation, more often than not, is for the end user. As far as code maintenance goes, the most important factor is proper abstractions and encapsulations. If you wrote a 5000 line, well commented method, it doesn't help me at all.
And a very specific set of projects lead itself to and require beforehand specs. Majority of the real world runs on "code is spec". Where is the spec for linux? Here is a little unknown someone's views on specs http://kerneltrap.org/node/5725 Where are the specs for rails, sinatra, django, flask? And how would it help if suddenly a rails specs came into being? You are confusing your little well with the world. Most projects design interfaces, not specs(activerecord, rails 4 queuing api etc)
Even your axiom holds(it doesn't, at all), how does that imply if you're writing more code than natural language (documentation, discussion of specs, interaction with the team, etc) something is extremely wrong.?
> Deriving my claim from these seems reasonable enough, to me, given the context of the discussion
> Not everything is science and while it might be nice to have 5-sigma data to reinforce my opinon, it fortunately doesn't need to be so reinforced in order to be valid, or even valid to be worth sharing.
I didn't ask for 5-sigma data. I asked for data which isn't personal anecdotes and viewpoints presented as truth.
If you're writing more code than natural language (documentation, discussion of specs, interaction with the team, etc) something is extremely wrong.