Полный текст есть по ссылке
http://maddog.sitengine.ru/smart-question-ru.html
В мире хакеров, стиль ответов, которые вы получаете на задаваемые технические вопросы, чаще всего зависит не от сложности самого вопроса, а от того каким образом вы зададите свой вопрос. Мы надеемся, что это руководство научит вас грамотно и правильно задавать вопросы так, чтобы увеличить вероятность получения удовлетворительного ответа.
Прежде всего следует понять, что хакерам на самом деле нравятся сложные и «заковыристые» вопросы, которые позволяют расшевелить мозг. Если бы нам это не нравилось, мы не были бы хакерами. Если задать нам интересный вопрос, требующий продолжительных размышлений, мы будем за него только благодарны, ведь хорошие вопросы — это и стимул, и подарок. Хорошие вопросы помогают лучше понять предмет и часто вскрывают проблемы, которых ранее не замечали или о которых просто не задумывались. У хакеров возглас «Хороший вопрос!», означает большой и искренний комплимент.
Несмотря на это, почему-то считается, что хакеры относятся к простым вопросам скорее враждебно и высокомерно. Со стороны может показаться, что мы достаточно грубы к новичкам и игнорируем их. Но на самом деле это не верно.
Мы, без всякого сомнения, неприязненно относимся к людям, которые, такое складывается впечатление, не хотят немного подумать своими мозгами или немного поучиться прежде, чем задавать свои вопросы. Такие люди попросту тратят время - они берут, ничего не давая взамен, они отнимают наше время, которое мы могли бы посвятить другому более интересному вопросу, и другому человеку, который больше них достоин ответа. Таких людей мы называем «неудачниками» («losers») (по историческим причинам это слово иногда пишется как «lusers» — пользователи-неудачники).
Мы понимаем, что большинство людей просто хотят использовать создаваемое нами программное обеспечение, и совершенно не собираются вникать в технические детали. Для многих компьютер - это просто инструмент, средство достижения цели. У таких людей есть более важные и насущные вещи в жизни. Мы прекрасно понимаем это и не ожидаем, что всех интересуют только технические нюансы, столь привлекательные для нас. Тем не менее, наш стиль ответов рассчитан на людей, которые действительно интересуются этим, и активно помогающие в процессе решения проблемы. И это никогда не изменится. А в принципе, и не должно меняться, ведь в противном случае, мы вряд ли сможем эффективно делать то, в чём мы лучше всего разбираемся.
Мы тратим своё личное время своей нелёгкой жизни на решение тех или иных вопросов и проблем, но временами мы просто не справляемся со шквалом вопросов. Поэтому приходится безжалостно фильтровать поступающие вопросы. В частности, приходится отбрасывать вопросы потенциальных неудачников, чтобы потратить более эффективно время на ответы действительно заинтересованным людям.
Если такая позиция кажется вам смешной, высокомерной и заносчивой, то вы глубоко ошибаетесь. Мы не просим вас относится к нам как богам. Если говорить, положив рука на сердце, большинство из нас хотели бы общаться с вами на равных, принять вас в свой круг культуры и общения, при условии, что и вы со своей стороны приложите все необходимые для этого усилия. Согласитесь, что бессмысленно помогать людям, которые не хотят помочь сами себе. Не знать чего-то — это нормально, а вот прикидываться идиотом — нет.
Итак, вовсе не обязательно быть технически компетентным, чтобы удостоиться нашего внимания, надо всего лишь продемонстрировать качества, позволяющие стать компетентным — внимательность, вдумчивость, наблюдательность, желание активно участвовать в выработке решения. Если по каким-либо причинам вы не можете смириться с подобного рода дискриминацией, то мы можем предложить вам заплатить за коммерческую поддержку вместо того, чтобы не просить хакеров безвозмездно помочь вам.
Лучший способ получить быстрый и исчерпывающий ответ — это спрашивать как человек умный, уверенный в себе и знающий, которому просто понадобилась помощь при решении одной конкретной проблемы.
Прежде, чем задать технический вопрос по электронной почте или дискуссионной группе, в чате или на форуме, сделайте следующее:
попытайтесь найти ответ, воспользовавшись поиском по архивам форума, на котором собираетесь задать вопрос
попытайтесь поискать ответ в интернете, воспользовавшись поисковыми сайтами
попытайтесь найти ответ в прилагаемом руководстве
попытайтесь найти ответ в списке часто задаваемых вопросов (FAQ)
попытайтесь найти ответ путём проверок и экспериментов
спросите у более опытного товарища
Когда вы задаёте вопрос, укажите с самого начала, что вы всё это уже сделали; это поможет понять, что вы не какой-нибудь лентяй, тратящий чужое время. Будет даже лучше, если вы покажите, что вы узнали в результатах своих поисков. Нам нравится отвечать людям, способным анализировать и делать выводы из полученных ответов.
Возьмите на вооружение контекстный поиск, как это делает поисковая система Google, по тексту полученного сообщения об ошибке (имеет смысл также поискать в дискуссионных группах — Google groups, а не только на веб-страницах). Это может привести вас либо непосредственно к документации, посвящённой тому, как устранить эту ошибку, либо к обсуждению в списке рассылки, в которой можно будет найти ответ. Даже если вам и не удалось найти ответ на свою проблему, фраза: «Я поискал в Google по следующему запросу, но ничего полезного не нашёл» пригодится при обращении за помощью по электронной почте или в дискуссионную группу хотя бы потому, что свидетельствует о бесполезности поиска. В дальнейшем это поможет быстрее найти ответ другим людям с подобной проблемой, т.к. решение данной проблемы будет связано в одну цепочку с вашим описанием проблемы.
Не ленитесь, потратьте время на поиск решения. Можете даже не думать, что у вас получится решить сложную проблему, поискав с помощью Google всего лишь несколько секунд. Почитайте и попытайтесь понять ответы из разных ЧаВО, посидите, расслабьтесь и немного подумайте над проблемой, прежде чем обращаться к экспертам. Поверьте, по вашим вопросам они смогут понять, как много вы читали и думали, и с большим удовольствием помогут, встретив подготовленного и умеющего думать пользователя. Не надо забрасывать людей вопросами только потому, что вы не смогли найти ответ на свою проблему (или получили их слишком много).
Подготовьте свой вопрос. Тщательно его продумайте. На поверхностные вопросы вы получите поверхностные ответы, или вообще не получите ответа. Чем больше вы сделаете, чтобы продемонстрировать свои размышления и усилия по решению проблемы до того, как попросить о помощи, тем вероятнее, что вы эту помощь получите.
Не задавайте глупых и неправильных вопросов. Если вопрос строится на ошибочных предположениях, любой хакер, скорее всего, даст настолько же бесполезный ответ, подумав про себя «Глупый вопрос…», и надеясь что, то что вы получили вместо того, что вам действительно надо, заставит вас лишний раз подумать.
Никогда не думайте и не надейтесь, что вам должны ответить. Вам никто и ничего не должен, в конце концов, вы же не платили за оказание этих услуг поддержки. Вы получите ответ на свой вопрос, если вы его заслужили, задав значимый, интересный и наводящий на размышления вопрос — вопрос, неявно дающий сообществу новый опыт, а не просто пассивно требующий от других поделиться знаниями.
С другой стороны, неплохо сразу ясно дать понять, что вы можете, желаете и хотите помочь в процессе выработки решения. На вопросы типа: «Может ли кто-то подсказать?», «Что не учтено в моём примере?» или «А нет ли сайта, который стоит на эту тему посмотреть?» более вероятно будет получен ответ, чем требование прислать точную последовательность действий для решения проблемы, поскольку вы явно показали, что решите проблему самостоятельно, если кто-то кажет вам правильное направление дальнейших действий.
Учитывая наш опыт, мы заметили, что люди, пишущие невнимательно и небрежно, обычно так же невнимательны и небрежны в мыслях и в коде создаваемых программ (по-крайней мере, мы с таким сталкиваемся достаточно часто, чтобы утверждать это). Отвечать на вопросы людей невнимательных и небрежно мыслящих — занятие неблагодарное, лучше мы своё время потратим на что-нибудь другое.
Поэтому чёткость и правильность формулировки вопроса имеет большое значение. Если вы не хотите морочить себе этим голову, мы, в свою очередь, не хотим морочить голову себе, уделяя внимание таким вопросам. Постарайтесь сформулировать вопрос правильным языком. Он не должен быть тяжеловесным и формальным — на самом деле, в хакерской культуре ценится неформальный, полный сленга и юмора язык, используемый правильно и к месту. Но мысли должны быть выражены чётко; необходимо продемонстрировать хоть какие-то признаки вдумчивости и внимания.
Соблюдайте правила орфографии, старайтесь писать грамотно, без ошибок («очепятки» меньше раздражают, нежели полное нежелание писать грамотно — прим. переводчика А.С.). Не путайте «its» с «it's», «loose» с «lose» или «discrete» с «discreet». Не ПИШИТЕ ВСЁ В ВЕРХНЕМ РЕГИСТРЕ, — это воспринимается как крик и считается грубостью. (Если всё написано в нижнем регистре, — не многим лучше, поскольку такой текст сложно читать. Алану Коксу это прощается, а вам — нет.)
В общем случае, если вы пишите на уровне детского лепета или бреда сумасшедшего, ваш вопрос, скорее всего, проигнорируют. Так что, использование сокращений, например, вместо «you» написать «u», приемлемых в программах по обмену быстрыми сообщениями, не приветствуется. Писанина в стиле малолетних «кул-хацкеров» (в оригинале — l33t script kiddie haxOr — прим. переводчика В.К.) — абсолютно безнадёжна, и гарантирует в ответ — тишину (или, в лучшем случае, порцию пренебрежения и сарказма).
Если вы задаёте вопросы в форуме, где используется не родной для вас язык, то некоторые лексические и грамматические ошибки вам простят — но никакого прощения лени не ждите (да, мы обычно способны почувствовать разницу). Кроме того, если вы не знаете точно, какой язык для адресата является родным, пишите по-английски. Занятые хакеры обычно пропускают вопросы на языках, которые они не понимают, а английский язык является основным и рабочим языком Интернет. Задав вопрос по-английски, вы уменьшаете вероятность того, что его пропустят не читая.
Внимательно и чётко опишите симптомы обнаруженной проблемы или ошибки
Опишите среду, в которой она возникает (компьютер, ОС, приложение и т.д.). Укажите дистрибутив и релиз (например: «Fedora Core 4», «Slackware 9.1» и т. п.).
Опишите проведённое вами исследование при попытках понять проблему прежде, чем задали свой вопрос.
Опишите какие вы предприняли самостоятельные шаги по диагностике и устранению проблемы прежде, чем задали свой вопрос.
Бесполезно сообщать хакерам своё мнение о причинах проблемы (Если ваши диагностические теории настолько значимы, надо ли обращаться за помощью к другим?). Поэтому, убедитесь, что вы сообщаете фактические симптомы происходящего, а не свои интерпретации и теории. Пусть интерпретацией и диагностикой займутся отвечающие. Если вы чувствуете, что ваше предположение будет полезным и важным, то стоит чётко и ясно написать почему по вашему мнению это не работает.
Не ограниченные по времени вопросы зачастую требуют и не ограниченного по времени ответа. Люди, скорее всего способные дать вам полезный ответ, ещё и самые занятые люди (ещё и потому, что большую часть своей работы делают сами). Такие люди ревностно относятся к своему времени, и поэтому часто не воспринимают вопросы не ограниченные по времени.
Вероятность получения полезного ответа повышается, если вы чётко даёте понять, чего добиваетесь от окружающих (предоставить ссылки, отправить код, проверить ваше решение и т.п.). Это сконцентрирует усилия отвечающих и неявно задаст ограничение по времени и усилиям, которые придётся затратить отвечающему, чтобы помочь вам. И это хорошо. Код ответа 911.
Чтобы понять, в каком мире живут эксперты, надо относиться к знаниям экспертов, как к ресурсу обильному,а к их времени — как к ресурсу весьма ограниченному. Чем меньше времени вы неявно требуете, тем более вероятно получение ответ от действительно хорошего и занятого эксперта.
Поэтому имеет смысл ограничить вопрос, чтобы свести к минимуму время, необходимое эксперту для его решения. Но зачастую это не тоже самое, что упростить вопрос. Так, например, вопрос: «Можете ли вы дать ссылку на хорошее описание X?» — обычно куда разумнее, чем просьба: «Объясните мне X, пожалуйста». Если у вас проблемы с неработающим кодом, разумнее будет попросить объяснить, что в нём не так, а не просить исправить ошибки.
Это ваша проблема, а не наша. Упоминание о срочности зачастую контр продуктивно: большинство хакеров просто удаляют такие сообщения как грубые и эгоистические попытки срочно привлечь к себе особое внимание.
В этом правиле есть одно небольшое исключение. Упоминание о срочности может иметь смысл, если вы используете программу в серьёзной и известной компании, которая может заинтересовать хакеров. В таком случае, если вам не хватает времени и вы сообщите об этом вежливо, люди могут оказаться достаточно заинтересованы, чтобы ответить быстрее.
Так делать, однако, крайне рискованно, потому что точка зрения хакера на серьезность и его интересы, вероятно, отличаются от ваших. Вопрос о международной космической станции, например, вызовет интерес, а вот вопрос от имени преуспевающего фонда или политической партии, почти наверняка, — нет. Фактически, вопрос с темой «Срочно: Помогите мне спасти пушистых тюленят!» будет проигнорирован или злобно прокомментирован даже теми хакерами, которые считают, что жизнь пушистых тюленят имеет для них значение.
Если вас это удивляет, перечитайте весь этот документ до тех пор, пока не поймёте, а до того воздержитесь от отправки вопросов вообще.
Будьте вежливы. Используйте фразы «Спасибо», «Заранее благодарен» или «Спасибо за Ваше понимание». Дайте понять, что вы благодарны людям, бесплатно посвящающим вам своё время.
После того, как ваша проблема решена, пошлите сообщение всем, кто вам помог, дайте им знать, чем всё закончилось, и поблагодарите ещё раз за помощь. Если проблема вызвала общий интерес в списке рассылки или дискуссионной группе, имеет смысл подобное сообщение отправить и туда.
Оптимальным решение будет ответить в нити обсуждения, начатой с исходного вопроса, добавив к теме сообщения пометку «FIXED», «RESOLVED», «РЕШЕНО» или другой не менее очевидный признак решения. В списках рассылки с большим количеством сообщений, потенциальный отвечающий при взгляде на нить обсуждения «Проблема Х», завершающуюся сообщением «Проблема Х - РЕШЕНИЕ» понимает, что ему не нужно тратить своё время даже на чтение сообщений (если он лично не считает Проблему Х интересной), и поэтому может потратить своё время на решение другой проблемы.
Такое сообщение не обязательно должно быть длинным и подробным. Простое: «Привет! Проблема была связана с разрывом в сетевом кабеле! Спасибо всем. Билл», - уже лучше, чем ничего. Фактически, краткое и вежливое резюме лучше, чем длинная диссертация, если только решение не затрагивает серьёзные технические аспекты. Напишите, какие действия позволили решить проблему, но всю последовательность поиска решения повторно описывать не надо.
Для достаточно серьёзных проблем можно послать резюме с историей поиска причин. Опишите окончательную постановку проблемы. Опишите, каким оказалось решение, и укажите тупиковые пути, которых стоит избегать. Назовите всех, кто помог вам: так вы найдёте себе друзей.
Есть древняя и священная традиция: если вы получаете ответ «RTFM», значит, отвечающий думает, что вам стоит почитать руководство (Read The Fucking Manual). Он почти наверняка прав. Идите читать.
У ответа RTFM есть более молодой аналог. Если вы получаете в ответ «STFW», значит, отвечающий думает, что вам стоит поискать ответ в сети (Search The Fucking Web). Он почти наверняка прав. Идите искать. (Более мягким вариантом этого выражения может быть фраза: «Гугл ваш друг!»)
Часто тот, кто вам отвечает подобными фразами, имеет под рукой руководство или web-страницу с необходимой вам информацией, и смотрит на неё, когда набирает ответ. Эти ответы означают, что, по его мнению, во-первых, необходимую информацию легко найти и, во-вторых, вы большему научитесь при поиске информации, чем если вам её преподнесут под нос на тарелочке.
Вас это не должно возмущать, т.к. по хакерским стандартам, он оказал вам достаточное уважение уже тем, что не проигнорировал вопрос. Вы должны поблагодарить ответившего за его отеческую доброту.
Если вы не поняли ответа, не спешите тут же требовать его объяснить. Попробуйте воспользоваться теми же источниками информации, что и при поиске ответа на исходный вопрос (руководства, ЧаВО (FAQ), Web, опытные коллеги), чтобы понять ответ. Если и после этого вам необходимы разъяснения, попросите ответившего разъяснить свой ответ, показав, что вам самим удалось узнать.
Например, предположим, я вам ответил: «Похоже, у вас завис zentry. Надо проверить.» Тогда плохим уточняющим вопросом будет: «А что такое zentry?» А хорошим: «Ок, я прочитал страницу справочного руководства, и про zentry там упомянуто только в опциях -z и -p. Ни в одной из них не сказано, как сбросить зависший zentry. Надо ли использовать одну из этих опций, или я что-то неправильно понял?»
Вот несколько классических глупых вопросов и о чём думают хакеры, когда на них не отвечают.
Вопрос:
Где можно найти программу или ресурс X?
Ответ:
Там же, где и я её взял, придурок, — найти в Интернете. Боже, неужели ещё не все знают, как пользоваться Google.
Вопрос:
Как можно с помощью X сделать Y?
Ответ:
Если вы хотите сделать Y, надо так и спрашивать, не предполагая заранее использование метода, который может вовсе не подходить. Вопросы такого вида часто задают те, кто не просто ничего не знает об X, но и сбит с толку решаемой проблемой Y и слишком сконцентрирован на деталях своей конкретной ситуации. Обычно лучше игнорировать таких людей, пока они не сформулируют свою проблему лучше.
Вопрос:
Как сконфигурировать приглашение командного интерпретатора?
Ответ:
Если вы достаточно умны, чтобы этим заинтересоваться, вам хватит ума воспользоваться поиском и найти ответ самостоятельно.
Вопрос:
Можно ли преобразовать AcmeCorp-документ в Tex-файл с помощью программы преобразования файлов Bass-o-matic?
Ответ:
Попробуйте и узнаете. Так, во-первых, узнаете ответ, а, во-вторых, перестанете тратить моё время.
Вопрос:
Моя {программа, конфигурация, мой оператор SQL} не работает
Ответ:
Это вообще не вопрос, и я не собираюсь задавать ещё десяток наводящих вопросов, чтобы выяснить, в чём на самом деле состоит ваша проблема — у меня есть дела и поинтереснее. Когда я вижу подобные вопросы, то обычно посылаю один из следующих ответов:
Вам к этому больше нечего добавить?
Ой, это очень плохо. Надеюсь, вы уже это исправили.
И какое это имеет отношение лично ко мне?
Будьте великодушны. Связанный с проблемой стресс может делать невежливыми или глупыми людей, которые таковыми не являются.
На первую ошибку укажите в частном порядке. Нет необходимости публично унижать человека, который возможно, честно ошибается. Начинающий пользователь может не знать, как искать в архивах или где находится или публикуется список часто задаваемых вопросов (FAQ).
Если вы не уверены, так и говорите! Ошибочный, но авторитетно звучащий ответ хуже, чем отсутствие ответа. Не направляйте людей по ложному пути просто потому, что вам приятно быть в роли эксперта. Будьте скромны и честны. Показывайте хороший пример для спрашивающих коллег.
Если вы не можете помочь, не мешайте. Не шутите по поводу процедур, которые могут разрушить среду пользователя — этот болван может принять ваши шутки как руководство к действию.
Задавайте дополнительные вопросы, чтобы получить больше информации. Если это делать правильно, спрашивающий кое-чему научится, — да и вы тоже. Попытайтесь превратить плохой вопрос в хороший, и помните, все мы были когда-то начинающими.
Хотя простой ответ RTFM бывает оправдан, когда даётся просто лентяю, ссылка на документацию (даже если это набор ключевых слов для поиска в Google) всё же лучше.
Если уж вы отвечаете на вопрос, давайте ответ по сути. Не предлагайте наспех придуманные обходные пути, если используется в принципе не то средство или неверный подход. Предлагайте хорошие средства. Переформулируйте вопрос.
Помогите сообществу извлечь пользу из вопроса. Когда встречаетесь с хорошим вопросом, спросите себя: «Как надо изменить соответствующую документацию или список ЧаВО, чтобы больше этот вопрос никто не задавал?» Затем отправьте соответствующее дополнение тому, кто поддерживает эти документы.
Если для ответа на вопрос пришлось провести исследование, поделитесь своим опытом, а не пишите так, как будто ответ свалился на вас с неба. Ответить на один хороший вопрос — это как накормить голодного один раз, а вот изложить методику исследования на примере, — значит научить добывать еду на всю жизнь.