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

Инструктор, опытнейший британский дедушка, который в шторм при крене лодки в 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

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

Начну с рассказа про приложение. Если кратко, то по прошествии четырёх недель с начала разработки, приложение продолжало падать в картинге, но несмотря на это мне удалось собрать показания датчиков больше чем с 10 кругов. То есть минимальную задачу, поставленную перед приложением, мы с ChatGPT решили, но довольно странным путём.

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

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

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

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

#chatgpt_driven_development

Кстати, думаю о том, выкладывать ли код приложения на GitHub. Поставьте 👾, если вам интересно на него посмотреть.

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

Уже тогда я стал мечтать о том, чтобы положить телефон в карман, воткнуть гарнитуру в ухо и слушать подсказки от электронного помощника про точки торможения, траектории и другие нюансы пилотажа. Потом был период работы в Microsoft, Hololens и мечты о том, чтобы это был не голосовой помощник, а augmented reality, в которой, как в компьютерной игре, тебе рисуют идеальную траекторию и, возможно, дают собирать какие-нибудь монетки, как в Super Mario Kart.

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

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

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

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

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

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

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

Data Source: Pressure

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

При дальнейшем анализе я понял свою главную ошибку. Я тупо брал данные акселерометра, а надо было сначала их сметчить с компасом и гироскопом, чтобы ускорение по оси Z было действительно вертикальным ускорением, а не ускорением вдоль вертикальной оси телефона. Но быстрых ответов, какие взять библиотеки, чтобы сделать этот sensor fusion в пару вызовов функций, ChatGPT мне не подсказал. Стало понятно, что обработка данных с датчиков телефона — это само по себе интересный проект на месяц.

Буду ли я брать такой проект на следующий месяц? Точно нет. После постов про этот проект ко мне в личку пришли друзья и накидали гоночных приложений, которые решают эту задачу с помощью GPS. И только в этот момент я вспомнил, то, о чем писал в прошлом посте. В Москве я катался в крытом картинге и ни на какой GPS рассчитывать не мог, а значит и те приложения для меня не работали. Сейчас же они отлично отвечают на вопрос — какое у меня время круга. А значит решение, которое я смогу найти, никакой дополнительно ценности не принесёт. Так что мы с ChatGPT пока пойдём порешаем другие задачи!

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

Определенно одна из главных моих точек роста как менеджера — это навык управления ожиданиями. Смотрите сами — с последнего моего поста про картинговую телеметрию прошёл ровно месяц, а в нём я обещал ссылку на гитхаб, где можно будет посмотреть на получившийся проект. За 4 недели до того поста я писал, что решил брать по одному проекту в месяц под реализацию силами ChatGPT. Т.е. по идее ровно сейчас должен был подойти к завершению второй месячный проект, который для меня закодил AI-ассистент.

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

Ну, что ж, пожар погружения в новый продукт и новую команду можно считать локализованным, хотя отдельные очаги возгорания, конечно, сохраняются и всё ещё регулярно дают жару. Но всё-таки сейчас заканчиваются первые за последний месяц выходные, когда в голове ощущается мыслительная активность, а не подгоревшее маршмеллоу на месте мозга. Поэтому я пришёл вам сказать вот что: ещё как минимум месяц я не возьмусь за следующей AI-driven-development проект. Потому что через 10 дней я лечу в долгожданный двухнедельный отпуск в Перу.

Но за время молчания у меня скопилось несколько классных тем, про которые хочется написать и послушать ваши комментарии. Так что следующий пост я рассчитываю написать раньше, чем в середине августа. А пока — можете посмотреть, что там за Андроид-приложение наваял ChatGPT. Исходники тут. Тестовый APK следующим постом.

Он прям правда тестовый. Там логи пишутся, как не в себя и удаляются только руками потом. Андроид-разработчиков прошу строго не судить. Хотя уважительное (чтобы не устроить восстание машин) ревью очень приветствуется!

Когда я стал обставлять свой “кабинет” в доме на Кипре, первым делом я купил себе большой монитор. Мне хотелось, чтобы он обязательно был 4K и заряжал ноут по type-C проводу. Я долго искал оптимальный по цене и качеству вариант, нашёл, привёз, подключил и предпочёл не обращать внимание на то, что нижний край монитора перекрывается верхней частью стоящего под ним ноутбука.

Первое время радость от монитора зашкаливала. Пока я жил в Сербии мне приходилось ездить в офис, чтобы посидеть за широким экраном. А тут вот они 28 дюймов дома. Но спустя какое-то время я стал раздражаться на звонках, когда шарил экран и терял мышку. Потом, когда писал код на одном экране и искал подсказки на StackOverflow на другом. Когда на одном экране писал заметки, а на другом просил ChatGPT их перевести. Когда много других разных когда.

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

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

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

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

Я постоянно говорю о том, что ChatGPT (Claude, Gemma, подставьте любого помощника на свой вкус) — это джун. Но следующая мысль, которая почему-то мне не приходила в голову, звучит так: чтобы стать соло-предпринимателем с IT-продуктом, разработанным LLM’кой, нужно знать какие-то основные технические концепции, на которых строится IT-разработка. А навёл меня на эту мысль мой товарищ, который спросил, что ему делать с кодом, который по мнению ChatGPT реализовывает ту функциональность, которую он хочет получить.

Естественно, я на автомате ответил, что тот же самый ChatGPT сможет ему ответить на вопрос, куда этот код вставить. Но потом я стал размышлять дальше, и понял, что если не задать правильные вопросы, то LLM’ка тебе не даст правильные ответы. Поэтому я уточнил, что путь, которым я пошёл бы (и не раз ходил) при разработке бота для телеги, это разворачивание простых скриптов в AWS Lambda. После этого я хотел написать ещё несколько уточнений про базы данных, заведение токенов бота и прочие детали реализации, но потом предложил Лёше попробовать пройти с ChatGPT настолько далеко, насколько получится. А исходя из результата, я попробую сделать вывод — какие концепции нужно знать тем, кто хочет, написать собственного телеграм-бота при поддержке ChatGPT, чтобы увеличить шанс на то, что они справятся с задачей.

Что у Лёши получилось за 14 часов общения с AI-джуном, читайте у него в канале. Я вот после этого поста очень жду доступ к репозиторию в GitHub, чтобы посмотреть более детально, что там получилось. А к вам у меня вопрос — пришли бы вы на воркшоп про то, как при поддержке ChatGPT собрать бекенд для телеграм-бота и развернуть его в AWS?

P.S. После отпуска в Перу и последовавшей почти сразу же за ним командировки в Караганду столько наблюдений, переживаний и мыслей, что собрать из них что-то понятное и осмысленное для внешнего наблюдателя очень сложно. Если бы Лёша не пришёл ко мне с этим вопросом, так бы и молчал дальше, пытаясь переварить новый опыт.

Может код ChatGPT пока пишет не очень, но вот мемы объясняет отлично прям.

Этот мем состоит из двух твитов, где пользователь по имени "Daniel" рассказывает, что встретил свою жену в обсуждении проблемы на GitHub (платформа для совместной работы над программным кодом). В ответ на это другой пользователь "Mickey Friedman" комментирует, что рад за Даниэля, потому что он нашел девушку, которая "может закоммититься" ("could commit").

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

Так что теперь на любой вопрос теперь правильно отвечать — "что тебя в OpenAI забанили?"

Пока мой товарищ наступает на грабли во время написания кода силами ChatGPT вслепую, я делегирую AI-джуну работу не только разработчика, но и DevOps. LLM’ка все так же пишет за меня код подо всякие разные задачи, решающиеся в облаке AWS, но теперь я пытаюсь от неё добиться ещё и части с разворачиванием этого пайпланйами GitHub Actions и шаблонами AWS Cloud Formation.

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

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

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

Кстати, ещё он регулярно теряет какой-нибудь кусок кода, поэтому я в очередной раз убедился, что хочу, чтобы он мне этот код не в чат присылал, а пулл-реквестами на гитхаб. Тогда я мог бы быстро увидеть diff с предыдущей версией кода и либо окнуть изменения, либо в коммент к этому PR написать ему, что он зачем-то лишний кусок кода удалил.

А вы бы хотели, чтобы вы текстом писали в телеграм, что нужно исправить, а вам в ответ сразу ссылочка на пулл-реквест?

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

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

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

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

Попробовал посмотреть на себя со стороны — а как я решения принимаю? Откладываю, пока не соберу достаточно данных. Стрессую, когда дедлайн пришёл, потому что данных всё ещё мало. Постоянно переживаю постфактум, что можно было собрать больше вводных и сделать лучше. И очень часто совершенно не задаюсь вопросом, чем я рискую, если я не угадаю. Мой внутренний математик постоянно стучится в мой мозг и говорит — у уравнений не бывает плохих решений. Решения либо есть, либо их нет. Если решений много, то выбрать из них нельзя, потому что они все равноценны.

И я продолжаю собирать фактуру, чтобы усложнять постановку задачи. Ведь если решений у системы уравнений много, значит можно добавить в неё ещё несколько условий. Была система из 3 уравнений, а вот она уже из 5, из 10, из 120. А красивого решения, да ещё и единственного, всё нет и нет.

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

А как вы принимаете решения при высоком уровне неопределенности?

После землетрясения, разбудившего нас прошлой ночью, возник вопрос: какие здания устойчивее к сейсмическим нагрузкам - монолитные или микросервисные? 🤔