On Wed, Aug 12, 2009 at 1:26 PM, Max Hetrickmaxhetrick@verizon.net wrote:
Brian Mathis wrote:
This thread seriously highlights the sort of attitudes that are causing major issues in IT in general, and have been for years. Whenever someone makes a mistake, we point fingers and call them stupid. We haughtily proclaim that only people who "know what they are doing" should have a job -- as if we had never been short on time, ventured into an area outside our expertise, or been a beginner.
The fact is that we all have a million things to do and only a fixed amount of time. It's simply not possible for anyone to be a complete expert in everything at all times. We've all been in a position where something needs to be done immediately and you don't know everything about the product/system. I would wager that is more common than the situation where you know everything about everything before performing any actions.
Additionally, IT often has the unique benefit that users can quickly contribute to a feedback loop that informs you directly with what they are having trouble with. Other industries, such as advertising, marketing, sales, etc... would *kill* to have that sort of feedback.
And what do we do with it? In this case, someone has effectively filed a bug on the documentation, and all we can do is spew about how stupid the person is. It doesn't matter if the information is there /somewhere/; the bug is that it's not clear, or it's presented in a confusing way, or it is potentially dangerous and that danger can be easily mitigated (Jason Pyeron has got the right idea).
Hmmm, not sure I agree with you here. Where I work, and in most places I've seen, if someone isn't competent enough on the Linux command line, he/she doesn't get close to a production system until he/she is taught or learned enough to be trusted.
A company just doesn't turn someone free on Linux servers with root access if he/she doesn't know what they are doing. That is just plain stupidity.
Your argument does apply, however, to this thread, the original poster suggested that the author of the article was wrong, and should be more clear about his commands. When in fact, the very first sentence of the article stated it was for *install time* which to me is pretty clear and concise.
If you have employees working for you and they don't know or understand enough to know that when you install an OS, it's going to wipe the drives, then I'd be doing one of two things. 1) teaching my employees, or 2) not allowing them access to a production system of all things.
Yes, education is important, very important. But the issue with this thread wasn't about that. It was about someone stating that the author of an article was wrong or not clear enough on instructions, when in my opinion, the author was extremely clear with the very first sentence of the guide.
If I don't know something about a system or piece of software, I set up a test server at work and play with it. I certainly don't play with it on a production environment, mis-read or not read at all the guide I'm working with, and then go back and try to blame the author.
> Instead of taking the lazy approach of dismissing someone as stupid, > prove that your haughtiness is justified by engaging on how to fix the > problem. You've been presented with an opportunity to make something > better than it was before. Take it.
Aside from some sarcasm, no one was being arrogant or rude in their responses. What problem? The problem that someone didn't clearly read through the how to before they started typing commands? How is that anyone's fault here on the list or on the wiki? It's no one's fault except the person typing things they clearly haven't thought about.
I think everyone's comments are spot on. You don't let people who aren't educated onto an installation with root access. If that's how you run your shops, then so be it, but that's not normal in my experience.
Regards, Max
There are 2 faults here, the documentation and the responses to the thread.
The fix for the documentation is to change the example to a command that does no damage if it is copied/pasted. That's an easy fix and can only serve to force the user to read the guide more in depth. Changing the device names to "/dev/sdX" "/dev/sdY" is much more unlikely to cause damage to a system if they were copied verbatim, and the capitals and use of X and Y is more likely to trigger someone to stop, as X and Y are frequently used as indicators to replace something else with. In my own documentation, I highlight those areas with a yellow background to be sure people know where to substitute real values.
It also helps to understand how people read instructions. When they look at a page, they see {big blob of useless introduction text}, then they see "Step 1, do this". They almost always go right to Step 1. I'd bet $100 that everyone reading this thread has done that more than once, recently. It's not good enough to put the warnings so far separated from the actual commands. You might have some feelings about how things *should* be done, but you don't get to make that decision for people, you just need to know it and work within it.
As far as the replies here go, the first one insinuates that the person can't follow instructions, the second one calls the person dumb, and others say that the person is incompetent, and compares their intelligence to that of a bottle. That IS rude and arrogant in my book, and your final sentence only continues with the passive-aggressive swiping that goes on too often in IT realms.