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

Привет!

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

Плохо:
— прив как выхи прошли))) я тут пытаюсь короче собрать проект но у меня не работает падает почемуто О_о хотя вроде я все сделал как надо, подойди пожалуйста))))) тут вообщем в консоли чтото непанятное у меня((( уже прям всё попробывал ничего не работает, аааа(
Хорошо:
— Привет, я пытаюсь запустить проект, но возникла проблема. Падает сразу после команды docker-compose up, вот лог запуска и ошибка: [...] Можешь подсказать как решить?

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 32

    +2
    Все это формулируется одной фразой: «Чтобы задать правильный вопрос — ты должен знать 50% ответа»
      +2
      Немного не так — «Правильно заданный вопрос – половина ответа».
      А вообще прежде чем задать вопрос я бы рекомендовал использовать "Метод утёнка"

        +2
        Метод утёнка хорош для людей, которые уже знают что и как делают, но заблудились в трёх соснах, т.к. взгляд замылился.
          0
          Во втором случае так же хорош, т.к. заставляет не пропускать хорошо знакомые места, а заострять на них внимание.
      +4
      Решить, что вы никогда не станете разработчиком, потому что весь мир против вас, и даже работающие примеры не работают. Бросить обучение;

      Всегда так делаю!
        +3
        Можно я прокомментирую статью примером реально диалога, произошедшего со мной неделю назад?
        — *Вопрос про longpoll*
        — *Даю ссылку на документацию где всё замечательно расписано*
        — *Пример кода, который не работает с абсолютно глупейшей ошибкой*
        — Ты бы теорию изучил прежде чем что то писать, как это всё устроено.
        — Ты пойми мне 17, как думаешь я люблю читать?

        После этого не нашёлся что ответить. :)
        Подозреваю что вашу статью НЕ прочтут именно такие люди.
          +1
          Есть очень большая проблема, связанная с тонкой гранью между необходимостью отправить человека читать и желанием это сделать ради повышения ЧСВ.

          Вот, например, комментарий из старой статьи про «токсичность».
            0
            У моего собеседника как раз не хватает базового понимания как это всё работает. Я и сказал ему про это.
            0
            Конечно, такие будут всегда. И раз уж они проходят стажировку в компании, где я работаю, то они либо следуют нашим правилам, либо стажировка для них заканчивается. Поэтому всем менторам разрешается вместо ответа на плохо поставленный вопрос присылать ссылку на этот текст (раньше он хранился в гугл-доке).
              0
              Я бы после этого сразу прекратил оказывать помощь. Всё равно у того, кто не любит читать, нет шансов достичь хоть каких-то успехов в ИТ.
                0
                Чем докажите?
                  0
                  Не знаю, чем ваш собеседник докажет, но я б доказал этим.
                  Не берусь утверждать за всё ИТ, но в программировании точно далеко не уехать без желания читать документацию (а документация есть у всего).
                  +1
                  Ну любить читать, может быть и не обязательно, но принять этот факт — необходимость.
                +3
                Было бы неплохо разместить эту статью на «Тостере», с обязательным изучением оной при регистрации.
                А пока я буду лично делиться ссылкой на нее, при каждом удобном случае.
                  0
                  Спасибо! Надеюсь, она сделает жизнь многих опытных разработчиков значительно проще, а многих неопытных — качественнее.
                  +3
                  Подумать о том, что вас могут спросить, и заранее подготовить ответы
                  Страх показаться некомпетентным — это последний рубеж борьбы с багами, который зачастую творит чудеса, помогая решать совершенно головоломные проблемы.

                  Если у вас всё в порядке с фантазией, можете использовать метод утёнка.
                    –2
                    Говори тихо
                    Проси мало
                    Уходи быстро
                      +1
                      Универсальный темплейт для вопроса технического плана:
                      Я решил использовать XXX для YYY. При обращении XXX к YYY с ZZZ я получаю ошибку. Вот версия моего окружения: OS, libs, etc. Подскажите, при обращении с XXX к YYY с ZZZ — вы тоже получаете ошибку? И если да — как мне выяснить, она связана с XXX или YYY?

                        –5
                        Морализаторство IMHO. Напоминает FIDO в 90-е. Когда вместо ответа, самопровозглашённые «гуру» начинают тебя лечить — «а тебе это зачем вообще»… С тех пор вопросы задаю, в основном, на зарубежных форумах, чтобы вместо совета по-делу не направляли читать какую-то хрень типа данной статьи. Культура задающих вопросы нынче в рунете выше чем культура тех кто вместо советов по делу доказывает что он альфа-самец. IMHO
                          +3
                          Это логично. Я, как человек с опытом, не могу дать совет человеку без опыта, если не понимаю, что и зачем он делает. Если он в цикле for использует return, то я не говорю ему что тут надо поправить — я начинаю с вопроса «чего ты ожидаешь от этой функции»? Дальше прошу по строчкам объяснить, что на его взгляд делает код. Так человек сам доходит то того, что код написан плохо.
                            0

                            Не понял, а какой смысл возвращать какое-то значение из управляющей структуры? Это же не функция...

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

                            При этом да, снобизм и высокомерие тоже никто не отменял. Просто не всегда вопрос «зачем это нужно» является снобизмом.
                            0
                            Статью писали, явно не «айтишники», все что нужно тем кто работает или собирается в передовых технологиях это обучаемость и самостоятельное гугление постоянно!
                              +2
                              А разве не об этом написано в статье?
                                +1
                                Не соглашусь. Не всегда гугление приходит на помощь, не всегда это достаточно быстро. Вот, например, мой вопрос о зависании Ethernet-адаптера под Windows 10. В сети нет ни строчки информации конкретно по моему случаю, все общепринятые методики вроде игры с драйверами и сброса настроек WinSock я перепробовал. В итоге, спустя два дня поисков и экспериментов я таки нашёл решение, причём оно добыто сугубо эмпирическим путём. Не всегда есть возможность и время ковыряться в проблеме.

                                Или вот ещё, хорошо структурированный вопрос, с описанием экспериментов и поисков, которые не дали положительного результата. Честно говоря, я так и ждал ответов в духе «выбрось это старьё», но, видимо, это свойственно только русскоязычным форумам, как ни печально это осознавать.
                                  0
                                  Моя вина, я не уточнил что я разработчик и коментил с точки зрения разраба, гугл не помогает если разраб работает в той сфере где маленькое сообщество или это новое направление, как правило в таких сферах головастые и опытные люди уже, а вот для начинающего разраба можно 98% инфы найти в интернете (и это не про скупые русскоязычные ресурсы, а первоисточники) + надо уметь искать информацию, как внизу уже писали.
                                +1
                                С первым пунктом все тривиально: если текст ошибки вам совсем непонятен — копируете его в гугл, и вдумчиво читаете текст по ссылкам.


                                Практика показывает, что не всегда тривиально. Или стоит уточнить определение «вдумчиво читать» :)
                                Я бы добавил — «Если нашёл ответ в интернете, убедись, что понял его».
                                Потому что встречаются любители SODD — код тупо скопировали, а потом сюрпризы на ревью случаются (и хорошо, если на ревью)…

                                P.S. А статья, в целом — отличная.
                                  +4
                                  Вообще говоря, один из самых полезных навыков для начинающего IT-шника — умение экспериментально находить причину проблемы или, как минимум, примерную область, в которой эта проблема обосновалась. И это прям must have для задавания правильных вопросов.

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

                                  Звучит как очевидная вещь, но на форумах (в т.ч. зарубежных) часто вижу, что этого понимания не хватает.

                                  Тут главное — не доверять своим предположениям, а просто пробовать. Иначе можно потратить кучу времени на поиск проблемы в логике кода, а потом окажется, что просто выбранный индикатор не работал.
                                    +1
                                    Пора писать статью «Как правильно отвечать на вопросы, если Вы — айтишник со стажем» :)
                                    Автору спасибо за текст, оч хорошая адаптация старого доброго материала
                                      0
                                      Сегодня подумал: странно что на хабре не было раскрыто этой темы. Может народ научится думать прежде чем задавать вопросы помощи или писать ненужные статьи. Задумался об адаптации той статьи из 90х (в 2004 году уже третья версия вышла) и быстрый хабрапоиск привел сюда.

                                      И тут до меня дошло: к сожалению, те люди, которым бы следовало ее прочитать, просто пройдут мимо.
                                        0
                                        На это есть люди, которые ее прочитали — будут давать ссылку :)

                                      Only users with full accounts can post comments. Log in, please.