На различных Q&A-сайтах и форумах, связанных с разработкой, я провёл времени больше, чем хотелось бы признавать. Там я ответил на тысячи вопросов. Как правило, вопросы остаются в границах таких форумов. Но после того, как вопросы начали сыпаться на мой личный почтовый ящик, я подумал, что надо написать об этом.

Эти электронные письма и сообщения обычно поступают от людей, с которыми я никогда раньше не общался — все они просто знают, что я «отвечаю на вопросы или решаю проблемы». Всё обычно выглядит примерно так:

• Я написал вопрос по ссылке {здесь}. Могли бы вы исправить ошибку?
• Привет, пожалуйста, помогите здесь {ссылка}.
• У меня есть серьёзное домашнее задание со сроком сдачи сегодня в 5 вечера, и мне с ним не справиться. Могли бы вы скачать его здесь {ссылка} и сделать так, чтобы к тому времени оно работало?

Это полные тексты реальных электронных писем, которые я нередко получаю.

Не имею ничего против людей, которые просят о помощи, поэтому я и участвую в сообществах вопросов и ответов. Дело в том, что есть много неправильных способов обратиться за помощью, в частности — плохие вопросы.

Здесь я укажу несколько причин, по которым такие прямые запросы остаются без ответа, напишу, как действовать, чтобы получить ответ на вопрос, и представлю несколько шагов, которые вы должны сделать до отправки вопроса, чтобы он не оказался плохим.

Как получать ответы

На разных форумах и сайтах, таких как Stack Overflow, есть много вопросов, оставшихся без ответа. Основная причина: большинство этих вопросов — просто плохие.

Если вы желаете задать вопрос, попробуйте пройтись по списку ниже, чтобы ваш вопрос не ушёл в безответное небытие:

• Вы погуглили ваш вопрос? Серьёзно. Просто скопируйте точное сообщение о вашей ошибке и потратьте несколько минут на чтение результатов выдачи. Это решит 90%+ всех проблем, с которыми вы сталкиваетесь.
• Хорошо, Google не помог. Что дальше? Я вам не верю. Поищите ещё, попробуйте изменить некоторые условия поиска и удалить всё специфическое для конкретного вашего случая (например, название проекта и т.д.).
• Может быть, спросить коллегу? Если вы работаете в команде, то попросите помочь. Две головы часто лучше, чем одна, и обычно найти ответ, сидя рядом с кем-то, легче, чем через Интернет.
• Нет коллеги? Как насчёт утёнка? Я знаю, что это может показаться глупым, но нередко метод утёнка помогает взглянуть на проблемы со стороны или даже решить их. Просто попробуйте озвучить точно вашу проблему кому-нибудь (или чему-нибудь) и посмотреть, щёлкнет ли что-нибудь в вас. Я знаю, это звучит глупо, но вы удивитесь, насколько эффективным может быть результат.
• Рассмотрите возможность проверки в «нишевых» точках. Если применимо, то рассмотрите возможность проверки репозитория GitHub для конкретной проблемы или вопроса. Или используйте функцию поиска на некоторых «нишевых» форумах или сайтах (например, «отправка электронной почты в MVC» на форумах ASP.NET). Кстати, эти сайты могут не индексироваться, поэтому их труднее найти в выдаче поисковой системы.
• Всё-таки ничего. Что делать? Если вам всё-таки не повезло, тогда, вероятно, пора задать вопрос где-нибудь. Опять же — скорее всего, похожую проблему решали до вас, но вы обнаружите это лишь позже.

Как задать (правильный) вопрос

Итак, вы просмотрели всю Сеть. Вы выполнили бесчисленные поиски по каждой комбинации поисковых терминов и синонимов, которые только можно себе представить, и всё равно — ничего.

Наверное, настало время задать вопрос. Давайте рассмотрим несколько вещей, которые вы должны помнить в этом процессе:

• Заголовок — это всё! Описательный и содержательный заголовок вашего вопроса имеет исключительное значение. Заголовок должен передавать основную проблему (например, «Null Reference Exception в ASP.NET Telerik GridView при разбиении на страницы» вместо «Помогите! GridView не работает»). Если ваш заголовок достаточно описательный, то его прочитают, а чем больше людей прочитает его, тем больше шансов получить ответ.
• Не забрасывайте сеть слишком широко. Не нужно описывать всё ваше приложение и его общее назначение. Будьте проще и сосредоточьтесь только на одной проблеме или на одном варианте использования. Чем выше фокус, тем выше вероятность того, что вы получите результаты.
• Конкретнее. Будьте настолько конкретными, насколько сможете. Не заявляйте просто, «что-то не работает». Укажите точно, что вы пытаетесь выполнить, что вы пробовали и какой результат вы ожидаете получить.
• …Но не слишком. Хотя важно включать детали, не переусердствуйте. Не надо вставлять огромные куски HTML, CSS, Javascript, SQL и другого кода, прокручивая через которые можно заработать кистевой туннельный синдром — такое отпугивает. Опять же — кратко и только нужные детали.
• Не гадайте с ошибками. Если ваш вопрос связан с ошибками, попробуйте включить точное сообщение об ошибке из системы, а не использовать: «Кажется, случилось или вывело то-то». Специфика имеет значение; иногда ошибка при компиляции и ошибка при выполнении — вещи совершенно разные, поэтому пусть ваши возможные читатели знают, что и когда происходит.
• Это воспроизводится? Тогда воспроизведите проблему. Если вашу проблему можно легко воспроизвести и, что важно, расшарить её, то постарайтесь это сделать. Либо кратко объясните шаги, необходимые для проявления проблемы, либо рассмотрите возможность использования онлайн-инструмента для обмена кодом. Например, попробуйте JSBin или сниппеты Stack Overflow, чтобы создать пример, похожий на ваш.
• Прочитайте ваш вопрос — дважды. Прежде чем нажимать кнопку отправки, скорее всего, зелёного цвета, прочитайте вопрос. Затем прочитайте его ещё раз. Если что-то выглядит не так или неправильно, попробуйте переделать. В основном, сосредоточьтесь на определении того, понятен ли ваш вопрос, и помните, что он должен быть понятным для совершенно незнакомого вам человека.
• Всё шаги позади, а проблема там же? Тогда задавайте свой вопрос и надейтесь на лучшее. По мере обсуждения вашей проблемы вы быстро обнаружите, что именно вы объяснили хорошо, что недостаточно; просто следите за ответами и редактируйте по необходимости.

Провели несколько часов, постоянно обновляя экран, и всё же ничего? Если у вас есть быстро приближающийся дедлайн, то вы можете прийти к осознанию того, что находится в центре внимания следующего раздела: ваша проблема — не их проблема.

Ваша проблема — не моя проблема

Я знаю, это может звучать грубо, но так оно и есть.

Слишком часто вопросы и просьбы изобилуют срочностью: дедлайн через несколько часов, проект нужно сдать в ближайшее время и т.п. Как бы я ни хотел помочь вам, но в сутках просто слишком мало часов. У меня есть свои собственные сроки и проекты. А ещё есть у меня есть жизнь за пределами разработки, которую я ценю больше всего на свете.

Избегайте любых выражений, связанных со срочностью в ваших вопросах, таких как «ПОМОГИТЕ!», «СРОЧНО» или любых других фраз, которые соответствуют этому регулярному выражению: [A-ZА-Я!]+.

Вероятно, образовательная система научила вас, что откладывание «на потом» бывает делом ужасным. То же верно в программировании. Вот почему своевременное начало работы может дать достаточно времени для решения любых серьёзных проблем, с которыми вы столкнётесь (самостоятельно или со сторонней помощью).

Этот урок должен усвоить в какой-то момент каждый: спешка, как правило, не ускоряет решение проблемы. Задавайте внятный вопрос за адекватный объём времени и поместите его в надлежащий раздел, чтобы читатель успел ознакомиться с вопросом и ответить на него.

Будьте профессионалом (а не тупицей)

Дедлайн и срочность могут вызывать серьёзный стресс. Любой, кто профессионально разрабатывал программное обеспечение, знает, что утверждение выше — большое преуменьшение.

Однако стресс — не оправдание для того, чтобы действовать, как тупица. Я видел немеряно вопрошающих, просто уничтожающих того, кто попытался помочь. Крик «это не сработало» заглавными буквами или «это глупый ответ» не принесёт вам никаких плюсов и, конечно же, не выманит никого на поле боя ради помощи незнакомцу.

Помните, что помогающие вам люди делают это полностью добровольно. Они тратят своё время и силы, чтобы помочь вам преодолеть трудную ситуацию. Не забывайте об этом, когда собираетесь переключиться в верхний регистр клавиатуры в ответе.

Люди тратят своё время, чтобы ответить на ваш вопрос, получая лишь несколько сомнительных интернет-баллов, поэтому просто учитывайте это во время всего процесса.

Особенно плохо получается, когда вопрошающий находит чей-то адрес электронной почты и решает штурмовать людей напрямую вместо того, чтобы спрашивать на форумах.

(Слишком) личное общение

Скажу для начала: я не против писем на мою почту, когда кому-то нужна помощь. Я охотно оторвусь от своих дел и напишу вам, если вы обратитесь — но вежливо.

Чаще всего мне присылают ссылки на уже опубликованные вопросы на форумах или Stack Overflow. Обычно, когда я перехожу по ссылке, решение уже есть. Если нет, то я уделю немного времени и постараюсь помочь, если смогу.

Есть другое семейство писем, на которые отвечать не так приятно и которые редко заслуживают ответа. Это потому, что они не следуют ни одному из правил, которые я сформулировал выше.

Ситуация немного иная, когда вы обращаетесь к кому-то напрямую. Некоторые подходы остаются теми же, но здесь есть свои собственные ключевые моменты:

• Ещё раз — что вы делали? Если я не вижу от вас никаких намёков на попытки решить свою проблему, то я тоже не вижу причин её решать (см. выше «Ваша проблема — не моя проблема»).
• Это тот человек? Убедитесь, что тот, с кем вы связываетесь, в состоянии вам помочь.
• Не сердитесь. Столкновение с проблемой может быть обескураживающим, поверьте мне, я это понимаю. Трудность возникает, когда вы решаете дать себе выход, отправив мне электронное письмо, как будто я та персона, которая создала проблему. Так очень легко не получить ответа.
• Будьте терпеливыми. Как и в случае с форумом, если вы пришлёте мне вопрос, то я не остановлю все свои дела, чтобы ответить на него. Когда я получу возможность взглянуть на него, я сделаю это — но, пожалуйста, не засыпайте мою почту обновлениями каждые пять минут.

Я не хочу кого-то отговаривать от обращения за помощью напрямую. Но, пожалуйста, убедитесь, что сначала вы в достаточной мере исчерпали другие ресурсы. Мне абсолютно не хочется читать очередное письмо «почему jQuery не работает».

Итоги

Надеюсь, этот пост не выглядит как ворчание о ваших вопросах. Также не хочу, чтобы кому-то показалось, что речь идёт конкретно о нём. Этот пост — лишь о некоторых действиях, которые помогут не задавать плохие вопросы, что, в свою очередь, приведёт к плохим ответам или их отсутствию.

Находчивость — это одна из самых важных способностей разработчика. Если разработчик может находить ответы и решать проблемы самостоятельно, то, скорее всего, у него больше времени уйдёт на выполнение задач, а не раздумья, почему они не получаются.

Если вы сталкиваетесь с проблемой, которая снова и снова не находится в поисковике, а решение продолжает ускользать от вас, то вот тогда следует задать вопрос. Просто убедитесь, что вы его достаточно обдумали и действительно постарались, чтобы сделать ваш вопрос достойным ответа.

И лучше, чтобы вопрос не был «почему jQuery не работает».