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

Пробуйте очевидное

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

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

1. Внимательно читаю сообщение об ошибке. Возможно, ответ кроется где-то в тексте или стектрейсе. Например, мы можем увидеть, что сборка не удалась из-за неудачной проверки стиля в коде.
2. Пробую самое простое решение. Может проблема с подключением к сети? Кабель подключен? Что, если откатить последние изменения или использовать git stash?
3. Провожу внутренний поиск. Есть документация, затрагивающая эту базу знаний? Это известный баг? Кто-то уже работает над устранением проблемы?
4. Провожу внешний поиск. Возможно, на Stack Overflow уже есть ответ на вопрос.

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

Как просить о помощи

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

1. Что я пытаюсь сделать и в чем проблема?
2. Как я пытался решить проблему?
3. Что именно не работает так, как мне нужно?
4. Чего я достиг в решении проблемы?
5. Сам вопрос.

Например, возникли проблемы с тестированием сборки. Я бы задал вопрос так:

Я пытаюсь собрать iOS-проект строго по инструкции, но сборка не выполняется из-за ошибки. Я следовал инструкции по настройке среды разработки и проверил пакеты X и Y. По инструкции я построил Y, потом X. В результате сборка X провалилась, в ошибке сказано, что в Y отсутствует зависимость. Я убедился, что в Y есть зависимость, указанная в его файле конфигурации. Подскажите, это я что-то не так делаю или Y неправильно импортирует файл?

В этом примере мы сначала обозначили цель (собрать iOS проект) и проблему (ошибка). Далее рассказали, как пытались ее решить (читали инструкцию, проверили зависимость) и что конкретно не работает (отсутствует зависимость). А в конце мы указываем, какая именно помощь нам нужна (проверка кода / проверка импорта файла).

Может показаться, что это все излишне. Почему нельзя просто сказать «не работает сборка»? Можно и так, все зависит от собеседника. Вот почему я придерживаюсь детального подхода:

1. Структурируя вопрос, я показываю, что уважаю время собеседника. Подробно расписывая проделанные шаги, я экономлю другому человеку время на решение моей проблемы.
2. Подготовка вопросов позволяет мне лично убедиться в том, что я обстоятельно подошел к решению проблемы и сделал все, что мог.
3. Конкретный вопрос, в отличие от стандартного «Кто разбирается в iOS и поможет мне со сборкой?», поможет привлечь именно тех, кто разбирается в моей проблеме. Ведь человек может знать iOS, но конкретно с моей проблемой не сталкивался.

Что делать, если никто не может помочь

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

1. Продолжайте копать. Иногда вы работаете над чем-то новым и недостаточно изученным, и вам нужно больше времени на исследование этой области.
2. Пересмотрите свой подход. Случается, что вместо использования общепринятого решения вы изобретаете собственное. Это случилось и со мной, когда я встроил приложение Django в автономный исполняемый файл OSX. Я могу быть первым, кто до этого додумался. Это плохой знак! Возможно, вам стоит вернуться назад и выбрать другой подход к решению поставленной задачи.

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

Просить о помощи не стыдно

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

***

Желаем удачи и надеемся, что вы найдете решение всех проблем, с которыми столкнетесь!

Материалы по теме

• 5 привычек малоэффективных удаленных сотрудников
• Как не «сгореть на работе», если ты программист
• ТОП-5 книг для программиста по управлению программистами

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста». Интересно, перейти к каналу