Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет!
Последние пару лет очень много занимаюсь с людьми, которые только начинают свою карьеру в ИТ. Поскольку и сами вопросы, и манера их задавать у многих людей похожи, я решил собрать свой опыт и рекомендации в одном месте.
Давным-давно я прочитал статью 2004-го года авторства Эрика Рэймонда, и всегда в карьере неукоснительно ей следовал. Она довольно большая, и заточена скорее под системных администраторов. Мне же приходится помогать людям, зачастую вообще не имеющим опыта в разработке, стать джуниорами и начать свою карьеру.
Тем, кто уже стал, или еще только мечтает стать начинающим разработчиком, я могу дать следующие рекомендации:
А теперь подробнее.
Вы изучаете какой-то язык программирования по книге или курсу. Взяли пример кода, запустили его, но он упал с непонятной для вас ошибкой. Если верить книге — он должен работать. Но вы верите глазам — он не работает. Какие есть варианты?
Какой вариант правильный? Вот он:
Понять, что вы не уникальны (что бы там не говорили мама с бабушкой), а ИТ мир не так прост, как об этом трубят, когда зовут на курсы и вебинары.
Понимание того, что вы не уникальны, приводит к осознанию, что ваша проблема наверняка уже встречалась у десятков, сотен, тысяч людей. Если вы начинающий разработчик, то запросто могли что-то не заметить, не установить или не настроить. Вот чеклист, по которому я предлагаю пройти прежде, чем вы поймете, что самостоятельно решить проблему вы не можете, и вам нужна помощь:
С первым пунктом все тривиально: если текст ошибки вам совсем непонятен — копируете его в гугл, и вдумчиво читаете текст по ссылкам.
Второй: например, если ваш код упал с ошибкой “Не могу подключить стороннюю библиотеку”, то дело не в вашем коде. Дело в том, что вы не установили какую-то библиотеку, которую хотите использовать. Значит, нужно искать как ее установить, а не как починить ваш код.
Третий и четвертый весьма похожи: Что если проблема именно в этой библиотеке, и мне просто нужно поискать другую? Что если я вообще не буду использовать стороннюю библиотеку, а напишу свой код используя стандартные средства?
Пятый пункт подводит нас к следующей части: подумайте, что может спросить вас человек, к которому вы обратитесь, и держите ответы наготове.
Цель — это то, что вы хотели сделать. К примеру, написать код, который ходит в интернет и сохраняет 10 картинок со смешными котиками. Проблема — это то, почему вы видите ошибку в консоли, но не видите 10 смешных котиков. Не начинайте свой вопрос с проблемы. Начинайте его с цели, заканчивайте проблемой. Если человек, к которому вы обращаетесь за помощью, опытный разработчик и много знает, то наверняка он сможет предложить вам более простое и изящное решение проблемы. Если вы уже выбрали самое простое и изящное — он четко будет понимать, что и зачем вы хотите делать, и это ускорит получение ответа.
Хороший вопрос:
Не нужно выливать на человека поток мыслей. Человек, к которому вы обратились за решением проблемы, занят своими делами. Сделайте так, чтобы он быстро понял, что у вас за проблема, и что вы от него хотите. Если с грамотностью у вас проблемы — используйте онлайн-сервисы проверки орфографии и пунктуации. Убрать из сообщения мусор вы можете и без онлайн сервисов. Не лейте воду, не начинайте издалека. Пишите кратко, ёмко, и по существу. Предоставьте примеры.
Плохо:
Не стоит писать вопрос личным сообщением конкретному человеку, если только вам не сообщили, что спросить следует именно его. Лучше написать группе людей, потому что:
Взгляните на последний пункт. Вы ведь уже усвоили, что проблемы надо стараться решать самостоятельно? Уже воспользовались поиском по чату/форуму/группе, но не нашли упоминания своей проблемы? Окей, тогда спрашивайте.
С другой стороны, не стоит беспокоить людей зря. По возможности исключите из списка адресатов всех, кто не может вам помочь. Чем больше сообщений приходит человеку, тем меньше шансов, что он прочитает их все. Не вырабатывайте у людей привычку выключать оповещения или просто игнорировать сообщения.
Наверняка, ваш опыт может быть полезен кому-то ещё. Сэкономьте время себе и другим, выложив ответ или решение. Следующий новичок, если он уже знает то, о чем мы здесь разговариваем, вообще не будет никого беспокоить — он найдет ваше решение поиском. Почему я говорю, что вы можете сэкономить время себе? Потому что вы можете столкнуться с этой проблемой через год, и не вспомните, как ее решали. Поиск снова спасёт.
Максимально упростите жизнь людям, у которых просите помощи.
Убедитесь, что ссылки, которые вы присылаете, работают. Попробуйте открыть ее в инкогнито режиме. Если по ссылке требуется авторизация, то вы увидите ошибку доступа. Например, если вы загрузили код в приватный репозиторий, или отправили ссылку на гугл диск, к которому доступ есть только у вас — человек увидит ошибку, и ему придется тратить время, чтобы сообщить об этом вам, а потом ждать, когда вы настроите доступ. Сделайте так, чтобы человек сразу увидел то, о чем вы говорите.
Не ожидайте, что кто-то захочет вспоминать, о чем вы спрашивали два дня назад. Пришлите информацию ещё раз, напомните контекст. Никому не хочется искать в переписке то, что есть у вас под рукой. Если вам лень продублировать информацию, чтобы люди не тратили своё время на поиск, значит, помощь вам не нужна.
Не выдирайте из контекста. Если присылаете лог с ошибкой, очевидно, что надо включить не только саму ошибку, но и код, вызвавший ее, с примером того, на чем он сломался.
Если для решения вашей проблемы есть установленный процесс — следуйте ему. Не стоит изобретать велосипед, если уже есть статья с пошаговым HowTo.
Не стоит добиваться ответа одного человека по разным каналам (писать в слак, скайп, телеграм) одновременно — человеку будет неприятно.
Не нужно писать одинаковое сообщение сразу нескольким людям, в надежде на то, что хотя бы кто-то вам ответит. Все эти люди могут дать вам ответ (скорее всего, он будет один и тот же), но все они на какое-то время отвлекутся от своих дел. Используйте групповые чаты.
Всё, о чём мы разговаривали здесь, применимо и за пределами сферы ИТ. Следуйте этим правилам в супермаркете, автосервисе, на отдыхе в другой стране, при общении с друзьями и родственниками. Покажите людям, что вы цените их время, и не хотите их напрягать по пустякам. Покажите, что вы потратили силы и время на то, чтобы решить проблему самостоятельно, но вам не удалось, и вам действительно нужна помощь. В благодарность люди с пониманием отнесутся к вашим проблемам, и помогут с их решением.
Последние пару лет очень много занимаюсь с людьми, которые только начинают свою карьеру в ИТ. Поскольку и сами вопросы, и манера их задавать у многих людей похожи, я решил собрать свой опыт и рекомендации в одном месте.
Давным-давно я прочитал статью 2004-го года авторства Эрика Рэймонда, и всегда в карьере неукоснительно ей следовал. Она довольно большая, и заточена скорее под системных администраторов. Мне же приходится помогать людям, зачастую вообще не имеющим опыта в разработке, стать джуниорами и начать свою карьеру.
Тем, кто уже стал, или еще только мечтает стать начинающим разработчиком, я могу дать следующие рекомендации:
- Изучайте проблему самостоятельно
- Сначала сообщайте цель, потом озвучивайте проблему
- Пишите грамотно и по существу
- Задавайте вопросы по адресу и делитесь решением
- Уважайте чужое время
- Смотрите шире
А теперь подробнее.
Изучайте проблему самостоятельно
Вы изучаете какой-то язык программирования по книге или курсу. Взяли пример кода, запустили его, но он упал с непонятной для вас ошибкой. Если верить книге — он должен работать. Но вы верите глазам — он не работает. Какие есть варианты?
- Решить, что вы никогда не станете разработчиком, потому что весь мир против вас, и даже работающие примеры не работают. Бросить обучение;
- Решить, что вы никогда не станете разработчиком, потому что слишком глупы или вам не дано. Бросить обучение;
- Начать спрашивать всех знакомых, кто хоть как-то связан с ИТ, требовать чтобы разобрались почему у вас не работает. Узнать много нового о себе, обидеться. Бросить обучение;
Какой вариант правильный? Вот он:
Понять, что вы не уникальны (что бы там не говорили мама с бабушкой), а ИТ мир не так прост, как об этом трубят, когда зовут на курсы и вебинары.
Понимание того, что вы не уникальны, приводит к осознанию, что ваша проблема наверняка уже встречалась у десятков, сотен, тысяч людей. Если вы начинающий разработчик, то запросто могли что-то не заметить, не установить или не настроить. Вот чеклист, по которому я предлагаю пройти прежде, чем вы поймете, что самостоятельно решить проблему вы не можете, и вам нужна помощь:
- Убедиться, что вопрос уникален и на него нет ответа в интернете
- Внимательно изучить причину проблемы, а не следствие
- Оценить возможные варианты решения проблемы, их плюсы и минусы
- Подумать над альтернативными вариантами достижения цели
- Подумать о том, что вас могут спросить, и заранее подготовить ответы
С первым пунктом все тривиально: если текст ошибки вам совсем непонятен — копируете его в гугл, и вдумчиво читаете текст по ссылкам.
Второй: например, если ваш код упал с ошибкой “Не могу подключить стороннюю библиотеку”, то дело не в вашем коде. Дело в том, что вы не установили какую-то библиотеку, которую хотите использовать. Значит, нужно искать как ее установить, а не как починить ваш код.
Третий и четвертый весьма похожи: Что если проблема именно в этой библиотеке, и мне просто нужно поискать другую? Что если я вообще не буду использовать стороннюю библиотеку, а напишу свой код используя стандартные средства?
Пятый пункт подводит нас к следующей части: подумайте, что может спросить вас человек, к которому вы обратитесь, и держите ответы наготове.
Сначала сообщайте цель, потом озвучивайте проблему
Цель — это то, что вы хотели сделать. К примеру, написать код, который ходит в интернет и сохраняет 10 картинок со смешными котиками. Проблема — это то, почему вы видите ошибку в консоли, но не видите 10 смешных котиков. Не начинайте свой вопрос с проблемы. Начинайте его с цели, заканчивайте проблемой. Если человек, к которому вы обращаетесь за помощью, опытный разработчик и много знает, то наверняка он сможет предложить вам более простое и изящное решение проблемы. Если вы уже выбрали самое простое и изящное — он четко будет понимать, что и зачем вы хотите делать, и это ускорит получение ответа.
Хороший вопрос:
Я хочу сохранять 10 смешных котиков каждый день, чтобы смеяться и продлевать себе жизнь. Для этого я написал вот такой код: [...]. Я ожидаю, что он будет подключаться к FTP серверу и загружать оттуда новые картинки. Однако, когда я запустил его, то увидел вот такую ошибку: [...] Хотя через браузер я могу зайти на этот сервер.Быстрый ответ:
Ты зря взял эту библиотеку, ее уже давно никто не поддерживает и не развивает. Возьми лучше вот эту — я сам скачиваю ей картинки с котиками!Плохой вопрос:
Привет, мой код выдал вот такую ошибку [...], ты не знаешь в чем может быть дело?Очевидный ответ:
Привет. Нет, не знаю.
Пишите грамотно и по существу
Не нужно выливать на человека поток мыслей. Человек, к которому вы обратились за решением проблемы, занят своими делами. Сделайте так, чтобы он быстро понял, что у вас за проблема, и что вы от него хотите. Если с грамотностью у вас проблемы — используйте онлайн-сервисы проверки орфографии и пунктуации. Убрать из сообщения мусор вы можете и без онлайн сервисов. Не лейте воду, не начинайте издалека. Пишите кратко, ёмко, и по существу. Предоставьте примеры.
Плохо:
— прив как выхи прошли))) я тут пытаюсь короче собрать проект но у меня не работает падает почемуто О_о хотя вроде я все сделал как надо, подойди пожалуйста))))) тут вообщем в консоли чтото непанятное у меня((( уже прям всё попробывал ничего не работает, аааа(Хорошо:
— Привет, я пытаюсь запустить проект, но возникла проблема. Падает сразу после команды docker-compose up, вот лог запуска и ошибка: [...] Можешь подсказать как решить?
Задавайте вопросы по адресу и делитесь решением
Не стоит писать вопрос личным сообщением конкретному человеку, если только вам не сообщили, что спросить следует именно его. Лучше написать группе людей, потому что:
- Каждый занят решением своих проблем. Шанс, что кто-то в общем чате или на форуме может уделить вам время — выше.
- Шанс, что кто-то в общем чате знает, как вам помочь — выше.
- Вы оставляете другим возможность найти этот же вопрос и ответ позже.
Взгляните на последний пункт. Вы ведь уже усвоили, что проблемы надо стараться решать самостоятельно? Уже воспользовались поиском по чату/форуму/группе, но не нашли упоминания своей проблемы? Окей, тогда спрашивайте.
С другой стороны, не стоит беспокоить людей зря. По возможности исключите из списка адресатов всех, кто не может вам помочь. Чем больше сообщений приходит человеку, тем меньше шансов, что он прочитает их все. Не вырабатывайте у людей привычку выключать оповещения или просто игнорировать сообщения.
Наверняка, ваш опыт может быть полезен кому-то ещё. Сэкономьте время себе и другим, выложив ответ или решение. Следующий новичок, если он уже знает то, о чем мы здесь разговариваем, вообще не будет никого беспокоить — он найдет ваше решение поиском. Почему я говорю, что вы можете сэкономить время себе? Потому что вы можете столкнуться с этой проблемой через год, и не вспомните, как ее решали. Поиск снова спасёт.
Уважайте чужое время
Максимально упростите жизнь людям, у которых просите помощи.
Убедитесь, что ссылки, которые вы присылаете, работают. Попробуйте открыть ее в инкогнито режиме. Если по ссылке требуется авторизация, то вы увидите ошибку доступа. Например, если вы загрузили код в приватный репозиторий, или отправили ссылку на гугл диск, к которому доступ есть только у вас — человек увидит ошибку, и ему придется тратить время, чтобы сообщить об этом вам, а потом ждать, когда вы настроите доступ. Сделайте так, чтобы человек сразу увидел то, о чем вы говорите.
Не ожидайте, что кто-то захочет вспоминать, о чем вы спрашивали два дня назад. Пришлите информацию ещё раз, напомните контекст. Никому не хочется искать в переписке то, что есть у вас под рукой. Если вам лень продублировать информацию, чтобы люди не тратили своё время на поиск, значит, помощь вам не нужна.
Не выдирайте из контекста. Если присылаете лог с ошибкой, очевидно, что надо включить не только саму ошибку, но и код, вызвавший ее, с примером того, на чем он сломался.
Если для решения вашей проблемы есть установленный процесс — следуйте ему. Не стоит изобретать велосипед, если уже есть статья с пошаговым HowTo.
Не стоит добиваться ответа одного человека по разным каналам (писать в слак, скайп, телеграм) одновременно — человеку будет неприятно.
Не нужно писать одинаковое сообщение сразу нескольким людям, в надежде на то, что хотя бы кто-то вам ответит. Все эти люди могут дать вам ответ (скорее всего, он будет один и тот же), но все они на какое-то время отвлекутся от своих дел. Используйте групповые чаты.
Смотрите шире
Всё, о чём мы разговаривали здесь, применимо и за пределами сферы ИТ. Следуйте этим правилам в супермаркете, автосервисе, на отдыхе в другой стране, при общении с друзьями и родственниками. Покажите людям, что вы цените их время, и не хотите их напрягать по пустякам. Покажите, что вы потратили силы и время на то, чтобы решить проблему самостоятельно, но вам не удалось, и вам действительно нужна помощь. В благодарность люди с пониманием отнесутся к вашим проблемам, и помогут с их решением.
