Принимая поздравления и пожелания по поводу самых разных событий я регулярно отвечал на них, что я буду стараться соответствовать. Не понимаете о чем я? Ну, например, желают мне карьерных успехов и я такой — "Буду стараться". Так вот сегодня я себя поймал на этом (спасибо миру онлайн-коммуникаций, в котором проще, чем в оффлайновой жизни, сначала подумать, а потом ответить) и сказал, что стараться не буду, а просто буду что-то делать. Делать потому что это естественно для меня. И тогда так же естественно, что что-то обязательно получится. Хотя, возможно, и совсем не то, ради чего я из прошлого года, решил бы стараться!

А знаете, кто меня научил этой глубокой мысли? Мультик Удача, который мы недавно смотрели. Хотя, конечно, он просто лёг на хорошую почву, которую давно готовил один мой старый друг!

В общем, этот пост два в одном - рекомендация, что посмотреть, если вам она, вдруг, необходима в эти, возможно, тяжёлые постновогодние часы. И пожелание нам всем на Новый Год - давайте не стараться, а просто делать! Тогда у нас всё получится! 😎

Я тут за время сначала рождественских, а потом и совсем коротеньких новогодних выходных, активно использовал ChatGPT в роли junior-разработчика. Основной юзкейс такой — я придумываю serverless архитектуру на базе AWS Lambda и SQS для какой-то штуки, которую мне хочется реализовать, и прошу ChatGPT написать код функции для лямбды. И, надо сказать, результат превзошёл все мои ожидания. Нет, серьёзно, это практически идеальный линейный разработчик. Он не только пишет красивый код с комментариями, но и подробно описывает что он сделал и как, какие ожидаются входные параметры в сообщении в очереди, какие права нужно раздать той роли, от имени которой функция будет выполняться и даже рассказывает как собрать layer с зависимостями или целую сборку.

При этом, конечно, он как и настоящий разработчик что-то иногда продалбывает. Например, когда я его попросил сделать возможность посылать в телегу сообщения как с картинками, так и без (а это две разных API-функции - sendMessage и sendMediaGroup), он в одном случае добавлял сообщение в очередь об успешной отправке, а в другом не добавлял. Но скорость, с которой появляется новый код, когда ты замечаешь такие недостатки, настолько велика, что их легко простить. И вот тут у меня возник вопрос — а как встроить код сгенерённый ChatGPT в продакшн-процессы?

Согласитесь, было бы круто, если бы ChatGPT был просто контактом в телеграме, с которым ты переписываешься как с разработчиком. Пишешь ему задачу, он в ответ присылает код на ревью и объяснение. Окнул код, он его коммитит в GitHub, там прогоняются тесты и, если что-то пошло не так, то он сразу на это смотрит и исправляет косяк. А если ничего не упало, то можно пойти и катнуть новую версию релиза в прод (так уж и быть, уже без помощи ChatGPT. ну, пока, по крайней мере).

Собственно, у меня два вопроса:
1) Вы бы таким пользовались?
2) А может есть что-то такое готовое уже?

UPD. А зачем код в телегу присылать? Пусть вообще сразу делает pull request в github и присылает ссылку на него в телегу с объяснением

Ко мне довольно регулярно приходят люди с вопросами про то, как устроены процессы разработки во “взрослых” командах. Вот и этот год начался именно с такой консультации. Чаще всего за этим вопросом стоит предположение, что мы вот тут маленький стартап, процессы у нас сложились как сложились, а в корпорациях-то есть какое-то тайное знание “как надо”. Не знаю, хорошая это новость или нет, но Деда Мороза не существует нет никаких взрослых команд. Единственное, что есть — это умение/желание/возможность пользоваться здравым смыслом.

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

Как говорится, страшно не то, что мы взрослые. Страшно то, что взрослые это мы. Даже если речь про команды. Думаете, что у вас недостаточно зрелые процессы? Приходите поговорить об этом)

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

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

Хотя, на самом деле, было и что-то довольно свежее для меня. То, во что вроде бы веришь, но признаться об этом вслух (и даже самому себе) как будто бы неприлично. Вот, например, цитата, которая прямо противоречит традиционным призывам не принимать решений о продукте на собственном опыте.

When you build a product or service, you make the call on hundreds of tiny decisions each day. If you're solving someone else's problem, you're constantly stabbing in the dark. When you solve your own problem, the light comes on. You know exactly what the right answer is.

У меня есть такая особенность, что я не могу долго заниматься продуктом, клиентом которого себя не представляю. Возможно, поэтому мне очень тяжело даётся проведение custdev-интервью (а, возможно, поэтому я и не продакт 🙂). И я просто не могу не поддержать такой прекрасный ход мыслей. Правда, я очень четко отдаю себе отчёт в том, что совет делать продукт для себя не работает в вакууме. Если следовать ему, то надо следовать и другим рекомендациям из книги, например отсекать всё лишнее и очень четко обозначать свою нишу. Потому что когда ты меряешь продукт по себе, то и нишу надо определять так же.

В общем, не знаю как насчёт продуктов, которые люди делают на работе (я-то на работе другим занят 😈), а вот для того, что я пилю в свободное время, мне всё, что описано в ReWork очень подходит. Не хочется тратить свободное время на абстрактные идеи, которые пусть и могут принести в теории больше денег, чем продукт для себя, но абсолютно не доставляют радости при работе над ними в моменте. Потому что работа над ними ощущается как ещё одна полноценная работа. А делать что-то для себя с первого момента доставляет удовольствие.

А вы верите в целесообразность делания продуктов “для себя”?

#books #rework

#books #rework

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

Начнём с базы. Размышления и обсуждения надо трансформировать в принятие решений. Не должно быть встреч с повесткой “давайте обсудим” или “подумаем”. Даже если вы собираетесь на брейншторм, вы должны понимать с чем конкретно вы собираетесь оттуда выйти. Есть компании/команды с ужасной менеджерской культурой — “сто встреч и ноль фоллоуапов“ (уверен многие тут знают о чем речь 😈). Чаще всего это происходит потому что никто не хочет брать на себя ответственность за принятие решений. Такие встречи увеличивают фрустрацию вместо того, чтобы мотивировать команду. А должно быть наоборот — встретились, решили, разошлись вдохновленные новым вызовом. Как меня когда-то учил мой наставник по проектному менеджменту — ты должен приходить на встречу с готовым решением в голове, а команда должна уходить со встречи с ощущением, что вы на встрече вместе до него договорились.

Whenever you can, swap "Let's think about it" for "Let's decide on it." Commit to making decisions. Don't wait for the perfect solution. Decide and move forward.
You want to get into the rhythm of making choices. When you get in that flow of making decision after decision, you build momentum and boost morale. Decisions are progress.
Each one you make is a brick in your foundation. You can't build on top of "We'll decide later," but you can build on top of "Done."

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

It doesn't matter how much you plan, you'll still get some stuff wrong anyway. Don't make things worse by overanalyzing and delaying before you even get going.

...a big part of this: You don't have to live with a decision forever. If you make a mistake, you can correct it later.

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

Instead, make choices that are small enough that they're effectively temporary. When you make tiny decisions, you can't make big mistakes. These small decisions mean you can afford to change. There's no big penalty if you mess up.
You just fix it.

Тут, наверное, без примеров не обойтись. Ну, например, пусть речь идёт про какие-то процессы разработки и у вас в команде сейчас только senior-разработчики. Значит сейчас вам не надо придумывать решения, которые будет допускать наличие junior’ов в команде. Потому что если у вас сейчас нет джуна и вы их даже не собеседовали, то в ближайшие N месяцев их и не появится. А команда из одних синиоров и команда с джунами — это две разные команды.

#books #rework #decisionmaking

Хочется немного продолжить тему про принятие решений и поговорить о том, как правильно фиксировать те или иные договоренности. Почему это вообще важно? Потому что часто под одними и теми же словами разные люди понимают абсолютно разные вещи. Я много раз уходил со встречи, где бекендеры и фронтенедеры договорились о том, как они будут взаимодействовать, на словах, а потом выяснилось, что бекенд реализовал одно, а фронтенд поддержал совсем другое.

Я знаю ровно один способ этого избежать — договариваться на том языке, на котором не может быть двух толкований. Конкретно в случае договоренностей между бекендом и фронтендом — на языке API. Когда бекендер говорит, что реализует какие-то методы, у него в голове не сработает и половина триггеров из тех, которые щёлкнут, когда он увидит конкретные поля в конкретных объектах апишки. Когда фронтендер говорит, что согласен на какую-то реализацию со стороны бекенда, он скорее всего не может быстро оценить сколько и каких вызовов ему придётся сделать, чтобы собрать всю страницу целиком. А когда он увидит API он может сразу сказать каких методов ему не хватает, чтобы не плодить лишние запросы.

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

Хотел написать пост о том, как важно следить за уровнем заряда своей батарейки, а потом вспомнил, что уже писал его в прошлой жизни, т.е. 2,5 года назад. И он, кстати, стал моим самым расшаренным постом в фейсбуке за всё время. Забавно, что в прошлый раз писал я его тоже перед очень долгожданным отпуском. Видимо, когда уже достаточно хорошо умеешь наблюдать за своим состоянием и не пытаешься вопреки сопротивлению что-то продолжать делать (не надо, оно ж всё равно не получится скорее всего), то именно в режиме энергосбережения эффекты саботажа организма и выбора быстрого дофамина проявляются лучше всего.

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

Но при этом, несмотря на то, что в компании отлично построена система фидбека, а мой непосредственный руководитель ценит и хвалит ту работу, которую я делаю, дофамина от результата очень не хватает. Как это проявляется прямо сейчас? Очень забавным образом.

Я, как человек, помешанный на том, что всё время надо делать что-то полезное (о, я с этим в себе постоянно борюсь, но успехи переменные), всегда держу в фокусе несколько развивающих активностей. Прямо сейчас их три: почитать книжку, пройти тему в курсе по яхтингу и продвинуться дальше в написании одного проекта силами AI. И из этих трёх активностей чаще всего выигрывает курс по яхтингу, если у меня есть хотя бы час свободного времени. Если времени меньше, то книжка. А до проекта добираюсь только тогда, когда чувствую, что могу засесть часа на 3-4. В остальное время, если пытаюсь сесть за проект (т.е. тему по яхтингу сегодня уже прошёл и книжку почитал), то включается прокрастинация.

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

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

P.S. А, блин, ещё ж одну развивающую активность забыл — посты вот эти вот писать. Или, может, я не считаю её развивающей. Но дофамин она точно приносит, особенно, когда вы посты лайкаете и комментите. А если ещё и перепостите, то вообще ухххх.

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

У пёсана, кстати, есть свой инстаграм и там больше жизни, чем в моём!

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

Примерно по той же причине, когда у меня спрашивают — а какой бы курс по программированию на питоне пройти, чтобы лучше понимать, что вообще вы там делаете в своей разработке, я впадаю в ступор. Потому что курс наверняка может научить с помощью кода решать какие-то прикладные задачи. Но для понимания того, что происходит, нужна скорее база. А база это те самые курсы, которые у нас на ВМК шли первые два года — алгоритмы, архитектура вычислительных машин, операционные системы, системы программирования, объектно-ориентированное программирование и что там было ещё. И послать человека изучать всё вот это как будто бы странно. А, с другой стороны, как ориентироваться в разработке без знания всего этого, я не очень понимаю. И, вообще, всем, кто сейчас хочет войти в айти, мне очень хочется говорить - не надо, остановись. Это только со стороны кажется, что в айти всё классно, просто и богато. А в реальной жизни ты замучаешься конкурировать за свою джуновую позицию не только с такими же как ты, но и с ChatGPT.

А вы что говорите желающим "войти в айти"?

Много лет назад вместе с коллегой придумали формат, в котором мы бы хотели работать со стартапами. Коротко назвали его C*O as a Service. В моём случае, соответственно CTO. С тех пор у меня появилось много самого разного управленческого опыта в разработке, инфраструктуре и т.д. А ещё появилось ещё больше уверенности в том, что именно такой формат отлично подходит стартапам на ранних этапах. Если считать, что CTO руками не работает (а в достаточно больших компаниях от него этого всё-таки не требуется), то для него в небольшой стартап-команде не хватает задач на фуллтайм, но при этом его экспертиза нужна достаточно регулярно.

Да что там далеко ходить — недавно в одном чатике обсуждали на мой взгляд классический пример, где нужен именно такой сервис. Есть две разработки двух разных команд аутсорсеров, с которыми бизнесу не понятно что делать, а надо их как-то объединить и развивать. Что делать? На мой взгляд, если не привлечь специалиста, который сможет вникнуть в то, что сделано, пообщаться с бизнесом, пообщаться с аутсорсерами и предложить план, опираясь на свой опыт и насмотренность, то скорее всего всё закончится третьей разработкой третьей команды и новым витком той же проблемы.

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

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

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

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

Всем бережного отношения к организму и здоровья!

Вчера к нам на Кипр по почте из Великобритании пришли наши новые сертификаты — теперь мы с женой официально Coastal Skipper’ы. Если прошлый уровень (Day Skipper) мы получали в максимально расслабленных условиях в комфортнейшем климате зимнего Ливана, то на этот раз послушались советов бывалых и поехали делать это на родину RYA (расшифровывается как Royal Yachting Association, ну, вы поняли) — в пролив Солент на самом юге Соединенного Королевства. Выбор локации полностью соответствует принципу, по которому учиться нужно в самых тяжелых условиях. Перефразируя классическое выражение — тяжело в Соленте, легко в Средиземноморье.

За пять дней в проливе мы успели застать шторм (и на ходу поменять весь план переходов на день), туман (и от души погудеть круче, чем фанаты на футболе), самый сильный прилив за год (и, воспользовавшись этим, пройти по обмелевающему участку пролива), самый сильный отлив за год (и поседеть от цифры 2,8 на глубиномере). А ещё попробовать ночной яхтинг (вот как подобрать точный аналог английскому слову sailing?) на, возможно, самой хорошо размеченной освещёнными буями и секторными огнями территории. Впрочем, это как раз опыт, которым не факт, что получится где-то ещё воспользоваться. Но, как минимум, это просто захватывающе и красиво (просто посмотрите на эту гифку).

Кстати, в процессе обучения заметил за собой одну важную штуку. Мне очень сложно заставлять себя делать что-то, смысл или механику чего я не понимаю. Одно из упражнений, которое мы тренировали — это швартовка на буе под парусом при наличии течения. И вот два человека передо мной уже это сделали. Кажется, оба не с первой попытки, но больше двух никому из них не понадобились. Наступила моя очередь.

Инструктор, опытнейший британский дедушка, который в шторм при крене лодки в 30-35 градусов, пил свой proper tea с абсолютно невозмутимым выражением лица, говорит мне что делать. А я его слушаю, начинаю это делать, анализирую, не понимаю почему это должно сработать, и впадаю в ступор. В этом ступоре я на каком-то подсознательно-нстинктивном уровне, делаю какие-то движения штурвалом, даю команды тем, кто работает с парусами, но в итоге у меня ничего не получается. Дедушка злится, что я не следую беспрекословно его командам. Я злюсь, что он не понимает вопросы, которые я ему задаю, и просто повторяет то объяснение, которое я не понимаю. В итоге за полчаса и 4 попытки у меня так и не получилось зашвартоваться на этом буе, а все, кто учились вместе со мной, всё это время давились со смеху, но, к счастью (а может и нет), никто из них не заснял это соревнование баранов в своей упёртости.

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

1. Он на самом деле не понял, что ты от него хочешь, и будет делать что-то по-своему. И с большой вероятностью у него ничего не получится (как у меня в этой истории со швартовкой)
2. Он понял, что ты от него хочешь, точно следует инструкции, но обстоятельства поменялись и оно перестало работать. А так как он не понимает сути, то не сможет ни принять самостоятельные решения, чтобы учесть обстоятельства, ни даже прийти заранее с вопросом — что нужно изменить.

Поэтому если ставишь кому-то задачу, надо держать эти риски в голове, когда принимаешь решение — потратить ли дополнительное время на объяснение контекста и проверку того, как хорошо человек понял, что нужно сделать, или и так всё ok.

Всем попутного ветра и приятного волнения! Во всех смыслах)

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

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

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

В январе этого года я заинтересовался темой написания кода силами ChatGPT. Начинал с того, что с его помощью ускорял написание кода небольших бекендов, крутящихся в AWS Lambda. Это задача, которую я регулярно решал вручную, но так как я ненастоящий программист (в смысле, не занимаюсь написанием кода большую часть рабочего времени), то тратил на это довольно много времени. В таком сценарии ChatGPT выступал для меня очень быстрым junior-разработчиком, что сильно ускоряло реализацию, хотя и добавляло этапов с глупыми ошибками по пути.

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

Но недавно попробовал с его помощью сделать совсем новую для себя штуку — написать небольшое Android-приложение. Весь мой опыт работы в Android Studio до этого сводился ровно к одной вещи — подготовке и проведению воркшопа по сбору крэшей при помощи AppMetrica. А приложение, которое хотелось написать, должно было логировать данные с датчиков телефона с максимальной частотой. И, к моему удивлению, на это мне хватило пары вечеров будних дней (часа по два) и нескольких субботних часов. Т.е. спустя примерно 8 часов взаимодействия с ChatGPT я смог закинуть собранную APK-шку на свой телефон, запустить приложение, нажать на кнопку, убрать телефон в карман и спустя 15 минут посмотреть на лог данных датчиков (акселерометра, гироскопа и магнитометра), записанный за время заезда в картинге.

Теперь передо мной стоит следующая задача, с которой я тоже не сказать, что много сталкивался — обработать этот лог и получить из него какую-то минимальную телеметрию заезда. Задача минимум — узнать время круга. И, да, если в Москве мне бы это показалось бессмысленным занятием, поскольку после заезда всегда можно посмотреть на распечатку своего заезда по кругам, то в нашем местном картинге в Пафосе узнать время своего лучшего круга — это уже большая удача.

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

О прогрессе в этом эксперименте буду рассказывать каждую неделю. Не переключайтесь ;)

#chatgpt_driven_development

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

- Я хочу быть тем человеком, который сделал такой проект.
- Я верю в финансовый успех проекта и хочу иметь в нём долю.
- Я верю, что могу быстро сделать такой проект (для кого-то) и получить в несколько раз больше денег за час своей работы, чем обычно.

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

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

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

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

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

Вот то, сколько всего нового придётся по дороге “потрогать”, меня немного смутило. Мой опыт и в разработке мобильных приложений, и в обработке данных ну совсем минимальный. С другой стороны, мне показалось, что это классная задачка для того, чтобы проверить, насколько опытный менеджер (тут и с мобилками, и с данными у меня всё в порядке) может взять себе в помощники ChatGPT и сделать всё в одиночку.

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

#chatgpt_driven_development

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

Я продолжаю собирать MVP проекта, который позволит получать картинговую телеметрию (пока выяснять время круга), используя только Android-телефон в кармане. За первую неделю мы с ChatGPT собрали минимальное приложение, теперь пришло время анализировать данные. Это вторая область, в которой я понимаю, что надо делать, примерно знаю, какие инструменты есть, но ничего толком не делал руками.

Поэтому первая задача, которую я прошу своего AI-ассистента помочь решить, это подбор инструментов. Хочу python notebook, но не хочу заморачиваться с установкой и настройкой всего локально на ноутбуке. После недолгой переписки, остановились на Google Colab.

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

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

Круто, что ChatGPT сам говорит, в каких файлах, классах и функциях внести изменения. Правда, иногда приходится спрашивать, что за exception вылетел или что за unknown reference, но до окончания выходных мы справились со сбором новой версии APK, которая не крешится сразу после запуска. Правда, поотлаживать её я не успел не то что в картинге, а даже просто в быту. Так что следующая неделя явно будет посвящена стабильности данных из приложения.

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

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

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

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

#chatgpt_driven_development

Мой редактор (since 2021) и моя жена (since 2023) сказала, что надо сделать мои посты более читаемыми. Так что теперь моё утро начинается не с кофе, который я варю для редактора, а сам не пью, а с чтения вот этой книжки.

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

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

Из-за ограниченности времени по будням я решил тестировать работоспособность приложения в домашних условиях по-максимуму. Сначала просто ходил по дому с телефоном в кармане и выяснил, что ChatGPT мне кое-что не договорил про Foreground Service. Чтобы сбор данных действительно продолжался в фоновом режиме, надо было не просто создать сервис, а перенести в него всю логику сбора данных. Когда я начал переносить сбор данных в сервис, сломалось обновление списка сохраненных гонок. А ещё за время “домашних тестов” выяснилось, что через несколько минут приложение и сервис могут убиваться, как энергозатратные.

К выходным я пришёл с полностью разломанным приложением и списком проблем, о которых ChatGPT знал, но сам ничего не говорил. Мне даже стало казаться, что я работаю не с джуном из своей команды, а с аутсорсерами, которые все, что не сказано в требованиях, трактуют так, как им удобно. Но за субботу и половину воскресенья мы с ChatGPT объединили усилия и пофиксили все эти проблемы. В процессе тестирования я успел походить по дому, поездить на машине и даже навернуть несколько кругов по району на электросамокате. Приложение не вылетало ни через 10, ни через 15, ни даже через 20 минут. Осталось только доехать до картинга и записать 10 минут данных с датчиков, с которыми я буду работать в Google Colab на следующей неделе.

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

Итог недели оказался смешанным: я узнал много нового про Foreground Service и взаимодействия через Intent в Android-приложениях, но насколько сильно продвинулся к цели — неясно. Впереди осталась одна неделя, за которую надо данные и собрать, и обработать. В успех уже не очень верится, потому что проанализировать данные с датчиков это отдельная большая задача. Но небольшая надежда на один красивый хак по вычислению времени круга, который не поможет в общем случае, но подходит конкретно для картинга в Пафосе, осталась. Если данные соберутся, с ним всё должно получиться очень просто.

#chatgpt_driven_development