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

Дисклеймер: примеры выдуманные, но основаны на опыте автора. Любые совпадения имён и ситуаций случайны!

Пример №1: «Привет, есть проблемка»

Представим, что в один прекрасный день нам в ЛС написал Кларк Кент (решил стать разработчиком):

Привет! У меня тут проблема: сборка не собирается, не знаю, что делать(

Как думаешь, что не так в запросе, который был задан выше? Представь, что в моменте у тебя большой поток входящих сообщений и, в принципе, часто приходится быстро менять контексты. Что можно понять из этого сообщения? Верно, из него ничего невозможно понять! Какая именно сборка: (CI или локальная)? По какой причине она не собирается? Какая ошибка?

А теперь давай подумаем, как можно было бы перефразировать этот запрос, чтобы стало чуточку понятнее.

Привет! При сборке на CI появился такой лог: error: IllegalArgumentException("some interesting error"). Не могу понять, как это починить. Подскажи пожалуйста

Стало лучше, но, кажется, пока всё-таки не до конца.

Ты можешь сказать: «У запроса появились подробности, что теперь тебе не нравится привередливый техлид?» Подробности действительно появились, но почему разработчик сам даже не попробовал разобраться с проблемой? По сообщению выглядит так, что он пришёл с ошибкой сразу, как только на неё наткнулся (оно может быть ошибочным, но зачастую именно так и есть).

Теперь может появиться вопрос: «А как можно понять, что человек потратил на проблему время и только после этого пришёл с просьбой помочь?»

Давай посмотрим на пример.

Привет ! При сборке на CI появился такой лог: error: IllegalArgumentException("some interesting error"). Я провёл ресерч, локально эта проблема не воспроизводится. При других настройках CI этой проблемы тоже нет. Она почему-то появляется только тогда, когда я открываю пул-реквест в development ветку.

В голове сразу появляется вопрос: «А смотрел ли Кларк документацию на наш CI?» Если бы посмотрел, то мог заметить, что dev pipeline отличается от других своими настройками. И это нормальная ситуация, когда какие-то проверки падают именно тогда, когда Кларк открыл пул-реквест в дев. В таком случае его можно просто направить в доку.

А что, если все таки проблема никак не разрешается и человек потратил на нее время? Кажется, что в таком случае запрос может выглядеть подобным образом:

Привет! При сборке на CI появился такой лог: error: IllegalArgumentException("some interesting error"). Я провел ресёрч, локально эта проблема не воспроизводится. При других настройках CI этой проблемы тоже нет.

Она воспроизводится только при сборке в дев, потому что на таких сборках другой пайплайн. Но в чём именно корень ошибки, пока не понятно. Сейчас у меня план такой: проставить логи в пайплайне и узнать, в чём именно проблема, либо лучше просто скипнуть проверку, которая падает, чтобы успеть в релиз.

Чем этот запрос лучше предыдущего? Несколькими факторами.

• Человек действительно потратил время, чтобы выяснить кейсы, в которых появляется проблема.

• Он накидал короткий план с вариантами решения проблемы.

• Смог погрузить в контекст текущей проблемы.

Такой запрос мне нравится больше. А каково твоё мнение, дорогой читатель?

А пока давай перейдём к следующему примеру.

Пример №2: «Надеюсь, я угадал»

Представим, что в один прекрасный день нам написал Чарльз Ксавьер:

Привет! У меня тут сложный баг: кнопка пропадает после того, как пользователь на неё нажмёт. Баг воспроизводится на проде, а мы воспроизвести не можем. Я сделал фикс, и мы закатили его в прод. Надеюсь, я угадал.

Ты можешь спросить: «А что тут плохого? Человек уже решил проблему и просто поделился с тобой».

Максимально в таком сообщении может напрячь формулировка «надеюсь, я угадал». Разработчик не имеет права пользоваться такими формулировками, особенно если он что-то отправляет в прод.

По сути, если к вам приходит разработчик и пишет фразы подобного рода: «надеюсь, угадал», «по моим ощущениям», «мне так кажется», «вроде», — то стоит серьёзно насторожиться. Это не системный подход. В технических вопросах не стоит полагаться на интуицию. ПО работает не по нашей интуиции. У любой проблемы всегда есть причины. Иногда причины бывают очень специфическими, но всё равно у каждой проблемы они есть.

А как можно улучшить этот запрос ?

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

Стало лучше. В идеале мы, конечно же, хотим сразу исправить проблему.

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

Перейдём к следующему примеру.

Пример №3: краткость — сестра таланта

Представим, что в один прекрасный день к нам написал  Уэйд Уилсон:

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

А теперь перейдём к следующему примеру.

Пример 4: «Привет, го созвон, срочно»

Представим, что в один прекрасный день нам написал  Эммет Браун:

Привет! У меня срочный вопрос, давай созвонимся.

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

А как этот запрос можно было бы улучшить? На самом деле, это вопрос неоднозначный. Мне в голову приходит только одна ситуация, где это может быть уместно (но, возможно, ты в комментариях сможешь накидать ещё ситуаций):

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

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

Пример 5: «Гугл»

Привет! Подскажи пожалуйста, как мне покрасить кнопку?

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

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

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

Выводы

Думаю, что все примеры, приведённые выше, можно подытожить небольшой формулировкой: «Перед тем как написать кому-то, нужно всегда ставить себя на его место и думать, как можно написать так, чтобы человек сразу погрузился в контекст и понял суть проблемы».

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

Накидывайте свои примеры в комментах :)