Date: Tue, 05 Oct 1999 02:52:44 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: wayne@crb-web.com Cc: FreeBSD Hackers List <freebsd-hackers@FreeBSD.ORG> Subject: Re: Developer assessment (was Re: A bike shed ...) Message-ID: <37F8E96C.CDC2F36@newsguy.com> References: <Pine.LNX.4.10.9910031826100.4169-100000@crb.crb-web.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I really, really need not get into this, but I just can't help myself... sigh... Wayne Cuddy wrote: > > > Are you willing to accept that you may have been judged "not worth the > > effort" on the content of your questions, or are we going to have > > another flamewar about whether we should be opening a developers' > > kindergarten? > Oh. Ok if this is case where are the guidelines as to what is "worth the > effort?" This determination is obviously relative. This is a volunteer project. Nobody is forced to do anything. There is no guideline on what kind of questions people should answer or not. It's very simple: if I (emphasis on "I") think answering your message is worth the time in which I could read ten, twenty other messages, I'll do so. The same applies to each other person on the list, developer or not. There are things one can do to improve their chances of seeing the message answered. For example: * Make the messages easy to read. Wrapped lines, no html, clear quoting, adequate use of spacing. * Provide as much information as possible. The less information on a message, the more likely the message comes from someone "clueless", with whom any conversation is likely to be very frustrating. * Show that you did your homework. Describe how you researched the subject, what answers you came from, what happened when you tried each of them, what alternatives are you considering, how do you figure their pro and cons, etc. * Be polite. In my experience, there is absolutely nothing more likely to induce answers than a polite message, no matter it's contents. > You are right I jumped to learning about FreeBSD kernel development, which I > don't get paid for in any way, so that I could have someone else do it... > Try to be a little reasonable here, I would not be here if I did not want to > learn. Which means doing my own work. Example of people wanting someone else to do their homework: "I noticed FreeBSD's malloc() does not return an error when it allocates more memory than available. Can't you do [options]?" This is a recurring thread, you can look up on the archives to read how it goes. Basically, the person doesn't like the present behavior, and would like to have an alternative (or have it changed completely). ALSO, they would like others to _explain_ to them how to go about making such change. Sure, they probably think it isn't all that hard, which only goes to show they didn't do any research at all. For example, the notorious SIGDANGER signal, one of the alternatives to the "problem" above, required that we supported more than 32 signals. Sounds easy, right? Well, someone just spent FIVE WEEKS just adding support for more than 32 signals. The fact is that many people come here before reading a single man page, reading a single source file. That, on -hackers, is wanting others to do their homework. > I would be hard pressed to read the list for a day and not find a demeaning or > wasteful comment from some of the developers on this list. So apparently some > people do have time negative responses. Some months ago FreeBSD had more than 150 committers. I don't know how many there are right now. -hackers, -current, -questions are all very busy lists, and these people happen to also *code* in their free time. If we did not have occasional comments like that given the number of people, the number of e-mails and the fact that at the very least some of them are bound to be going through some stress in their lives, I'd feel like i entered the Twilight Zone. > Does a helpful response, even a "stupid" one take that much time? I did > realize how busy you were. Sure it does. In the minutes I have been answering this mail, I could have finished reading all my e-mail and gone sleep. > This is absolutely correct and in many cases the most inefficient way to go. > It is certainly helpful to answer a question that is on the tip of one's > tongue rather than wading through lines of code especially if it is holding > up the work of others. However you are correct definitive answers are in the > code... all 1 million+ lines.. It comes down to this: if you are ever going to write code, you'll have to read it first. If you don't read it now, while searching for the easy answers, when are you going to start? When all your questions are so complex you'll need to master hundreds of lines of code before finding the answer? Reading the code might be inefficient, but it is YOUR time you are spending, not mine. That kind of consideration is highly valued. And cut that one million lines bullshit. You don't need to read one million lines even if you wanted to rewrite the whole virtual memory system. And most surely "easy" answers won't take more than a few dozen lines of code to figure out, at most. If it takes more, then they are not easy. But if you haven't *TRIED* to find the answer, how do you know if they are easy or not? Nobody reads this list because they are paid to. People read this list and answer the questions in it because they *WANT*. And nobody is going to spend time holding the hand of someone who does not spend HIS time trying to find the answer in first place. If you ask me where in the source code a certain function is defined, I'll delete the message as soon as I lay my eyes upon it. If you ask me *how* do you find out where in the source code is that function, your message will probably generate a long thread of answers. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37F8E96C.CDC2F36>