Pull to refresh

Comments 32

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

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

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

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

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

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

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

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

UFO just landed and posted this here
Вопрос «какой результат ты хочешь получить» (хорошо преобразующийся в «зачем тебе это вообще») часто подразумевает, что «самопровозглашенный гуру» представляет себе ансамбль типичных результатов, достижение которых путем, требующим решения данной конкретной проблемы, оказывается совершенно неоптимальным.

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

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


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

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

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

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

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

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

Articles