How to be a Developer the Moronic Way
Someone pointed me to http://catb.org/esr/faqs/smart-questions.html . It amazes me how developers, who sometimes appear to be intelligent and capable of programming their way out of a paper bag, can be such morons. My guess is there are two groups of open source developers. One group is interested in sharing code, improving code, and helping computers get smarter and easier to use. The other group is interested in broadcasting how great they are. (I, of course, am obviously in the second group since I'm broadcasting as we speak.)
Eric Raymond is saying that if you don't read the code, you can't report a bug. Don't do usability testing -- that doesn't involve reading the code and the comments from the users can't be valuable because they didn't read the code. Invariably, with people like this and people like Ulrich Drepper, even if you read the code, they will not be interested in your comments. These people obviously believe that everyone should only use code they have personally written -- we should all spend our time rebuilding operating systems and compilers from scratch.
If you're a developer, and you broadcast your code, you need to learn how to deal with feedback appropriately. If you're getting negative feedback, its probably because you didn't broadcast the documentation as effectively as you broadcast the code, or, you implemented some stupid bug in an early version of the code. For a bug, apologize profusely for the bug, and then point the user to the correct version of the code: "You're right. I made a stupid typo in version 1.0.15 of the software. I fixed that problem in, I think, version 1.0.23 or so. You can download the latest version, 2.17.45 from _here_." You screwed up. Your penance for not doing better QA is dealing with the negative feedback.
If you're getting feedback along the lines of "
". Don't be annoyed. You've got a user that is excited about your product. Bask in the glow of that excitement. Don't tell the user to RTFM. The user already tried to read the manual and couldn't determine the answer. The user already tried to use the tool to do it, and couldn't figure out if it could be done or not. It seemed like you should be able to do it, but the exact syntax was too convoluted to figure out, probably because the developer who is broadcasting how intelligent they are did a crappy job of designing the user interface.
Eric Raymond is saying that if you don't read the code, you can't report a bug. Don't do usability testing -- that doesn't involve reading the code and the comments from the users can't be valuable because they didn't read the code. Invariably, with people like this and people like Ulrich Drepper, even if you read the code, they will not be interested in your comments. These people obviously believe that everyone should only use code they have personally written -- we should all spend our time rebuilding operating systems and compilers from scratch.
If you're a developer, and you broadcast your code, you need to learn how to deal with feedback appropriately. If you're getting negative feedback, its probably because you didn't broadcast the documentation as effectively as you broadcast the code, or, you implemented some stupid bug in an early version of the code. For a bug, apologize profusely for the bug, and then point the user to the correct version of the code: "You're right. I made a stupid typo in version 1.0.15 of the software. I fixed that problem in, I think, version 1.0.23 or so. You can download the latest version, 2.17.45 from _here_." You screwed up. Your penance for not doing better QA is dealing with the negative feedback.
If you're getting feedback along the lines of "
Can I convert an AcmeCorp document into a TeX file using the Bass-o-matic file converter? |
posted by Cesium at 08:51
0 comments
