Latest / // TODO: Переписать — IT без бигтеха и успешного успеха / // TODO: Отвечать за код

Transcript

// TODO: Отвечать за код · // TODO: Переписать — IT без бигтеха и успешного успеха

• Василий: ты вообще-то их изучил перед тем, как делать задачу? Он такой, блин, прости, и я все пропустил, я просто сделал, как чувствовал. Artem: Я со стороны бизнеса смотрю. Бизнес получает то, что надо. Все. Василий: Потому что если убрать человеческую ответственность, ответственность сотрудника из этого уравнения, то зачем разработчики в целом нужны? Мы сами себя заменим по кайфу и пойдем, не знаю, шить Artem: Всем привет, С вами снова подкаст ToDo Переписать и его ведущая Артём Самойлов и Александр Ляпин. Alex: Всем привет! Artem: И сегодня у нас в гостях Василий Сафронов. Он менеджер проекта и он не так давно был software-инженером. Василий, расскажи немножко о себе. Василий: Да, всё так, как ты сказал. Сейчас приходится руководить проектом последнее время, выполняя менеджерскую работу в основном. Скорее это такой принудительный переход. Я себя позиционирую как всё-таки инженера, я этим люблю заниматься. Но как-то условия диктуют необходимость двигаться дальше и развиваться больше в менеджерскую сторону и уже помогать как-то направлять команду в нужное русло. Artem: А с чем, скажем так, какой триггер послужил этому переходу? есть с чего все началось? Ты говоришь про то, что это как бы вынужденная такая мера. Тебя не спрашивали? Василий: Нет, конечно, спросили. Мало того, я сам это решение принял, потому что сейчас у нас компания, где я был первый разработчик, когда начиналась разработка, я все с нуля поднимал. Совместно нанимали там с нашим директором вместе людей, команду. строили компанию и поэтому так как человек всегда был рядом более такой погруженный во все нюансы и в истории компании и в истории принимаемых решений да то есть плюс оказывается что я вроде как хорошо выполняю менеджерскую работу но у меня большой с этим опыт и до отечки был вот поэтому естественно Функциональность эту я взял на себя, как только стало понятно, что разработчиков у достаточно количества и моя помощь там не нужна, я пошел и нашел у себя свое применение там, где это больше всего необходимо для компании, чтобы принести максимальную пользу. Artem: Да, это интересно, и об этом, я думаю, мы еще поговорим, но сегодня мы бы хотели вообще обсудить довольно интересную тему, да, это го и питон. Дело в том, что Вася когда-то писал на питоне, так же, как и мы, но потом что-то случилось, и Вася ушел в го. И, собственно, хотелось бы вот услышать вообще про... твоё знакомство с Python, есть как ты входил в разработку и как ты перешёл на Go и почему. Василий: Слушай, тогда самого начала, стоит начать, я начал разрабатывать, ну, как-то писать какой-то код. Первый еще в году, в 15-м, возможно, 16-м. Я тогда работал инженером-конструктором. Вот, разрабатывал системы всякие электронные. Вот, и был далек от разработки. Но, так как... Приходилось ездить в командировке, производить наладку оборудования вместе с инженерами-наладчиками на различные объекты, реальные объекты, есть реальные люди, где есть какая-то реальная опасность и реальные сроки, которые не подвинут, потому что тебе завтра машинный цемент привезут и все зальют условно. Приходилось решать какие-то проблемы с электроникой, возникающие на месте. В компании был свой отдельный отдел, который занимается разработкой на C, на плюсах, они разрабатывали под микроконтроллером. И в какой-то момент оказалось, у нас в очередной командировке оказался баг в прошивке, его нужно править на месте. Я тогда впервые, наверное, не считая каких-то уроков информатики, впервые так, где я прикоснулся к коду и под руководством старшего программиста, в общем-то, на объекте На ноутбуке поменял код, зашил его в микроконтроллер и после этого до меня дошло, что нифига себе, ну можно так, можно управлять железом вот так, а не только так, как я себе представил до этого, да? То есть каким-то механическим путем. Вот, и всё, и понеслось, я приехал. Я уже в командировке пока этим сидел, я сидел достаточно долго, по-моему недели две. Начал потихоньку изучать Cи на YouTube. Вот, чистый C. Я перед этим провел какой-то ресёрч, какой язык более перспективный, какой язык более базовый, даёт больше всего знаний, и вот прям начал сишки сразу. И это на самом деле первый, да, Artem: Это интересно. Василий: первый язык, вот, Goal C, который я начал с 99, по-моему, стандартом, который, на котором я написал какие-то первые программы, после этого приехал домой, закупился каким-то железом базовым, значит, есть такие отладочные платы. Вот. Artem: М-м. Василий: И начал сидеть там вечерами после работы экспериментировать, там состо N32, F104, по-моему, какая-то плата такая была популярная тогда. В общем, писать напрямую в регистре какие-то программы, там мигать сфитодиодиками, двигать какие-то там двигатели, и всё Вот, и был первый опыт. Но я ещё долго работал инженером-конструктором, потом ведущим-конструктором. У меня уже в какой-то момент начал руководить целыми проектами на этом предприятии. В очень верхнем уровне. Я делал, кто занимается разработкой ПО, он перешел под моё руководство. И разработка новых комплексов, нового железа в целиком. Мне в тот момент понадобилось... в какой-то момент мне понадобилось оформлять большое количество документов, я помню. Очень большое количество документов нужно было оформить для заказчика. Как-то там мне с завода пришла куча таблиц икселевских с какими-то номенклатурами. Я уже не помню, что там конкретно за данные. И я такой, ну я не хочу это делать руками, это займет очень много времени. И я слышал, что есть Python, который может помочь с этим. И который... Если я знаю C, как-то я уже понял, что такое указатель, к тому моменту я уже изучил C, я попробовал Java, я изучил ООП самостоятельно, да, я даже попробовал C sharp и попробовал проходить несколько курсов на платформе открытое образование, раньше такая была, сейчас не знаю, жива или нет. Надеюсь, что... Artem: И все это, будучи при этом не разработчиком, вообще никак. Василий: не разработчиком, не работая в разработке, работая конструктором. И я взялся за Python и начал пытаться распросить вот эти вот большие Excel таблицы, чтобы сжать их до того объема данных термин, нужно найти его. Потратил на это почти месяц, кажется. Ничего Artem: Ох Василий: мне не получилось, я понял, что это... какой-то тупиковый путь, я делаю что-то неправильно, и как раз в тот момент я понял, что мне нужны курсы по этому, чтобы изучить его более профессионально, чтобы использовать его в своей работе, потому что именно для аналитики, для любого менеджера это тоже хороший инструмент, если нужно что-то какие-то недотерминированные данные обработать. И вот я пошел потом уже на курсы через какое-то время, которые мы с тобой вместе закончили в разное Artem: Learn Python. Василий: время, да, да, да, вот на них. После них я тоже использовал Python активно в своей работе. Долго я работал еще конструктором. Я вышел из компании в должности заместистили главного конструктора. Уже на IT-шную работу. Закончил второй курсы. На тот момент в Яндекс.Практикум уже на метла. И мне, ну просто через network, ребята, которые точно на курсы заканчивали, предложили... пойти работать с разработчиками, и самое понравилось, потому что я там, так как уже умею опыт управления, какой-то, понимаешь, чуть-чуть в людях, взялся руководить всеми вот этими учебными проектами, как-то, ну, синхронизировать работы ребят, вот, что кто делает. И людям понравилось, что кто-то готов взять за них ответственность, вот, и провести их по этому пути тоже. И там были куда более профессиональные разработчики, которые... уже долго работают в индустрии, какие-то медицинские программы разрабатывают, еще что-то. вот, собственно, мы с ними хорошо нашли коннект в этом, то есть я свою ценность этом нашел. И меня позвали на работу, на мою первую IT-шную работу в 22-м году. И я решил, что да, кайф, это то, чего я хочу. Как раз в том и время я немножко выигрывал на работе конструктора, потому что... Ну, во-первых, манеджерская работа, она такая, всегда достаточно тяжелая, потому что там нужно много что согласовывать, людьми беседовать, что-то добиваться, вот, постоянно бороться с каким-то сопротивлением, чтобы достичь цели. И в какой-то момент я решил, что я могу позволить себе свичнуться, и я свичнулся. Это было не на повышение зарплаты, на тот момент я получал уже достаточно, ну, много денег на зарплате, да, то есть свои. И... Это был практически равнозначный переход. Я ушел в IT. Моя первая работа была в проекте Пушкинской карты. На нем я Artem: Хм... Василий: пошел медиа-разработчиком. Есть такая программа в России. Artem: то есть из входа сразу на медла залетел. Прям как Яндекс учил. Василий: Да, сходу на медла влетел. И в тот же момент, как только я пришел, оказалось, что это вторая версия API, которая там разрабатывается. Мы, естественно, занимаемся разработкой API для этой программы. Вторая версия API разрабатывается. Первая написана на Go. Ее уже некому поддерживать, потому что старая команда слилась, оставила на себе весь legacy. Его сложно раскурить. Его сложно поддерживать, собственно, есть некоторые проблемы с дальнейшим ходом, и заказчикам это дико не нравится, поэтому начали писать с нуля вторую версию. Но при этом приходилось поддерживать и первую версию, какие-то изменения туда вносить. И вот в тот же момент я буквально начал писать ного с первых буквально месяцев, когда мне сказали, а вот тут есть сервис ного, хочешь? И просто искали, знаешь, кого-то, кто бы согласился на самом деле, потому что никто не знал, у кого не было экспертизы в текущей команде, нужно было вникнуть. И я буквально сразу пошел и начал читать код, как-то вникать, потратил неделю, по-моему, то, чтобы вникнуть. вот, безусловно, сам синтаксис, хотя синтаксис несложный, C-образный язык, собственно, если кто-то знает C, мне кажется, в ГО вообще несложно разобраться. И вот это мое первое знакомство с ГО. Ну, на тот момент язык мне не понравился, я страдал, когда писал на нём, естественно, потому что Python просто в сердечко упал сразу, когда только я начал на писать, а ГО оказался такой какой-то... некрасивый, неказистый язык, что-то странное. Но, однако, писать на нем было достаточно быстро и эффективно. Я бы не сказал, что нем фичи выкатывались медленнее, чем выкатывались в команде, которая знает Python. Вот так и пошел 22 года, как-то перманентно знаком с Go. Artem: Так, слушай, подожди, тебя получается коммерческого опыта именно в питоне, это у тебя по сути и не было? То есть ты сразу так залетел ногой или что? Я как-то пропустил этот момент. Василий: Был? Нет, нет, пришлось писать и на том, другом. Конечно, основной там, не знаю, 80%, Artem: Ага. Василий: 85 % кода это был Питон, просто параллельно всегда был Гоа, всегда Artem: Угу. Василий: приходилось с ним как-то работать, Вот, там много других языков на самом деле было, и потом я познакомился с Лоа, потом я познакомился тоже в промышленном плане, потом познакомился с Груви и понял, что Гоа не такой уж плохой язык, не такой уж там экозист, да. и много еще чего попробовал JavaScript. Но основным стэком всегда осталось Python.go. Artem: У тебя какая-то очень интересная история, честно говоря, Василий: Ахах Artem: в кодов IT. Это просто какой-то Unreal. Наверное, это времена, у разработчиков все было достаточно хорошо. Сейчас как будто бы немножко по-другому. Работу найти довольно сложно, когда у тебя нет коммерческого опыта. А тут тебя по факту получилось, что ты просто закончил курсы, ты никак не относился к IT. Ну да, у тебя как был опыт, понятно, с языками, вот именно коммерческого на тот момент у тебя не было, да, ведь опыта? То есть ты вот просто ну Василий: Нет, не было, нет. Artem: совсем вообще в другой сфере работал и Василий: Да. Artem: ты без проблем смог найти работу, сразу пошел на медла, сразу стал писать на двух языках, по сути, там на Гошке и на Питоне, еще при этом во, и на Луо. Василий: На трёх там ещё Лова была, да, рядом всегда. Потому что база данных была Тарантова, а ней нужно было скрипты на Лову писать. Artem: Просто жесть. И при этом твой опыт на руководящей должности, он сыграл свою роль в том, что ребята тебя взяли к себе. Василий: Да, навыки менеджмента, навыки осознания процессов вокруг тебя — это всегда важные навыки. И сейчас, когда мы нанимаем людей, я тоже на это сильно обращаю внимание, на сколько человек может сам себя манжирить, насколько он может осознать процессы, которых не только он вращается, а вся компания, весь контекст, охватывающий фичу, который проходит от discovery до выхода в реализу своему. Artem: Да, ну история конечно действительно очень крутая, очень крутая и сейчас бы побольше таких историй, но мне кажется, что рыночек прям уж совсем какой-то другой стал. И это вряд ли, наверное, возможно уже. Василий: Да, я думаю, что сейчас это было бы проблемой. Мало того, я думал, анализировал для себя, что будет, если сейчас у меня не станет работать в IT, пойду ли я искать другую работу. Скорее всего, я бы не вышел на рынок и я бы не пошел в IT. Мне не нравится эта разработка, вот сейчас, в текущей продигме идет, когда все пишется и для меня было кайфом писать код руками. Я думаю, что это именно инженерное наслаждение, что-то делать своими руками, осознавать это итеративно, То, что ты создал задачу, и это тебя. Это делает нас максимально далекими от Бога. Artem: 100 % да. Я уже тоже говорил про это, что как разработчик я был гораздо счастливее до появления Ишки. И в общем-то я стою на этом, вот именно как разработчик я 100 % был... Мне очень нравилось писать код руками, самостоятельно читать документацию, как-то изучать, какие-то копаться в клубе и так далее, делать какие-то прикольные решения. Сейчас это все вот просто исчезло. Ну, уже разработка, она абсолютно другая и она, скорее всего, никогда не вернется к той, что было раньше. И это вот то, наверное, что надо принять. То есть ты либо как бы остаешься разработчиком, ну, или не знаю, как сейчас назвать разработчика. Вот. Но об этом мы тоже поговорим. Да-да-да. Василий: продукт инженер, продукт инженер сейчас есть в популярной соводе Artem: Ну, кстати, это, наверное, близко к правде. Вот product engineer, это реально близко к правде. Потому что... У меня в компании, в стартапе, в котором я работаю, я больше внимания уделяю именно продукту, нежели коду. И вот все, что касается различных метрик, как ты знаешь продукт, как ты можешь влиять на него, как ты можешь его улучшать и так далее, это ценится руководством гораздо выше, чем все, угодно ты делаешь с кодом. Всем, в общем-то, без разницы, менеджменту, как правило. Поэтому да, продукт инженера, это вот... Я первый раз слышу про эту концепцию и мне кажется, это очень даже интересно. Василий: А давай поразгоняем? Мне кажется, что это всегда было важно. Во-первых, Artem: 100 % 100 % да Василий: кажется, этом плане ничего не изменилось. Просто немножко фокус сменился, теперь можно не смотреть там... Ну, условно, можно не смотреть, потому что я самом деле с этим не согласен в код. И просто можно сместить свой фокус внимания на какие-то более продуктовые вещи. И приносить ценность более на высоком уровне. И, кстати, давай поразгоняем Artem: Да. Василий: насчет того, а вот ты сказал, изменилось, никто не пишет код руками, вот изменилась аппарадигма, а так ли это? Мне кажется, у нас просто некоторые информационные пузыри именно для веб-разработки, людей, которые близки к ним, мобильной разработки, куда именно наступает ИИ. И мы вот тут мечемся с этим ИИ и переживаем. А есть большой пласт разработки, который вообще не переживает, а вообще уверенно стоит на ногах и занимается своей работой. Потому что есть же люди, которые делают митинский программ, митинское оборудование. Есть люди, которые пишут софт для самолетов каких-нибудь, да, там навигационных. Есть люди, которые пишут софт для телевизоров, для микроконтроллеров. люди, которые пишут софт для EBLO. блоков питания автомобилей и еще каких-то таких вещей, которые очень важны и где-то не можешь отдать наутку по ИИ, тебе нужно все равно смотреть код. И как будто бы таких людей гораздо больше, такой сфер гораздо больше, просто они не так заметны, потому что у них в целом все стабильно, у них не сильно что-то меняется. И это мы тут носимся, типа нас заменят, там у нас какие-то... То мы носились в фреймворки новые выходили, то мы начали носить ЦИИ вышвы, типа каждый новый модель. Теперь мы просто в панике носимся, кажется, нам просто нравится паниковать, Artem: Слушай, мне нравится твой take. В целом, я, наверное, разделяю то, что мы можем находиться в каком-то пузыре. И вот все, что нас окружает, веб-разработка и все, что этим связано, действительно оно так или иначе находится с ICH-ками. И мы не знаем, происходит в других сферах. Именно поэтому я очень хочу найти человека, как раз из той сферы, например, с микроконтроллами работает. Вот и просто провести подкаст с ним для того, чтобы поговорить вообще и узнать, что у них там происходит в этом домене. Если, кстати, такой человек нас смотрит, пожалуйста, напишите обязательно в личку. Будет очень интересно провести подкаст с вами, вот, обсудить это дело. Но в целом, мне кажется, что ИИ так или иначе во все сферы проник. Вот меня почему-то такое ощущение складывается, что в любом случае, то есть ИИ будет проникать во все сферы. И даже если сейчас веб-разработка вышла далеко вперед, плане того, насколько ИИ внедрём в неё, то и другие сферы так или иначе будут захвачены яичкой. Вот мне так кажется. Алекс, что думаешь? Василий: А во все ли? Я думаю, во все. Я думаю, опять же, это сугубо наш пузырь. И мы такие думаем, что у нас тут все захватывает, значит, мы здесь все захватывает. Не знаю, я прихожу в магазин, продавщицы на классе как сидели, так и сидят. Это большой пласт людей. Artem: Ха-ха-ха! Василий: Люди на улицах как убираются, там так и убираются. Не знаю, вот у меня фонтан, тут в дворе закрывали, пришли люди, приехали, начали там пылить что-то, фанеру. Ну, то есть очень большой пласт людей, которые делают работу свою, да, которые... Мы обычно не обращаем внимания, хотя делается вокруг очень много работы, очень много труда. Это никуда не делось, плюс люди, которые просто сидят в поликлиниках, где есть строгие законы по управлению медицинским персональным данным, ты туда не поставишь еду. Есть люди, которые сидят и делают свою работу. В общем, много где, в каких-то госорганизациях любой страны мира, где тоже ИИ особо... возможно, неприменим, по крайней мере, если ты не в США сидишь, и у тебя нет доступа напрямую к передовым моделям, которые находятся на твоей же территории. И... В общем... Да, да, да... Artem: Ну это ты в общем говоришь, это ты просто в общем говоришь. Я думал, что этот вопрос больше относится к разработке. Но если в общем, то понятно, что куча сфер, где ИИ не заменят, естественно, человека, это кстати очень хорошо, типа какие-нибудь электрики, сантехники, у этих ребят работы будет очень много и она будет очень хорошо оплачиваемая. Побольше, чем у нас, скорее всего, даже в будущем. Потому что... Да, да. Василий: Да, уже сейчас. Я сделал ремонт буквально в квартире недавно на кухне. Я тебе скажу, электрика стоит очень дорого. Я точно отдал больше, чем я получаю сам за месяц. Artem: Ну вот, собственно, идти, явно не войти. Надо Василий: Да. Artem: идти туда, где ты можешь что-то делать руками и где тебя пока точно не заменят. Таких сфер точно достаточно много еще, и они будут оставаться. Наверное, кто может заменить электрику? Только какой-нибудь гуманоидный робот с супер ИИ, но когда они появятся, когда появятся такие роботы, которые смогут выполнять такую работу. Наверное, не скоро ещё. Василий: Я сомневаюсь, что вообще появится, Знаешь почему? Потому что все-таки модели своей текущей архитектуры, такое-то переножение матриц, вероятностные исчисления того, что нужно сделать. И пока там есть хоть доля вероятностей, а не четкий факт знания, что нужно делать вот это, чтобы тебе не загорело полквартиры, то никто не доверит... роботу делать электрику, потому что меня квартиры там предыдущие два раза горели от были возгорания электрики, я бы не доверил даже если там было 99 процентов уверенности какому-то роботу сделать это. Во-первых, во-вторых, а кто потом будет нести ответственность юридически? Artem: Ну, компания, которая этого робота сделала, или компания, которая, не знаю, надела условно этого робота к себе в Василий: Ну, Artem: штат. Василий: да, тогда это убивает всю бизнес-модель компании, если есть такая вероятность, они будут закладывать себе эти риски и увеличивать стоимость работ на эти риски, да, то, что они же после чего-то выплачивают эти компенсации, им нужно их заработать. Возможно, это станет настолько дорого, действительно, такая работа, что это будет нерентабельно, придёт человек сделать руками. Получше. Artem: Да, да, вот это возможно, То есть вывод такой, надо не идти в IT, Василий: Ха-ха! Artem: надо что-то делать руками. Василий: Да, но в любом случае, если вы в IT, кто нас слушает, если вы не умеете что-то там, не у вас нет култу-хобби или занятий, которые вы уверены, что вы хорошо его делаете руками, я рекомендую. Во-первых, это психологически хорошо разгружает, просто что-то делать руками, это всегда приятно, созидательный процесс. Во-вторых, это всегда полезно. В-третьих, вы всегда будете уверены, что вас завтрашний день не станет для вас концом, если вас вдруг заменят. Artem: Олег, всё думаешь насчёт вот этого всего? Alex: Ну в целом нет данных, к сожалению, именно по программистскому такому домену. Такие еще остались там профессии, которых АИ не заэффектил и которые могут писать код руками и так далее. вот да, по поводу остальных вообще тоже отраслей, индустрии, скажем так, всякие ресерчи вроде выходили, антропика того же самого. там области, ну типа теоретические возможности, и те, которые сейчас уже происходят, типа какие там отрасли аффектятся и насколько сильно. Ну вот как компьютер, да, и математика довольно сильно аффектится. Не знаю, тоже было бы интересно поговорить, ну подкаст, да, провести с представителем. Artem: другого домена. Alex: ну не то чтобы другого домена хотя бы даже в домене там разработки той же самой большой ну с другого короче тот там всякие электронику делать далее вот тоже интересно как-то насколько сильно там за эффектилась за эффектил я и вот эти короче слои вот ну а так в целом что в целом согласен что что ручной труд еще возможно не так скоро заменят если вообще заменят вот и короче да в целом согласен Artem: Ну окей, в общем, будем смотреть, что будет у нас происходить. Насчет замены, я думаю, да, ручной труд это пока то, что действительно будет выигрывать и наверное приобретать всего большую ценность. Например, я точно знаю, что в развитых странах, типа там Австралии, США, электриком ты будешь зарабатывать просто огромные деньги. с антехником ты можешь зарабатывать огромные деньги и скорее всего это даже не сопоставимо с тем, что ты можешь зарабатывать в IT. Понятно, что зависит там от многих факторов и в IT можно зарабатывать хорошие деньги. Странно, что мы вообще тут типа обсуждаем зарплаты IT-щиков, они какие-то не такие, вот, хотя на самом деле в IT всегда были хорошие зарплаты в общем-то, не для кого не секрет. Alex: руками кстати реально приятно работать прямо реально отвлекает и какой-то такой позитивно оставляет отпечаток что-то руками сделал потому что там кнопки понажимал это одно не особо почувствовал скажем так через ну короче через сенсорик там через моторик вот так если руками что-то сделал реально приятно Artem: Тут вопрос еще, знаешь, просто так когда-то делать руками что-то, типа не знаю, в течение часа поковырять любимый мотоцикл, ну, наверное, прикольно, особенно когда у тебя есть инструменты, там все хорошо. А если заниматься этим постоянно на протяжении всего дня, условно работать с тем же мотоциклом, но просто с грязью, непонятно с чем, с какими-то решениями и так далее. есть, ну, как работа, это может уже по-другому выглядеть. Alex: Ну может приезд сюда может Да вообще любую любая работа требует каких-то усилий тут надо пробовать смотреть не знаю Ну в таких развитых странах да там там реально всяких и димены там короче ручной труд ценится и это хорошо это правильно мне кажется Artem: Согласен. Мы немножко отошли от темы как будто бы. Мы хотели вроде ГО обсудить, но по факту ушли в какой-то... Alex: Да. Artem: и обсуждение текущих реалий ИИшки. Да-да-да-да, Alex: куда уходить из IT-шки. Artem: куда уходить зайти. Вась, расскажи, вот в целом твоя... твоя вот первая встреча с ГО глазами человека, который... работал с питоном. Вот что, не знаю, тебе понравилось, что не понравилось, то есть что вот зацепило тебя сразу, обратило внимание на себя. Василий: Странно будет звучать, это обработка ошибок Понравилось, Artem: Ну конечно, ещё бы. Василий: именно понравилось Знаешь почему? Потому что Artem: Угу. Василий: ты должен каждую обработать и значит ты должен понимать на каком этапе выполнения паркаромки каждая ошибка может возникнуть И то никак, Artem: Да. Василий: ты и там кинул общий exception, там потом его где-то поймал, не важно Мне не нужно понимать, сейчас точечный обработок, в ГО так не пойдет У тебя появляются какие-то привычки делать более стабильным, более предсказуемым думать о том, как он работает здесь сейчас, на этот момент. Artem: Да, я когда пытался изучать Go, это было, наверное, года три назад, мне тоже понравилось это, то есть на удивление. Я слышал постоянно в интернете холивары о том, что вся эта история с обработкой ошибок в Go, она надоедает. И можно было бы что-то более интересное придумать. Но лично мне понравилось. То есть опять же вот по сравнению с питоном где-то реально просто там ну как правило пишешь exception и все у тебя там ну как бы дальше непонятно что происходит. Здесь ты обрабатываешь постоянно и не знаю мне понравилась эта идея. А что не понравилось? Василий: Не понравилось отсутствие некоторого сахара, который есть питоне. Ну как сказать, не понравилось, знаешь, я иногда думаю и скучаю, а вот бы хорошо были декораторы, допустим. Потому что в паттинге это удобная штука действительно. Некоторые синтоксические сахары, позволяют делать код более минималистичным. В ГОО. Приходится все-таки там, прямо, прокидывать функции функций, там все вот такое-то все нужно, Какой-нибудь хендлер обработать нужно, там, кинуть другую функцию, которая регистрирует этот хендлер. Вот. Но с другой стороны, я понимаю, если бы сейчас это ввели, допустим, то код начало превращаться бы в что-то... что-то ужасное, скорее всего. Это бы добавило больше веративности, и мы бы, пришли в какое-то... Точке, пришлось бы опять же сидеть долго разбираться в коде. Знаешь что? Просто в Python есть нюанс, что там много действительно способов, богатый язык, и нем много способов написать что-то одно. И в любой момент времени, когда мне приходилось читать чей-то код разработчиков, review, я всегда страдал, знаешь, от чего? Люди не соблюдают какие-то договоренности по старой галю, да, еще что-то. Как-то пишут код, и мне всегда нужно тратить время на то, осознать, а что разработчиков мяут видом, вместо того, чтобы потратить время на проверить бизнес логику к коду, то, выполняется безопасно, небезопасно. И просто тратишь время на это осознание какое-то, когда в ГОЛД этого нету. С одной стороны, как-то немножко скучаю, с другой стороны, это очень сильно вскореет разработку. когда тебе не нужно об этом думать. Artem: То есть по факту ревьюить код на Go гораздо легче, чем на Python. Василий: Вообще, наизия. Он буквально на этом проекте, на текущем, и выбрали ГО, как основной язык, именно потому что очень легко ревьюить код, очень легко читать. Если это, конечно, не код написанный, давай дисквеймер, если ты человек написал, и он знал, что он писал, и он неплохой разработчик, ни до уровня, ты точно с легкостью прочитаешь этот PR и осознаешь то, что он его ведал, и... либо кустишь его, либо накидаешь ошибку, в общем, не возникнет необходимости думать, блин, а что тут такое происходит вообще, да? Artem: интересно ну это прикольно да не знаю вот если посмотреть на то что ну как правило да когда ты начинаешь изучать какой-то язык то ты все равно пытаешься писать так как вот ты писал над своем первом языке там словно или на языке с которым у тебя больше опыта то есть например если есть час спитона перейду там в го и буду пытаться писать на го то наверное я буду писать как ну питанист вот на го они как там гофер на го вот у тебя было такое Василий: Да, было. В Go есть стандартная структура проекта, которая есть в интернете, если зайти, попробуй поискать. Который принят в принципе придерживаться, это не жесткое требование, но обычно все пытаются его придерживаться. Я какое-то время пытался писать как на Python, с Rc, core, какой-нибудь config, изобретать какую-то свою архитектуру. Потом приходилось с интерфейсами немножко по... осознать, почему они помещаются в том или ином месте, и как они вообще работают, немножко непривычное. Но в целом, знаешь, с учетом того, что меня был опыт, который я рассказывал, перед этим с C, Java, с Sharp-ом немножко, у меня не возникло каких-то концептуальных сложностей переключиться, потому что все-таки, если ты понимаешь какие-то концепции с более богатых синтоксических языках, здесь уже не возникают проблемы это что-то осознать. Вообще, на самом деле, гугногоз легко писать. Я всем рекомендую просто, естественно, начать писать, если вы знаете любой другой язык уже, да, мне кажется, не должно возникнуть проблем. Посмотрели сигнатуры, функции, посмотрели основные концепции, посмотрели, как обработка ошибок идет и в путь. Вот. Artem: Да, во времена Ишки опять же это будет наверное такой, знаешь, кайф, когда ты можешь реально сидеть и писать ручками, снова вернуться в это всё. И времяпривождение довольно приятное, как мне кажется. Василий: Да, да, сейчас я услышу термин «ретрокодинг», как называется. Сейчас начнем, да. Да. Artem: дожили ретро кодинг ай жесть ну да интересно было бы попробовать у меня знаешь был такой небольшой опыт с растом мне в какой-то момент стало очень интересно попробовать поизучать его потому что ну из всех просто утюгов там рассказывали про раст это было еще до появления агентов и я изучал прям самостоятельно мне прям очень понравилось То есть вот прям сама идея языка с этим BaroChecker, то совсем вот прям было очень интересно и язык мне показался очень прикольным. Но дальше у меня стало очень мало времени и я, к сожалению, не смог просто продолжить с этим, да и как бы проектов не было, которые на расте были бы написаны, чтобы вот разрабатывать полноценно. А потом появились агенты и сейчас ты по сути можешь, ну не знаю, языка написать там просто любое приложение, которое тебе надо. Например, для своего сервиса, который я делаю, как такой pet-проект, один из микросервисов написан на Rust'е, и я не знаю абсолютно ничего про этот микросервис. То есть он просто есть, он просто работает. Он выполняет какую-то свою микрофункцию, и все. В принципе, мне от этого больше ничего не надо. То есть мне даже не надо понимать, что там происходит, потому что он выполняет только одну функцию. и выполняет ее он достаточно хорошо. Как там написан код, насколько хорошо, меня в принципе не сильно волнует, потому что в совокупности это дает как бы эффект, который мне нужен, как такому вот, ну с точки зрения бизнеса. И вот сейчас возникает вообще вопрос, если вообще смысл изучать языки разные, если сейчас там ИИшка, агент может написать там просто на любом языке. и ты как бы следишь уже за этим с точки зрения, наверное, получения какого-то там бизнес-функционала больше или все-таки нужно? Давай вот порассуждаем на эту тему. Василий: Да, окей. Ну слушай, гляди, у меня тоже был совсем небольшой опыт, точнее как опыт, опыт попытки изучения раста. Я там купил книжку даже, по-моему, «Раз в десять» называется ещё там такой мужчина с перчатками боксёрскими на ручке. Я прочитал, наверное, страницы 100 или 150, в общем-то, и после этого я закинул. Да, прикольный язык с точки зрения бурлчекера, да, и тех... Как-то гарантика, которая предоставляет компилятор и концепции имутабельности по умолчанию, да, собственно, много, достаточно много, в общем-то, безопасности из коробки предоставляют при каком-то отсутствии runtime или минимальном runtime. Вот, но да, действительно, пока непонятно, в общем, нем очень мало проектов и непонятно, где его применять, кроме каких-то вот, там, не знаю... Криптопроектов, которые я не очень люблю. Где Artem: Ха-ха! Василий: важны действительно какие-то задержки в обработке, чтобы сборщик мусора не тормозил систему, когда он решил поудалять неиспользуемые объекты в памяти. То, что голо бывает, надо за это критиковать. Хотя это принципе нормальное поведение любого языка сборщика мусора. В общем-то есть какие-то проекты. Где задержки? Alex: шлюзы там всякие вроде пишут ну всякие типа gateway шлюзы Василий: Да-да-да, вот сетевые шлюты, там CloudFair активно используют, вот Crypto Startup, возможно, какая-то биржевая торговля, где какие-то боты, которые нужно что-то там активно собирать, какую-то информацию быстро иметь, реагировать нее, то есть где важны минимальные задержки, но в целом как будто бы таких проектов не очень много, и большинство из них уже либо существует и пишется на плюсах, а на плюсах все-таки ну как-то людей больше, во-первых, во-вторых, Экспертизы в мире в целом больше у людей на плюсах, у разработчиков на плюсах. Поэтому легче найти разработчика профессионального, легче начать с ним нанять и ввести его в команду, в проект и начать приносить какую-то пользу. Поэтому я понимаю, куда иметь трассу, он там вимбеддат, по-моему, пытается немножко, но я пока не понимаю, как он это может сделать, кроме того, что это фаннел-язык, который всем нравится. чтобы Вадипра был пока как будто бы он особо не может занять свое место, такой статистически значимую позицию вот именно в найтишном рынке плюс он еще похож на G, я когда его посмотрел, на самом деле да, типа в топ такой, я посмотрел, такой блин, ну это же Jello script, там вот с этими лет, такой ну Artem: Ну меня не было такой ассоциации. Нет, Василий: Не было. Я просто перед этим подписал на реакции на чистом JavaScript, без TypeScript, один проект, без заказчика. И я после уже пробовал раз таки, ну это почему-то похоже на JavaScript. Понятное дело, что это просто первая ассоциация, первое ощущение, когда ты человека встречаешь, что ты подумал, а потом это может быть ошибочно, конечно. Но в целом, да. Artem: У меня была первая ассоциация, что ничего себе как логично. Типа настолько Василий: Да. Artem: прям логично всё сделано. Типа вот если ты так подумаешь, блин, ну это ж прям имеет смысл. Да. Да. Василий: Ну, обработка ошибок одна из лучших, самом деле. Давай будем честными. Вряд ли тут можно что-то как-то перехвалить раз. Но надеюсь, что, конечно, он тоже займет какое-то место на рынке значимое, потому что чем больше языков, тем лучше, конкуренция всегда полезна. А насчет того, что нужно ли читать код и нужно ли... Да, учить, учить. Да, конечно, нужно, конечно, нужно. Есть, опять же, очень много нижек, где важно читать и отнести ответственность за каждую строчку кода. А если мы здесь обсуждаем, нужно ли читать у себя код или нет, это просто значит, что у нас есть запас прочности, потому что исправить эти ошибки до того, как они станут критичными для пользователей и принесут достаточно вред. Допустим, я бы не хотел... вися на каком-то объекте, устанавливаю оборудование на высоте 20 метров, подвешиваю на поясе, и настраиваю железо в нереальном объекте, узнать, что какой-то модуль электронный не так работает, как нужно, потому что программист не читал свой код. Ну, я бы, наверное, вышел с ним подраться после этого, когда вернулся. Есть куча железа какого-то, которая уходит с заводов людям. И они никогда... У них нет доступа устранить ошибки, то есть нету варианта устранить за собой какие-то баги. Они точно должны Artem: Угу. Василий: читать свой код и быть уверены в том, что он работает. Есть куча оборудования, которое действительно просто уходит, и нет возможности с ним дальше взаимодействовать, даже как-то снять информацию о том, а как вообще он нормально, ненормально используется. Так что читать код нужно... в зависимости от того, насколько критичен тебя твой продукт. Вот такой пример из жизни буквально. Я бы очень хотел, разработчики одной программы читали свой код. Ну, точнее, в ASCII читают, просто там был баг. В общем, я пришел с мамой в клинику к врачу, ей нужно было посмотреть мерто снимки ее. И программа, которая у врача была, просто не смогла посмотреть МРТ-снимки, она не смогла их открыть. Идя домой, установив новую версию программы, свежего, я их спокойно открыл на своем ноутбуке. И мне потом пришлось через неделю ехать к этому же врачу со своим ноутбуком, чтобы показать снимки МРТ. А вообще-то это время, которое тратится, которое человек не получает в лечении. И так во многих местах. Много программ в медицинской сфере используются, которые также влияют на процессы. много в других ответственных сферах. Поэтому нужно ли читать наш тобой код? Может быть нет, но всё равно это не воздобавляет нас от ответственности. Нужно ли читать какой-то другой код? Я бы рекомендовал на самом деле всем читать свой код. Artem: Да, тут конечно можно, знаешь, порассуждать на тему, ну вот то, что мы уже затрагивали с Алексом, но у нас тут, видишь, такая ситуация, что мы все три питаниста и три разработчика, и можно как будто бы вот эту тему еще больше, не знаю, обговорить, потому что я считаю, что, ну как бы человек делает ошибки, то есть разработчики, они делают кучу ошибок, и ты, допустим, как человек, который ревьюет PR, ты можешь посмотреть, сказать, что все окей, а на самом деле ты пропустил чудо. есть ты как человек, который, ну, этот PR должен был опровнуть, и как человек, который является там опытным разработчиком, ты посмотрел, опровнул его, и, ну, не нашел критический баг, а он там был. И какая разница, если бы это просто было сделано там нейронка, например, и ну... и ничего бы не произошло, есть ну не посмотрел бы ты код. Вот, никакой же разницы нету. Василий: Есть, Человек может сделать выводы из своей ошибки и не повторять ее. Агента ты не можешь переобучить. то есть ты можешь, конечно, задать правила, дописать скилл какой-то, в память ему положить что-то. В в зависимости от того, как у устроена агентская инфраструктура. Но большинстве случаев ты не можешь на это повлиять, в то время как... Допустим, если джун делает ошибку, ты можешь подойти к нему, условно, дать подзатынь, ну, моральный, да, естественно, не физический, ни в коем случае, мы же не бьем людей. Вот. И, собственно, постараться это сделать так, это больше не повторялось. Агенты ошибаются гораздо чаще. У меня на работе все, ну, весь цикл разработки, весь цикл вообще, ну, все процессы. обложены агентами, и люди активны. То есть я не хочу показаться лудитым, у нас действительно мы активно используем. Я сам очень часто пишу код агентами, вот, постоянно фактически. Я уже не помню, как я писал код руками, но при этом стараемся смотреть его, и у нас никогда нет такого, чтобы человек был исключен из этого цикла. Плюс ответственность человека, она всегда лежит на том коде, который он сделал. Не важно, как... код был произведен, готов ли ты взять за него ответственность. И вот чем ценность программиста сейчас в том, что он пишет код, либо в том, что он понимает, что он сделал, не важно как, вышло из-под его руки через промк, либо через ручное написание. И в том, что он может гарантировать какое-то качество и исключить вероятность возникновения одинаковых ошибок. Банальный пример. Банальный пример. У нас был GPT 5.6, и он достаточно неплохо работал. Вышел GPT 6 Astra, потом GPT 6.1 Sol. Я сейчас активно его использую. Но сейчас большая проблема, что он часто выходит за границы дозволенного. Буквально вот меня лежит в рабочей директории два проекта Frontend и Backend часть. отдельные репозитории, и в кодексе заведены отдельные проекты на frontend и на backend. То есть границы жестко определены, которыми может работать там агента. В каждом репозитории есть свои скиллы, правила, это вот все настроенное, то есть на каждый отдельный этап четко регламентировано. При этом решая задачу, которую я скинул на backend, агенту мы с ним разобрали построили план я честно вычитывал план он честно пошел его решать вот согласно всем договоренностям при этом на выходе он мне выдает два пиара ссылки на два пиара я иду смотрю и так на вакенд и на фронтенд я говорю откуда у нас взялся фронтенд проект ограничен репозиториям вакенда Задача, в джире стояла, с типом, типа, задачи на бэкэнд специально, да, то есть у тебя все процессы построены для бэкэнда. Откуда взялся фронтенд? Он говорит, ну вот там надо было контракт поменять, взаимодействие с этим фронтендом менялось, поэтому я решил, что я и фронтенд пойду поменяю, потому что я в целом знаю, где он тебя лежит, вот это не секрет типа для меня. Почему-то для него это не секрет, Ну ладно. Вот. И я пошел и сделал на frontend, такое, ну ты, конечно, молодец, а границы проекта чем определены? У же конкретно границы проекта к репрессии бэкэнда, задача с типом, задача бэкэнда, Ну вот. Он такой, ну да, прости, прости, я там что-то мешка себе позволил, вышел за границы, такого больше не повторится. Я после этого пошел, доработал правила, что, типа, если нужно выйти за границы, я то есть не запретил жестко, но что ты должен всегда сообщать явно, если тебе это нужно, да, пользователя, чтобы... было принято соответствующее решение, чтобы пользователь мог отвечать за это решение. При этом я пошел, налил себе чаек, пока ходил, думал, и думал, блин, а в репезитете FrontEnd есть же свои скеллы, там, описание архитектуры, свои правила, вот это вот сюда, а использовал ли он их, когда он пошел из репезитета BackEnd, или он просто сделал там какую-то лапшу из кода? Я пошел, естественно, в том же чате спросил, а там вот как-то... Знаешь, там есть вообще-то свои артефакты агентские, ты вообще-то их изучил перед тем, как делать задачу? Он такой, блин, прости, и я все пропустил, я просто сделал, как чувствовал. Ну что, ну что вот? Я, естественно, потом пошел и провел ревью всего PR Frontend и привел к какому-то... каким-то адекватным критериям качества, но это было недопустимое поведение, на тот момент у меня дико горело, я хотел уже удалить все, потому что на самом деле, если он себе это позволяет, он себе много чего может позволить. Выйти за рамки проекта и что-то наделать в системе. И это не один пример. нас, допустим, на фронтенде в репетитории четко закреплены правила работать с стилями по OPM. Это такая методология работы с складывающими стилями. Раскладывать их рядом с компонентами, модуле, да, и всё такое. Но я не фронтендер, естественно, как-то об этом абстрактно говорю. Я писал код Nerect и руками, и не руками, но... И даже был лидом команды фронтендов когда-то. Но, в общем-то, я не считаю себя профессиональным фронтендером. Но, однако... Однако... Дафу ему задачу... Отдельная вообще уже другая задача, через какое-то время, да. Пошел ревьюить то, что он сделал, в итоге он просто все стили, онлайн написал в индекс HTML вот этот вот текст-стайл, что вообще не противоречит всем договоренностям, то есть в репозитории явно закреплены правила, и он их явно игнорирует. То есть это всегда какая-то... Когда ты отдаешь что-то агенту работу, это всегда какой-то процент вероятности, что оно сделано с каким-то качеством. И чем у тебя больше цепочек в этом взаимодействии? Есть правила подсчета размерных цепей и зазоры, кажется, называется в конструкторском деле, когда нужно соединить несколько деталей, и каждый деталь, допустим, какая-то погрешность размерных, плюс или минус. И чем больше эта погрешность в каждой детали, допустим, тебя в целом допустимо, но ты их должен десяток соединить в одно общее изделие. И в итоге у тебя получается, что в одном общем изделие погрешность накапливается такая, вот этих вот суммы погрешности, которые там на каждой детали, что она становится недопустимой. Поэтому на сборочных чертежах там всегда тоже прописывается это. И вот это можно исправить с процессом агентской разработки, когда тебя там каждый агент или каждый отдельный скилл имеет какой-то зазор по качеству, который ты непредсказуемо, ну то есть не непредсказуемо, ты не подумал об этом, ты не описал, либо ты не знал, что он будет решать таким способом. И у тебя получается всегда задача решена не с тем качеством, которое ты ожидал. И не посмотря в код ты об этом не узнаешь. Проблема в том, что у нас скорее всего будет работать, возможно, да. И возможно, действительно удовлетворяет бизнес. Но опять же, вопрос типа... Когда мы говорим про бизнес, это удовлетворяет бизнес. Это окей, да, если мы такие метрики. Если ты думаешь, что ты выполнил при этом инженерную задачу, и ты как инженер при этом действительно что-то сделал, ну это не так. Ты ничего не сделал. это не инженерный подход. Alex: Похоже, Take обсуждали с Константином, если я правильно помню. Я там тоже говорил по поводу своего рода развития хаоса, потому что на одном шаге он в одну сторону пошел, на другом он пошел в ту же сторону. И до какой степени можно доверять агентам, Ну, так сказать, да. До коля можно доверять агентам, чтобы перестать понимать написанный код. вся эта лапша получится там и так далее да при этом он конечно может работать как целая но что внутри вообще может быть Я такой тейк Artem: Слушайте, мне честно тут сложно сказать однозначно, потому что твой пример вот он очень понятен с тем, что агент попутал берега и ушел куда-то в другое русло, но вот лично у меня такого вообще никогда не было. То есть вот просто никогда. За все то время, что я работаю, это конечно не значит, что меня завтра это не случится, но вот на данный момент я просто не припомню такой ситуации, чтобы... Ну подобная ситуация, случилась. Это во-первых. Во-вторых, учитывая, что это все-таки удовлетворяет бизнес, есть решение, которое удовлетворяет бизнес, а что еще надо, вот если так смотреть. То есть бизнесу хорошо, он получил то, что нужно. Василий: Ууууу Alex: поддерживаться там и все такое типа лучшей практики Artem: Так поддерживать всё равно агент будет, а агенту вообще без разницы какие там лучше практики или худше, всё равно. Василий: Я бы поспорил. Artem: А вот давай, давай. Василий: Потому что, на самом деле, архитектура правильная и важна, описание этой архитектуры для агента. Правильно разбить проект по модулям, по пакетам, правильно описать, как агент должен пойти и найти тот или иной метод, чтобы работали класс. Это важно, и предсказуемость поиска, Мы понимали, где мы ищем какие-то артефакты кода, чтобы их поправить. Это тоже важно. Не то чтобы не каши, нет. Artem: Ну, чтоб не каша была, а в целом понятное какое-то решение. Василий: Потому что агент на самом деле, когда он работает, он читает весь файл подряд. есть, тебе нужно поправить функцию, и там у тебя 50 функций в файле, да? И он, ну, на 10 000 код. И он будет читать все 10 000 кода, и потом с них как-то выбирать то, что тебе нужно поправить. И это, во-первых, вот остальная информация, которая не является необходимой в данной работе, она засорит ему контекст и даст ему, точнее, не даст ему качественно сделать свою работу. Во-первых, во-вторых, ты потратишь на отчтение, на это все токены, и это станет дорого. То есть плохая архитектура для агента, делать разработку агентами дороже. Artem: но дороже у нас подписка мы за подписку платим то есть ты же не платишь за просто токены сами по себе Василий: Конечно, конечно, но меня подписка вылетает на раз, типа кодекса, я не знаю, хватает. Ну, короче, дня два я жду там, обновились все лимиты, вот бывает, частенько. Alex: Подожди, подписка, ты имеешь в виду, что подписка и токены не коррелируют? Или ты не про это говорил? Artem: Я говорю про то, что ты же платишь за подписку, у тебя есть, ну, есть, понятно, лимиты, но ты платишь просто ограниченное количество денег в месяц, да, там, за эту подписку. И, в принципе, без разницы, сколько ты токена потратишь в рамках того, что ты, ну, в этих лимитах остаёшься, своих. Василий: Но это если ты остаешься в лимитах. Alex: Ну а если типа много... Да, если ты остаёшься, а если токены там израсходовались, лимит вылетел, всё, типа не сделаешь работа. Artem: Ну опять же, вот Вася тут рассказывает про кодекс, а у меня складывается ощущение, что кодекс лучше не использовать. Василий: Да, есть такое. Но это не только так. У меня есть и Anthropica подписка, которую я использую для личных проектов, личная подписка, я активно использую Anthropica. Естественно, какой-нибудь Opus 5.5 гораздо лучше в разработке, но однако он не избавлен всех этих проблем, которые мы озвучили. Он просто делает чуть-чуть более лучшей работу, Codex. Вот, и у него пока нету проблем с выходом с границы, хотя, судя Artem: Угу. Василий: по новостям, там тоже какой-то шум идет в том, что они остановили обучение. если я сейчас ничего не путаю, в общении с их моделей У кодекса сейчас большой разбор, ну, OpenAI большой разбор идет, в липунж закончился, как раз всех инцидентов, когда агенты выходили за свои границы А, да, Anthropi, вообще они же на этапе обучения они отключили интернет, чтобы их модельнику они выходили, так же с этим связано, что они выходят за границы Так что, собственно, что то, что то, как говорится, работает... как селум из Кабара Я бы тут не ставил ставку на какую-то конкретную модель Тем более они достаточно близки по качеству Сейчас уже особо нету принципиального выбора что я буду выбирать своей работе то или иное в зависимости от модели, зависимости от того сколько это будет стоить и каких-то юридических факторов Ну, Artem: Ну... Василий: еще... Да, извини. Опять же, возвращаясь к лимитам, меня часто есть той, что я все в работе, используя подписку вот именно в рабочем порядке, меня очень часто заканчиваются лимиты. Подключенные MCP, Atlassian, то есть позайти в конфу, почитать документы, зайти поизучать задачи, комментарии. Подключенные MCP, GitLab, которые ходят, естественно, в GitLab и исследуют ветки и мерш-реклесты. там еще какие-то инструменты, куча кода, который действительно сильно растет, и его становится много, его тоже нужно постоянно держать. То есть если у тебя еще в добавок нет и микросервисов, то есть не какой-то продукт, где у тебя есть отдельные репозитории на какой-то отдельной частичке, модуль микросервисов, а у тебя какой-то монолит, то это становится принципиально важным. А у меня как раз монолиты. И это безусловно продуктовыми требованиями. Тут нужно быть аккуратным все равно. С подписки, с лимитами. Artem: Слушай, ну интересно, же, вот у меня очень-очень редко я выхожу за лимиты, прям очень редко. Это практически никогда не случалось, только вот я один раз помню, ну и то там, было 30 минут подождать, ну подождал, в принципе, Вот, ну как бы история про то, что я пока не убежден. Все эти тейки, про которые вы рассказываете, что архитектура важна, это все важно, надо смотреть код. Я не убежден пока что. Я со стороны бизнеса смотрю. Бизнес получает то, что надо. Все. Василий: Да, если мы со стороны бизнеса смотрим, то возможно в этом проблемы нет. И на самом деле я как менеджер доволен. Я говорю, нас не просто так, мы на каждом этапе организовали помощников, настроили инфраструктуру, и агентов для каждого сотрудника. нас на всем цикле работы над какой-то фичой. какой-то задачи у нас работают агенты, есть помощники там в работе. Это, естественно, делает ускорение, но я скорее про то, что все равно нужно быть обязательным, нельзя снимать себя ответственность, нужно точно контролировать то, что происходит, какие данные ты даешь на вход, какие на выход, на выходе получаешь какой-то И я глобально про то, что ценность программиста в том, что он несет ответственность. Потому что если убрать человеческую ответственность, ответственность сотрудника из этого уравнения, то зачем разработчики в целом нужны? Artem: Да, я этим согласен, ответственность. Но и не только ответственность. На самом деле понятно, что ты как CEO, ты не будешь сидеть с тысячей кладов и как бы сделай мне это, сделай мне то, сделай вот это. И ты вот так просто как осьминог в этих чатах с кладом и делаешь себе продукт такой, one man band. Вот это же не так. То есть понятно, что есть зоны ответственности. Маргетолог работает с кладом для того, чтобы делать свою работу. разработчик работает с Cloudом для того, чтобы делать свою работу. и как бы мы все там вот в разных сферах делаем свою работу с помощью Ишек, делаем там быстрее. Ну по факту. По качеству, ну не знаю, как будто бы бизнес доволен тем, что происходит. Василий: Да, бизнес доволен, бизнес в восторге, честно, потому что мы ускорение получили значительное, допустим, в своих продуктах. Alex: Кот больше не Ботлнек. Василий: Да, да, Artem: Да, да. Василий: но батлнеки сместились. Если у нас раньше был стандартный ворплот, дискавери, аналитика, там, написание кода, приемка к UA. Теперь код не проблема, это не узкое место, но сильно большая нагрузка идет на аналитиков и сильно большая нагрузка идет на приемку кода и изучение, ну, QA, да. Вот. И это очень прям сильно стало узким местом, потому что в аналитике все не так просто. Там не детерминированный код написать, какой-то, ну, условно. Там прям творческая работа, не только творческая, но ее нужно понимать. все аспекты, продукт и тех фичей, которые ты делаешь, которые работаешь, их нужно исследовать и правильно описывать исходя из всего их контекста. То есть, это прям действительно проблемой стало. вот, можем на этом подытожить, как раз я могу дать ответ, когда мы сказали, что код больше не узкое место, и первоначально вопрос нужно ли, важен ли язык. Да, язык важен, какой язык у тебя с продуктовой точки зрения в плане. Ты, скорее всего, не поставишь какой-то on-premise продукт, то есть продукт, который устанавливается из сервера клиентов в закрытый контур, не поставишь на Python, потому что они всегда могут изучить твой код, ты его не можешь скомпилировать, да? В этом плане Go, допустим, перспективнее. Ты можешь его скомпилировать, отправить бинарник и быть уверенным, что, ну... Это, конечно, не защищает тебя на 100 % от слива продукта, но всё равно то, что его не дезассемблируют и не расковыряют, и сделают какой-нибудь кряк. Artem: Ну ты же слышал про эти истории все, которые вот сейчас форсятся, что там чел создал все приложения Adobe на Rust с помощью Cloda и... Василий: Да, Artcraft. Ты пробовал стыкать сами? Это же отвратительные... Artem: Не, я не пробовал. Не-не. Василий: Пожалуйста, дайте, пожалуйста, соберите 10 профессиональных дизайнеров, общем, дизайнеров, кто работает в этих проектах, и дайте им эти проекты. Пусть они попробуют им пользоваться и дадут свое заключение. Прям онлайн-трансфляцию поставьте, смотрите на их страдания. Это отвратительный нейрослоп. Alex: А там же говорили, что это только начало, а потом мы захотим улучшить, но мы все улучшим все эти продукты. Василий: Ну, да, да, я верю, я верю активно в их обещания, потому что, конечно же, у нас за последнее время с выходом нейросетей стало значительно больше качественных продуктов, написанных ИИ, мы прям все с ними очень активно работаем. Это шутка, если что, потому что я не вижу ни одного продукта, который вышел бы и сказал, мы полностью написаны ИИ, и мы занимаем какое-то значительное место на рынке. Вот, смотрите, мы добились своего. ни одного такого продукта я не вижу. По крайней мере, если они появляются, то они быстро умирают. Вот. Artem: Кстати, был такой продукт, достаточно хайповым был какое-то время назад. Проект, не помню как он называется, но это какой-то тоже русский, по-моему, чел, сделал такой маркетплейс типа хэ-хэ, но вот полностью новой подиный. И там прям очень, ну он хорошо взлетел. Не слышал про эту историю? Василий: Не, не слышал, не слышал. Видимо, он настолько хорошо взлетел, что я регулярно нанимая сотрудников там вот в недавнее время не слышал про него. Хотя с Artem: Ха-ха-ха! Василий: ХК ну как бы да, есть проблемы, но все-таки это остается основная площадка для поиска. Вот я не думаю, что его можно заменить, у них слишком богатая экосистема вокруг этого всего и куча заинтересованных людей. Да, а все-таки, кстати, заинтересованные люди, давайте так, слышал... как-то вспомнил мем что-то там про то что я не беспокоюсь что у меня заменит ИИ пока на моей работе люди которые умеют работать с Excel не могут заменить людей которые не имеют работать с Excel то есть человеческий фактор человеческое сопротивление все-таки тоже вот это социально он сильно играет вот и это мы разработчики у нас как-то молодая индустрия мы такие гибкие еще в основном тут все молодые ребята вот Мы сами себя заменим по кайфу и пойдем, не знаю, шить ботинки. Все остальных-то не особо сложно, точнее, особо... не особо получится изменить. То, что люди, наверное, будут сопротивляться. На удивление, почему разработчики сами себя изменяют, единственные, кто сами себя изменит. Типа что-то тут не так. Artem: Ну да. Василий: Так что да, насчёт, возвращаясь к языку, язык, возможно, важен с точки зрения того, насколько он подходит под твой продукт конкретно, твоя задача. Не с точки зрения того, что это прям вот я должен писать на этом языке, потому что у такие вкусовые предпочтения или еще что-то, Важен с точки зрения наима на рынке людей, потому что все равно что-то приходится читать, что-то исправлять до сих пор, поэтому важно... каких разработчиков на рынке больше, каких ты можешь себе позволить нанять. Важно какая у тебя в целом экспертиза в команде, если у тебя уже есть разработчики. Вот это все было важно и до, и остается важным сейчас, и как будто бы и это не сильно поменяло. Так что и Go есть место, и Rastu там в каких-то узких местах есть место, и Python, естественно, останется на половых, все с будет в порядке, мне кажется. Так что... Artem: Слушай, давай поговорим про рынок. Ты как раз затронул довольно интересную тему. Во-первых, сравнение госпитона в плане устройства на работу. первая тема. Во-вторых, интересно услышать твоё мнение на тему того, что сейчас нужно разработчику в 2026 году и 2027 году. На что обращают внимание при найме? Что сейчас важно? техничка она до сих пор важна или все-таки какие-то вот больше там не знаю смещение к продукту сейчас требуется или или что-то еще Василий: Давай, пересуждаем. Я могу тут сказать исходя из своего опыта. Мне все равно, был ли опыт у человека ногой или нет, потому что его простой язык на самом деле. Мне важно то, сколько он понимает вообще, что происходит. Допустим, в его основном стейке, если он хорошо разбирается в капитоне, в том, как работает джил, как там, не знаю, асинхронность работает, какие-то клецевые буферы, не знаю. или какие-то компьютерсайз сложные вещи, точнее сложные базовые, то возможность не можно говорить независимо от того, каком языке он писал, хоть на JavaScript, хоть на PHP. Допустим, меня есть разработчик, и фронтенд-разработчик при этом свободно разрабатывает на Rust свои проекты, и он хорошо понимает компьютерсайз, независимо от того, что он занимается в основном веб-разработкой. фронтайн части. У него очень сильный бекграунд и опыт. Вот. И мы нанимаем в основном даже не гороизработчиков, мы просто нанимаем людей, которые хорошо разбираются в технологиях. нас, наверное, плей на команде является каким-то гороизработчиком, который до этого писали на го, а остальная половина это там C++ программисты, там или Java, бывший программист. А у нас есть там... математик, который писал ядра для графических каких-то инструментов, допустим, на отдельных языках. Я, честно, не помню, как называется, все на видеокарте связано. Что-то писал, в общем-то. И он очень хорошо, в общем-то, вкатился в ГО. Он буквально сразу начал писать. То есть люди, которые обладают базовыми знаниями, они легко вкатываются в ГО и сходу начинают приносить пользу. В этом нет проблемы. Там изучить концепцию, горутин, каких-то... Да им даже не надо изучать, собственно. Я не думаю, что C++ разработчик не знает, что такое горутина, с чем ее едят и как это вообще работает, или что C разработчик не знает. Даже на C есть такие библиотеки, по-моему, Литниу называют, которые реализуют концепцию горутина на C. Пожалуйста, пиши на C, как на ГО. С переключением в контекст. Важны базовые, фундаментальные навыки. И при найме нужно смотреть на это, плюс надо смотреть все-таки, если не говорить о hardах, мне кажется, то сколько человек хорошо осознают процессы вокруг своей работы. есть не только свои, которые конкретно, потому что я взял задачи в работу, перевел им прогресс, написал код, потом перевел в review, отдал на review, всем сообщил. есть он просто добросовестно выполнил свою часть работы, но и также... пытается осознать контекст вокруг своей работы, смежных команд, команды фронт-энда, почему у них какие-то боли есть, как он может сделать легче взаимодействие с ним, с командой. Какие проблемы команды, аналитики, которые рядом и заводят им задачи, как с ними построить диалог. То есть прозрачный... и своевременно приносить какие-то обновления, какие-то проблемы. То есть быть предсказуемым, интересоваться миром вокруг себя, не только конкретно своей работой, это важно. Такие люди могут влиять в целом на процессы, такие люди могут находить узкие места и делать именно работу в команде целиком лучше, что-то предлагать приносить. Это вот это ценно. Artem: Интересно. Ну а если опять же возвращаться к первому вопросу насчет Python против Go, у кого там больше шансов найти работу сейчас? Василий: Поэтому разработчикам было сложно найти работу и до и ии. Я нанимал, когда я был ледом на предыдущих местах бекенд разработки, участвовал в нами разработчиков в свою команду и было сложно даже на тот момент. Потому что с многими разработчиками просто нечего было обсудить. Они не могли ответить на какие-то базовые вопросы по своему языку. Я на них, честно, тоже сейчас уже не отвечу, потому что я уже больше двух лет не писал на Python. Но какие-то важные вещи, там, не знаю, как дикт устроен под капотом, да, или ещё что-то, как там лист, что-то что такое базово-динамические статические массивы, там, не знаю, как они представлены в языке, какими структурами. Вот это всё, это всё... Очень мало технической экспертизы было в Python среде. Возможно, нам просто такие не приходили, потому что компания, честно говоря, не топлива, прям что бы было. Artem: Ха-ха! Василий: Я не исключаю, как бы, все сказанное, подмечаю это мое просто сугубо личное мнение, никак мне не относится к реальности, возможно. Но я на тот момент понял для себя, что мне просто хочется иметь больше технической экспертизы, работать в командах, в которых есть больше технической экспертизы. чтобы расти вместе с ними. И на тот момент я уже принял, что следующий мой проект, ну, принял решение, что следующий проект и следующая компания будет, я буду писать на ГО, потому что ГО действительно выглядел перспективно на тот момент. А потом пришел и все уравнял, сейчас уже, по-моему, нет смысла. Вот, опять же, если нет каких-то продуктовых моментов в выборе языка. Вот. И отвечаю на вопрос, кому легче. Да, одинаково, одинаково. Мне кажется, одинаково. И тех и этих много, занимают значительную часть ринга. Конечно, питанистов побольше. Но если ко мне придет питанист и скажет, я хорошо знаю базу и хочу на го, пожалуйста, в этом нет никаких проблем. Я бы не сказал, что питанисты ограничены только своим стеком. И я хочу заметить, меня есть одна давно сформировашася мысль, она бывает еще до REE. На самом деле я с насторожностью отношусь к разработчикам, которые знают только один язык. и они долгое время уже в индустрии. Я понимаю, если вы там June, Middle, начинающий, да, и вы ничего другого не использовали, но если вы какое-то время в индустрии и у вас просто не появилось интереса ни к чему еще попробовать, потому что же раз туда, но это странно, все вокруг говорят, почему бы не попробовать, почему бы не изучить какие-то концепции. И на самом деле, вот изучение языков... Особенно если языки принципиально отличаются другим парадигмам, то язык хоть хаскель, функциональный или реликсир. Это сильно добавляет технического код, технической экспертизы в понимании, что, как реализовано. Потому что на самом деле все концепции в языках, не какие-то уникальные. Это все вертится вокруг общих каких-то знаний в компьютерсайенс. И когда ты разбираешься, как действительно что-то работает в одном языке, ты понимаешь, как это можно реализовать в другом языке. Допустим, концепция Geroutine, же не уникальная. И в Python есть GreenLett, насколько я помню, Artem: Угу. Василий: Собственно, ты можешь тоже там отключить, по-моему, сейчас даже GIF, если не шиваюсь, есть версия Python с отключенным этим global interpreter log и... Попробовать построить обработку запросов на гренлетах. Ну понятно, есть отличия от Go. Конечно, Go для этого больше всего подходит, и него все равно у Гарутина более легковесные динамические выделения памяти под них. Но все равно, при желании ты можешь это сделать, изучить эту концепцию, прийти в Go не с пустыми... знаниями, а зная какую-то базу уже, попробовав сделать в своем языке. Опять же, как я сказал, все есть библиотека, которая это реализует, Липмилл. В Java, по-моему, тоже есть зеленые треды. Они, по-моему, говорят, я часто не трогал, но говорят, что они даже сделаны удобнее, Go, гораздо прикольнее. Java-разработчики тоже могут прийти с этой концепции уже с знания в язык. То есть это не что-то уникальное. Artem: многие разработчики, они, наверное, боятся, не знаю, попробовать перейти в другой язык, еще и потому, что боятся потерять в грейде. Ну, например, типа, аляты там, Синьор на Питоне, пойдешь на Гошку и потеряешь грейд. Ну вот лично для меня эта история выглядит так, что если ты вот software engineer в senior grade, то вообще без разницы какой там тебя язык. То есть ну ты просто берешь любой другой язык, спокойно там учишь всю базу за три месяца, условно, а может даже и быстрее сейчас. И все. Ну и как бы твой grade, он никуда не делся. Он так и остался. Вот лично у меня такое мнение. У нас когда я учился в Яндекс.Правдиками... У нас был в группе товарищ, и у него был уже огромный опыт с 1С за плечами. И он все время говорил, что это вообще абсолютно другое, у меня этот опыт не считается. Но при этом он очень хорошо все схватывал на питоне. есть питон для него, язык переходный был. И я просто вижу, что для него все гораздо быстрее, чем для меня. И как бы вот говорить про то, что типа опыт этот никак не помогает, ну довольно странно. И про грейд тоже самое. То есть он говорит, что вот если я буду искать там работу, мне будет типа сложно найти, потому что я там условно джином буду. Я говорю, да не, нифига. Не будешь ты там джином, тебя как бы за плечами просто огромный опыт работы. Ну да, один S, другой язык, ну в принципе-то какая разница? Василий: Ну да, согласен. Причем у меня тоже есть похожий опыт, когда мы наняли один из разработчиков на Python позицию, как Python Developer, он достаточно неплохо начал писать. Не знаю, Artem: Может это он был? Василий: Да, согласен. В общем, весь опыт полезный, и полезен, когда этот опыт разнообразный. Так вот, я бы сказал в заключение. Artem: Это да. Это да. Ну, я думаю, что мы обсудили на самом деле достаточно много сегодня и про Питон, и про Гошку, и про Ишку, текущие реалии, и про то, куда уходить и сойти, если все-таки приспичило. Но мы все-таки, конечно, надеемся, что ситуация как-то устаканится более-менее. Вроде сейчас как-то мы выходим на вот это вот плато, да, и постепенно все стабилизируется, как мне кажется. Вот. Будет более-менее понятно с рынком. И в целом будет уже понимание, как там работать с теми же агентами, что хочет бизнес, как со всем этим работать дальше, чего ожидать и так далее. Я думаю, что на сегодня тогда можно заканчивать. Спасибо большое, Вася, за то, что пришел и поделился своему вот, это было прям очень-очень интересно. Обязательно подписывайтесь. на канал ставьте лайки, оставляйте комментарии, очень интересно, если вы питанисты, гошники, пожалуйста, пишите, рассказывайте свой опыт ну и в целом, что думаете про то, что происходит с яичкой, про все наши разговоры Вась, спасибо большое, что пришел Василий: Спасибо, что позвали. Artem: Будем рады видеть тебя еще раз, можем выбрать какую-то другую тему для того, чтобы обсудить Василий: Тогда. Artem: через какое-то время. И Василий: Да, буду рад. Artem: супер! Спасибо большое, что смотрели. Всем пока-пока!