What's so bad about a grammar test? Any competent person (excluding extenuating circumstances: dyslexia, etc.) should be able to pass a simple grammar test. It's not some hardship that you have to study for or anything.
It's more like I am applying for a programming job, and I don't see why I have to subject myself to your whims.
Consider that instead of grammar, I am advocating I will only hire people who can do 50 push-ups. After all, what can I expect from people who are sloppy towards something as important their own bodies. What's so bad about 50 push-ups? Any fit person(excluding extenuating circumstances) should be able to do 50 push-ups.
The thing is, I don't see the correlation between grammar and the job I am supposed to do, but more importantly, by doing that, you aren't warranting me the respect I believe I deserve. I have a particular job and screening procedure in mind. If you ask me to skip rope, irrespective of my ability do so, I will have to deny.
What? If you're writing software being able to produce clear documentation, write-ups, and other supplemental materials is quite important. In some cases, far more important than writing the actual code.
In some hires I've used a descriptive writing assignment, where I ask the candidate to describe in words what they are looking at. You can learn much from these things, including: analysis skills, close looking, how they think, and, well, how well they would document their software.
> What? If you're writing software being able to produce clear documentation, write-ups, and other supplemental materials is quite important. In some cases, far more important than writing the actual code.
You are taking it to the extreme where there are only 2 states: grammar purists and monkeys banging at keyboard. Someone who mixes up "its" and "it's" is capable of all the important stuff you listed. I mix "its" and "it's" a lot while typing. I know the difference, my fingers don't.
> analysis skills, close looking, how they think, and, well, how well they would document their software.
And none of it is a result of good grammar. Are you implying that somehow good grammar leads to good analytic skills? Or are you saying talking with them gives you a window to their mind? If the latter, the window is wide open irrespective of how often I mix "it's" and "its". And how I prefer my period outside of quotes or parens(Why? Because I like it that way. That's why).
So teach yourself not to make the mistakes because the next person in behind you working on your code might not know what you mean. If you know the difference it's just laziness to not communicate correctly.
As for periods outside of parentheses or not, that's syntax, not grammar. Your position here is weak. Good grammar is an indication that the person wielding the language at least takes care over what they're doing. A valuable trait for anyone, no matter what.
> Good grammar is an indication that the person wielding the language at least takes care over what they're doing.
Good grammar is an indication of good grammar, and that's that. If you believe it's otherwise, well, your believes aren't fact. Please provide citations.
"...If you're writing software being able to produce clear documentation, write-ups, and other supplemental materials is quite important. In some cases, far more important than writing the actual code."
Does the company in the original post not recognise the function of an editor?
Absolutely you do not have to subject yourself to his whims. You would be free to walk out the door if you found the grammar test offensive, or the push-ups test, or the rope-skipping test.
You do not deserve respect. Ever. You must always earn it.
> Absolutely you do not have to subject yourself to his whims. You would be free to walk out the door if you found the grammar test offensive, or the push-ups test, or the rope-skipping test.
> You do not deserve respect. Ever. You must always earn it.
There are multiple types of respect. "One human being to another" is the basic type. Everyone deserves that. Another is earned. And the last one is context dependent.
If I am coming in for a programming job, there are expectations and norms. I come in and you ask me to unclog the toilet since you read in some blog about some CEO doing it or it represents loyalty or commitment or whatever the fuck, I am free to walk out and I will walk out. But that doesn't excuse the fact that you didn't warrant me the respect I deserved.
Oh god. I hate this attitude. Respect is a right, not a privilege. Why should anyone have to earn something so basic? Do we also have to earn our privilege to breathe air? We're all equals and equally deserve respect. Yes, even you after you muttered that banality.
I would say that we're definitely not identical, but we can all be equal.
A better question, though I will answer yours shortly, is what does equality mean? It's simply the relative value we assign something. The thing is, we can think in terms of valuable and not valuable or we can skip the duality altogether and see everything on an equal level. A spade is thoroughly unvaluable if you have no hole to dig yet indispensable when you do. So what is it's absolute value? Is it equal to a saw? Is one person equal to another? It all depends on your perspective.
The problem with seeing inequality between people in terms of respect is that you will treat some of your fellow man badly, since you don't respect them. If their value is merely a matter of perspective, which is ever changing, would it not make more sense to see past our biases and show everyone respect, whether they are equal to what we currently identify as respect worthy or not?
To me, respect means to consider someone in high regard. In my experience, how I look at people ends up affecting how they act. People always tend towards living up to the expectations placed on them. By showing someone that I don't respect them, I am pushing them down rather than helping them up.
Putting it another way, when someone is on the defensive, because someone else looks down on them and does not show them respect, they close up and are not receptive to new information. By showing them respect even if they are bad at something, they are likely to listen to what you have to say and change how they act as a result of your words. Disrespecting someone with - "you type like an idiot" or ignoring them, will make them respond appropriately. Validating their actions - "cool, a more condensed form of English!" then suggesting something else - "I've had lots of success finding a job by writing like this", they might actually change.
If we want society (and spelling) to improve, we have to embrace those we call idiots and teach them, not push them away.
If someone is an awesome programmer but can't write English to save his life, why not educate him? You'll certainly have a more loyal employee if he feels that he's gained important skills from you.
tl;dr - Disrespect is damaging, respect is nurturing. Respect everyone and the sun will shine brighter.
> You do not deserve respect. Ever. You must always earn it.
Hm. If you don't have my respect, I may well feel justified in stealing from you. Is that really the kind of 'lack of respect' you think should be the default state?
What's so bad about it is that unfounded assumptions are being drawn from the performance of said test.
Any competent person should be able to make a bed neatly and quickly. Would you apply for a (non-hospitalitly-related)job that required you to demonstrate your bed-making abilities?
Watching how someone makes their bed shows their behaviour towards paying attention to detail. Even if they don't know how to do it, if someone chooses not to do or chooses to give up, it's clear sign that the person will probably not do something out of their domain.
If you're in a startup, you wear many hats. You do what it takes to succeed. If you have no clue how to do sales, find a way.
>Watching how someone makes their bed shows their behaviour towards paying attention to detail. Even if they don't know how to do it, if someone chooses not to do or chooses to give up, it's clear sign that the person will probably not do something out of their domain.
I'm really not trying to be argumentative here, but this seems really silly. Replace "make a bed" with something like "kick a 40 yard field goal" or "craft a wooden chair" or more simply "tie a Windsor knot". All your testing is whether they care about that particular task that is in no way related to skills you actually need.
Sure it might sound silly but sometimes it's not whether you can actually do the task or not. It's more of how will you approach something that you are not expected to do. Different people have different approaches.
I agree that if you're hiring a programmer strictly to program and do nothing else, that's fine. But if you're looking for someone who thinks outside of the box, is capable of coming with ideas and solutions when the solutions are yet to be known, having tests like these is probably a way to figure out how a person thinks. Whether it's a good way or not, I'm not so sure as I've never had to administer one of these tests.
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.
