Хабрахабр

[Из песочницы] Как правильно задавать вопросы, если ты начинающий айтишник

Привет!

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

Она довольно большая, и заточена скорее под системных администраторов. Давным-давно я прочитал статью 2004-го года авторства Эрика Рэймонда, и всегда в карьере неукоснительно ей следовал. Мне же приходится помогать людям, зачастую вообще не имеющим опыта в разработке, стать джуниорами и начать свою карьеру.

Тем, кто уже стал, или еще только мечтает стать начинающим разработчиком, я могу дать следующие рекомендации:

  • Изучайте проблему самостоятельно
  • Сначала сообщайте цель, потом озвучивайте проблему
  • Пишите грамотно и по существу
  • Задавайте вопросы по адресу и делитесь решением
  • Уважайте чужое время
  • Смотрите шире

А теперь подробнее.

Изучайте проблему самостоятельно

Вы изучаете какой-то язык программирования по книге или курсу. Взяли пример кода, запустили его, но он упал с непонятной для вас ошибкой. Если верить книге — он должен работать. Но вы верите глазам — он не работает. Какие есть варианты?

  • Решить, что вы никогда не станете разработчиком, потому что весь мир против вас, и даже работающие примеры не работают. Бросить обучение;
  • Решить, что вы никогда не станете разработчиком, потому что слишком глупы или вам не дано. Бросить обучение;
  • Начать спрашивать всех знакомых, кто хоть как-то связан с ИТ, требовать чтобы разобрались почему у вас не работает. Узнать много нового о себе, обидеться. Бросить обучение;

Какой вариант правильный? Вот он:

Понять, что вы не уникальны (что бы там не говорили мама с бабушкой), а ИТ мир не так прост, как об этом трубят, когда зовут на курсы и вебинары.

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

  • Убедиться, что вопрос уникален и на него нет ответа в интернете
  • Внимательно изучить причину проблемы, а не следствие
  • Оценить возможные варианты решения проблемы, их плюсы и минусы
  • Подумать над альтернативными вариантами достижения цели
  • Подумать о том, что вас могут спросить, и заранее подготовить ответы

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

Дело в том, что вы не установили какую-то библиотеку, которую хотите использовать. Второй: например, если ваш код упал с ошибкой “Не могу подключить стороннюю библиотеку”, то дело не в вашем коде. Значит, нужно искать как ее установить, а не как починить ваш код.

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

Пятый пункт подводит нас к следующей части: подумайте, что может спросить вас человек, к которому вы обратитесь, и держите ответы наготове.

Сначала сообщайте цель, потом озвучивайте проблему

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

Хороший вопрос:

Для этого я написал вот такой код: [...]. Я хочу сохранять 10 смешных котиков каждый день, чтобы смеяться и продлевать себе жизнь. Однако, когда я запустил его, то увидел вот такую ошибку: [...] Хотя через браузер я могу зайти на этот сервер. Я ожидаю, что он будет подключаться к FTP серверу и загружать оттуда новые картинки.

Быстрый ответ:

Возьми лучше вот эту — я сам скачиваю ей картинки с котиками! Ты зря взял эту библиотеку, ее уже давно никто не поддерживает и не развивает.

Плохой вопрос:

Привет, мой код выдал вот такую ошибку [...], ты не знаешь в чем может быть дело?

Очевидный ответ:

Нет, не знаю. Привет.

Пишите грамотно и по существу

Не нужно выливать на человека поток мыслей. Человек, к которому вы обратились за решением проблемы, занят своими делами. Сделайте так, чтобы он быстро понял, что у вас за проблема, и что вы от него хотите. Если с грамотностью у вас проблемы — используйте онлайн-сервисы проверки орфографии и пунктуации. Убрать из сообщения мусор вы можете и без онлайн сервисов. Не лейте воду, не начинайте издалека. Пишите кратко, ёмко, и по существу. Предоставьте примеры.

Плохо:

— прив как выхи прошли))) я тут пытаюсь короче собрать проект но у меня не работает падает почемуто О_о хотя вроде я все сделал как надо, подойди пожалуйста))))) тут вообщем в консоли чтото непанятное у меня((( уже прям всё попробывал ничего не работает, аааа(

Хорошо:

Падает сразу после команды docker-compose up, вот лог запуска и ошибка: [...] Можешь подсказать как решить? — Привет, я пытаюсь запустить проект, но возникла проблема.

Задавайте вопросы по адресу и делитесь решением

Не стоит писать вопрос личным сообщением конкретному человеку, если только вам не сообщили, что спросить следует именно его. Лучше написать группе людей, потому что:

  • Каждый занят решением своих проблем. Шанс, что кто-то в общем чате или на форуме может уделить вам время — выше.
  • Шанс, что кто-то в общем чате знает, как вам помочь — выше.
  • Вы оставляете другим возможность найти этот же вопрос и ответ позже.

Взгляните на последний пункт. Вы ведь уже усвоили, что проблемы надо стараться решать самостоятельно? Уже воспользовались поиском по чату/форуму/группе, но не нашли упоминания своей проблемы? Окей, тогда спрашивайте.

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

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

Уважайте чужое время

Максимально упростите жизнь людям, у которых просите помощи.

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

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

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

Не стоит добиваться ответа одного человека по разным каналам (писать в слак, скайп, телеграм) одновременно — человеку будет неприятно.

Все эти люди могут дать вам ответ (скорее всего, он будет один и тот же), но все они на какое-то время отвлекутся от своих дел. Не нужно писать одинаковое сообщение сразу нескольким людям, в надежде на то, что хотя бы кто-то вам ответит. Используйте групповые чаты.

Смотрите шире

Всё, о чём мы разговаривали здесь, применимо и за пределами сферы ИТ. Следуйте этим правилам в супермаркете, автосервисе, на отдыхе в другой стране, при общении с друзьями и родственниками. Покажите людям, что вы цените их время, и не хотите их напрягать по пустякам. Покажите, что вы потратили силы и время на то, чтобы решить проблему самостоятельно, но вам не удалось, и вам действительно нужна помощь. В благодарность люди с пониманием отнесутся к вашим проблемам, и помогут с их решением.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть