Почему у всех проблемы с разработкой, а на рынке мало сильных программистов

Всем привет! Меня зовут Самат Галимов, и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионалов, с которыми можно поговорить простым человеческим языком. Сегодня очень необычный эпизод, потому что вести его буду не я, а наш редактор Юля Яковлева.

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

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

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

Да, когда ты так это проговорила, кажется, что да, эти две вещи связаны.

И мы позвали Федю, и я заняла роль ведущей, а Самата и Федя будут мне, человеку, который не работает в IT, объяснять, как же так получилось. Но прежде чем мы начнём... Ставьте нам лайки. Именно. Я скажу то, что обычно заставляю говорить Самата. Пожалуйста, поставьте нам пять звёзд. Оставьте комментарии. Мне лично это очень-очень важно. И мне очень приятно, что, когда я в прошлый раз появлялась в этом подкасте, в новогоднем выпуске, задавала Самату вопросы, которые нам слушатели прислали, и попросила вас оставить какие-то комментарии. Много людей реально их оставили, обратились лично ко мне. Это грело мне душу, сердце. И мне это понравилось, так что, пожалуйста, ещё хочу. Самата, теперь твоя очередь. Рекламная интеграция.

Это подкаст студии Либо-Либо, и мы его делаем вместе с сервисом онлайн-образования Яндекс Практикум. У Практикума есть курсы по разработке, по анализу данных, по веб-дизайну и по английскому языку. Если вы хотите освоить цифровую профессию, переходите на сайт Яндекс Практикум и учитесь.

Супер.

Меня зовут Самат, я в компании Федя и Самат отвечаю за продажи, за новых клиентов.

Меня зовут Федя Борщов, и в нашем с Саматом бизнесе я отвечаю за execution, за то, чтобы вещи случались.

Я отвечаю за отношения, чтобы они начались и чтобы потом все были довольны. А посередине Федя делает так, чтобы все, что мы пообещали, оно случилось. Например, мы говорим, мы вам запрогаем очень классную систему. Федя садится и прогает. Мы говорим, мы вам найдем 10 программистов. Федя садится и собеседует этих программистов, чтобы понять, что они реально классные. Короче, я продаю, Федя реализует.

У вас с Федей, конечно, реально perfect match. Я думаю об этом ещё с тех пор, как год назад мы в качестве последнего эпизода первого сезона записывали вашу с Федей партнёрскую сессию у юриста Дмитрия Грица, и вы в этом эпизоде обсуждали то, как вы будете строить свой бизнес, договаривались о партнёрских взаимоотношениях. И вот с тех пор прошёл реально уже год. Расскажите, что вы за этот год успели сделать?

Этот год мы помогли... Первым нашим клиентом была iGooods. Это крупный сервис, в котором можно заказать продукты на дом из разных супермаркетов. У них примерно 50 разработчиков на тот момент было, и не было технического директора. И компания доросла до такого размера, до такого масштаба, что... Одна команда разработки, такая монолитная, большая, которая все вместе делает сообща, уже не справляется просто потому, что вот команда в три человека хорошо координируется, в пять человек еще нормально, но 25-30 человек вместе координироваться не могут просто по определению, потому что галдёж. И один человек такой толпой управлять тоже не может, потому что ты не можешь за все сразу отвечать. Нужна какая-то другая структура. Это вот как бы организационная часть, а вторая часть, что и технически iGooods был таким большим монолитом. Значит, что все части программы, вся часть сервиса жили вместе, очень близко, тесно связано. И мы постарались решить обе проблемы.

Значит, iGooods был вашим первым клиентом, а кроме него?

Потом мы запустили сервис для онлайн-турниров для американского заказчика прямо с нуля, там набрали команду, запустили сервис. Потом мы сделали какое-то нереальное количество аудитов. Одно крупное медиа, два крупных сервиса для уральского одного олигарха, у которого там куча разных бизнесов. Потом сделали аудит и нашли СТО, то есть технического директора для украинского сервиса доставки еды готовой, типа Яндекс.Еды, на Украине. И, ну, в общем, был куча клиентов. Я поговорил с тысячей, мне кажется, людей. И мы наняли там, наверное, десяток программистов своим клиентам и одного человека себе.

Ну, это есть настоящая компания.

Заработали тонну денег.

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

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

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

То есть либо просто оставляете аудит и уходите, либо дальше ещё сами исправляете своими руками?

Да.

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

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

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

Это первое.

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

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

Ничего страшного.

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

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

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

Я не понимаю, как так получается. В смысле, ты говоришь, что у них есть все специалисты для этого?

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

А почему так?

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

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

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

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

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

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

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

Разработка ты имеешь в виду?

Да. И ты боишься там что-то менять, потому что ты не понимаешь, что там происходит. Какие-то люди, какие-то там фронтены, вот какого-то девопса там наняли. А что он делает? А зачем нам девопс? А вот мы тут какое-то облако купили. Если со стороны разработки нет кого-то, кто готов с тобой говорить и объяснять, то все это выглядит, как большая страшная каша.

И они, наверное, просто радуются, что хотя бы работает.

Хоть как-то работает.

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

Очень страшно.

Мы как бы делаем сейчас подкасты, уже там, 52-й эпизод сейчас будет, да?

Или, скажем, 53-й, 50-й эпизод.

А мы же затронули, типа, самое только... чуть-чуть совсем. Мы только поскребли по поверхности. А для того, чтобы что-то запрогать, тебе нужно, как бы, довольно много из этого знать. И программисты не стараются объяснять. Это вторая проблема, наверное, то, что люди не пытаются объяснить, что они делают и зачем они это делают.

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

Окей, хорошо. Есть большая компания, которая делает себе ERP. Это большая система, в которой взаимодействуют сотрудники, ставят друг другу задачи. И приходят программисты и говорят, а давай-ка мы это сделаем на микросервисах, и на скале, и на документно-ориентированной базе данных, и все это будет у нас асинхронно. Через Kafka (Кафку) работать. И работать через кавку, да, и вытянет гигантскую нагрузку. Я сейчас перечислил технологии, которые нужно использовать в банке для процессинга тысяч транзакций в секунду, когда мы там с карты платим, чтобы оно работало. А для того, чтобы сделать штуку, которая один человек поставил задачу, а другую задачу прочитал, она его ещё там уведомила, достаточно самых простых технологий, условно, PHP, фреймворка, простейшей базы данных. там нагрузки нет и никогда не предвидится. Но ребята увидели, да, у нас большая компания, нам нужна Kafka.

Мы мыслим амбициозно.

Мы мыслим амбициозно.

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

Это прямо сейчас мы делаем аудит очень крупной организации, вы все слышали название, скорее всего, сталкивались, если вы живете в России. Мы сейчас как бы назвали технологии, технологии нас поняли, а вот для нетехнологий я приведу аналогию. Ты говоришь, хочу себе стул сделать, сделайте мне пожалуйста стул, чтобы сидеть. А тебе говорят, о, чувак, нам сначала нужно специальный сплав, такой титановый, который в ракетах используется, вот на нем будет классно сидеть как бы.

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

Ну, скажем так, она как-то работает. Я не сказал, что она запущена целиком, но она как-то работает.

Смешно.

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

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

Да, и очень часто программисты, я сейчас одного конкретного человека представляю, очень часто программисты думают, я тут самый умный, бизнес тупой, нихера не понимает, они все идиоты, ну, буду делать, как они говорят. Они же мне деньги платят, буду делать, как говорят. Даже не буду пытаться им объяснить, что они неправы. Это вот очень частая картина. Я прямо много раз это видел, и у меня прямо сейчас в проекте есть такой программист, который достался в наследство, который прямым текстом говорит, ну, они все тупые, как бы, я что могу, делаю, но я особо не пытаюсь их даже убеждать.

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

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

Идеальная комбинация.

Да-да-да.

Сработаете много денег.

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

Это моя новая любимая рубрика.

Какой эпизод?

Я хочу, чтобы это был эпизод с Энделем.

Я вам сейчас расскажу о шестом эпизоде второго сезона.

Этот эпизод называется «Сон, расслабление, фокус. Как приложение Endel подбирает звуковой фон для сотен тысяч пользователей».

Там мы говорим с создателем сервиса Endel Олегом Ставицким. Взрывной эпизод, потому что ребята сделали приложение, которое генерирует музыку. Точнее, не музыку, а вот то, что называется звуковой фон. И они там использовали и какие-то разработки в области нейробиологии, пентагонические ритмы, которые что-то там говорят про музыку. И вообще сервис на очень тонкой грани, он с одной стороны вроде про здоровье, то, что называется health, с другой стороны он про реально классное современное искусство. И при этом он еще и денег зарабатывает. Это взрывной набор. Как у них это получилось сделать, мы говорили с Олегом Ставицким. Ссылку на про Endel мы положим в описании этого эпизода.

Я тоже воспользуюсь рекламной паузой и расскажу о проекте, который делаю уже без Самата в студии «Либо-Либо». Это подкаст «В один клик». Он вышел вчера, у меня реально был момент, когда запуск был завтра, правда, уже вчера, но, в общем, вы поняли. Это подкаст про электронную коммерцию, про электронную торговлю, про то, как компании продают свои товары, свои услуги, свой бренд в интернете. Этот подкаст «Запуск завтра». Там двое ведущих берут интервью у разных классных представителей этой индустрии, электронной коммерции, электронной торговли, и пытаются разобраться во всех тонкостях этого бизнеса простым, понятным языком. Я очень стараюсь этому помогать, как я помогаю в этом самату, в этом подкасте. Переходите по ссылке, которая будет в описании к этому эпизоду, подписывайтесь. У нас скоро выйдет там много всего крутого и интересного. Вы назвали прям такие суперглобальные проблемы. Я понимаю, что в итоге все более мелкие проблемы в это и упираются. Мы можем как-то эти большие проблемы декомпозировать, обсудить какие-то более маленькие конфликты, которые приводят в итоге к таким большим бедствиям.

Это реальный клиент. У нас есть Philips Россия, которому программисты сказали, что авторизацию через соцсети сделать невозможно. И вот крупнейшая вещь, которой должны пользоваться обычные люди, регистрируется только по e-mail, а через соцсети или через ВКонтакте одноклассники зайти не могут на сайт. Программисты так и сказали, что это невозможно, это слишком сложно.

При этом сделать авторизацию очень просто, да?

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

Почему программисты так сказали?

Ну вот начинают программисты делать вход через социальные сети. Сделали условный Google, начинают делать ВКонтос и выясняют, что он не отдает при аутентификации почту пользователя совсем. Ну то есть у ВКонтакта большая часть пользователя вообще без почты. Типа они там просто по номеру телефона когда-то зарегились, и почта вообще не знает, что такое. А у нас почта— это важное значение, уникальное в базе. У нас без нее целостность данных порушится. И программисты приходят и говорят, слушай, ну вот так у нас не получается. Нам придется ради того, чтобы сделать социальную авторизацию, отказаться от почты. Ну, в смысле, сделать ее неуникальной. Все, у нас не получится сделать социальную авторизацию. Это при том, что если бы они нормально вытащили это наружу, выяснилось бы, что авторизация через контосы не очень-то и нужна, и у всех пользователей давно есть Facebook, который почту отдает, и с этим все можно сделать. Но поскольку люди об этом не говорят открыто, вот прям про то, что типа нам нужна почта, у нас проблема в почте, то они не могут договориться и сидят без социальной авторизации.

А я бы задал другой вопрос. Я бы спросил у программиста, а зачем тебе делать почту уникальным полем? Можно ли без этого обойтись? Давай пускай у нас вконтактные пользователи будут без почты. Мы не будем делать email-рассылки, я понимаю, что это сломается, но зато все остальное у них работать будет.

А в итоге мы просто начали генерить пользователям из Вконтакта рандомную почту?

Ну, надо на них, кстати, потом рассылку случайно не сделать.

Не сделаем.

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

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

Ещё надо добавить, что ты говоришь «собрать в одной комнате», иногда они переписываются типа в Телеграме или в почте. Ну короче, вот то, что мы сейчас с тобой за три минуты обсудили, может растянуться типа на полторы недели обсуждения.

Мы действительно звучим как ужастик просто. Это правда.

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

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

А команда— это команда кого? Разработчиков и продуктов или кого?

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

И дизайнеров.

Ну и дизайнеров, понятно, да, и всех, кто посередине сидит тоже.

Но важно, чтобы... И толпа людей, получается.

Их должно быть не больше 9, ну, блин, 9, мне кажется, это предел.

Да, даже много.

Уже много, да. Их должно быть при этом мало, понимаешь? То есть должны быть все специальности, но при этом их должно быть мало. Это означает, что команда должна быть маленькой. И если у тебя проект гигантский, то у тебя должны быть независимые команды, то, что я в самом начале упомянул, то, что мы пытались сделать в iGooods, когда каждая команда независимо может собраться, принять решение, сделать, когда не нужно собирать встречу на 30 человек.

Микросервисная архитектура команды.

Да-да-да. Это называется кросс-функциональная команда, когда у тебя есть разные функциональности.

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

Здесь очень важно, чтобы участники были тоже достаточно прокачены. Программист тоже должен приносить проблемы, не стесняться рассказывать о своих внутренних вещах, которые ему кажутся непонятными, то, что бизнес на него сейчас надавит и все остальное. И проблему он тоже должен так формулировать. Ну, то есть представьте себе, встреча длится час, а начинается она с того, что программист приходит и говорит, у нас не получается сделать социальную авторизацию. И первые 20 минут ты тратишь на то, чтобы там на 9 человек выяснить, а почему у него не получается. При этом прокачанный программист, который думает про бизнес, он придет и скажет, так, чуваки, у нас тут проблема с ВКонтактом, Вот. Нам обязательно вообще ВКонтакт нужен для того, чтобы сделать социальную авторизацию. продакт, да не, нам в Facebook норма будет. Все, вопрос решен за 2 минуты.

Или программист приходит и говорит, а можем в ВКонтактном польсе рассылку не делать? Да, можем. Все. Проблема тоже решена.

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

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

А есть какие-то именно технические проблемы, которые от компании к компании повторяются?

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

Федь, ты сейчас описываешь проблемы в коде, а вот как это выражается для пользователя? Что для пользователя ломается?

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

Самое страшное, это то, что все, что описывает Федя, это случаи из практики. Вы можете знать места, в которых это происходит. То есть крутой, классный бизнес, всем радуется, все пользуются, мне самому он дико нравится, а потом ты приходишь и понимаешь, что под капотом там происходит просто ад. И ад не в том, что бизнес плохой, а в том, насколько лучше он мог бы быть, если бы у него была нормальная разработка. Потому что бывали случаи, когда сайт выдерживает нагрузку в тысячу посетителей, а в пять тысяч посетителей в день уже нет. Или у тебя было там пять разных способов оплаты заказа. Ты хочешь добавить шестой, а тебе программисты говорят, о, чувак, тут как бы работать на полгода. То есть у тебя уже 5 есть, тебе нужно просто шестой добавить, а это работа на полгода. Почему? Ты не понимаешь. Потому что эта глава была дописана пораньше, ее нельзя просто взять, надо все сдвинуть сначала, надо все переписать буквально.

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

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

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

Так и делают.

Так делают, да.

Тогда просто команды в два раза всегда увеличиваются.

Это вообще фигня. Это вообще не проблема. Баблом залить не вопрос. Другое дело, что невозможно протестировать быстро. Это все равно занимает время. И это время растет.

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

А в реальности пишут частично, тесты вообще не пишут?

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

эта культура не развита?

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

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

Такая ситуация, видимо, часто может возникать. Что бы вы делали на месте такого программиста?

программисту стоит в этот момент пересчитать на деньги, во сколько встанет то, что тестов нет. Это всегда можно, вообще все, что хочешь, можно перевести в деньги. И как только ты это переводишь в бизнес, сразу все становится очень быстро понятно. Ну и плюс доверие должно быть. Если ты программист, который обманываешь со сроками и никогда своего слова не держишь, то верить тебе про то, что это важно, никто не будет. То есть тебе нужно иметь накопленный авторитет. Я еще хотел рассказать про тесты. У нас тут такой эпизод получается. Мы как будто программисты все время пинаем, шпыняем, поэтому хочу поделиться историей, которую я недавно прочитал. Про то, как компания Oracle— это главный производитель баз данных в мире. Одна из главных компаний, которая делает базу данных. И у них, оказывается, все покрыто тестами, миллионом тестов. Я не знаю там точное количество, сейчас боюсь соврать, но там типа десятки тысяч тестов. На этой программе, мне кажется, 25 лет уже непрерывно работают десятки тысяч программистов. Люди работают там полгода, уходят, новые приходят. То есть с организационной точки зрения там полный бардак. Но за счет того, что у них все покрыто тестами, эта программа является образцом стабильности.

Люди не справляются, но технологии справляются.

Да, то есть они сделали так, они сделали такую систему, в которой невозможно сломать программу.

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

Да-да-да, там реально типа ты сделал программу, отправил ее тестироваться, она там на десятках тысяч серверов запустилась, и через два дня пришел результат. Реально так, Федя. То есть это безумие. Я бы не хотел там работать, и все, кто там работали, говорят, что они там не хотят больше работать, но бизнес работает до сих пор.

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

Мне трудно пинать бизнес по двум причинам.

Первое, то, что... Они ваши клиенты.

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

Ты имеешь в виду, что врач – это программист?

Это ответственность врача уважать и знать свою профессию.

И не делать какие-то ошибки. В твоем примере у врача полная власть, а в реальности у бизнеса, скорее, власть у пациентов.

Ну, конечно, и в медицине современной власть у пациента во многом.

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

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

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

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

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

А можешь пример привести?

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

Может показаться, что мы в конфликте, потому что, с одной стороны, вот мы сейчас рассказывали, как надо делать правильно, а потом Федя говорит, фичи надо фигачить, нужно быстрее бизнес создавать то, что ему надо. Это конфликт, он реальный, Федя, или как это соединить-то? С одной стороны, надо хорошо работать, с другой стороны, нужно фичи приносить.

Ну, на самом деле, это не дихотомия. Ну, то есть нет такой вот прямой, на который с одной стороны писать хороший код, а на другой стороне быстро делать. Быстро— это когда ты пишешь достаточно хороший код так, чтобы быстро с ним работать. Грубо говоря, когда мне говорят, что «Федя, слушай, тесты— это медленно, это нас замедляет». Я говорю, нет, тесты вас ускоряют, потому что когда ты пишешь код, ты не тратишь время на то, чтобы проверить, что он работает. Когда ты работаешь там без этого, тебе сложно. Вместо того, чтобы решать задачи, ты думаешь, сломал ты что-то или нет. То же самое с непонятным кодом. Понятный код нужен не для того, чтобы им гордиться и рассказывать всем, какой я понятный код написал, а для того, чтобы, когда ты решаешь задачу, думать не про код, а про то, что ты дашь бизнесу, когда ты решишь, как она будет работать. Поэтому я здесь за такой достаточно средний подход о том, что код должен быть, конечно, хороший, но хороший не идеальный, а настолько, чтобы тебя самого не замедлять.

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

это тесты, архитектурная чистота. Ну и вообще есть куча умных книг, которые говорят о том, как в принципе выглядит хорошее программное обеспечение. Начиная с всего того, что издал там Мартин Фаулер, и заканчивая книгой, которую всем нужно прочитать, это «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» (Gang of Four), она так и называется. Там описано, не знаю, порядка десяти, я не помню, сколько паттернов, Это вещи, по которым принято проектировать программное обеспечение. Такие вещи базовые, их нужно изучить и знать.

Я подумала, что мы обсудили, как можно стать лучше с точки зрения хардскиллов, но многие вещи, о которых вы говорили, про soft skills, про то, как общаться, как слышать друг друга, как не бояться там рассказать о своих трудностях. Как вам кажется, как эти скиллы прокачивать, и, может быть, какие вы можете дать советы?

Самый простой совет— это приходите на мой курс для тем лидов. Боюсь, когда выйдет подкаст, он уже запустится.

Я не знаю, что за курс с Федей про темледов. Я уверен, Федя там научит темледов. Я точно знаю, что если работать в компании, в которой уже выстроен процесс и программисты говорят с бизнесом, а бизнес говорит с программистами, то даже начинающий разработчик постепенно научится этому. Это скилл, который нарабатывается. Мы просто тут с Федей представляем такие два разных характера, может быть, или типа личности, я не знаю, как это назвать. Но, в общем, Федя, я знаю, он может сесть, прочитать книжку, все понять и начать так делать. Я в этом плане гораздо более... Ну, я хочу как бы быть в правильной тусовке, и я у них научусь. Это мой путь обучения. Я правильно объясняю, Федя?

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

А где ты учился?

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

Насколько я знаю, ты работал в студии Лебедева.

Да, это было самое первое. Я им очень-очень сильно обязан именно в soft skills. Я там научился управлять программистами, я там научился более-менее разговаривать с людьми. До этого у меня было все совсем плохо. Прекрасное место, я очень ему благодарен.

Вы сейчас ищете программиста. Это то вообще, почему этот эпизод возник. Расскажите, кого вы ищете.

Мы ищем опытного бойца, который умеет и прогать, и имеет прокаченные софт-скиллы.

Наш стэк— это Python и JavaScript.

Мы ищем уже самостоятельного программиста.

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

Потому что это очень сложно просто пробовать. Это сложный интеллектуальный труд. У меня есть софт-скиллы, я никогда не пойду пробовать. Ну нафига? Сложно это.

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

Ну да, у меня, наверное, порядка 30-40 откликов в неделю сейчас.

Офигеть. Ну это очень много. И не получается найти, да, такого человека пока?

Да.

А можешь проанализировать, в чём проблема?

Вот это меня и бесит.

Меня тоже.

Можешь проанализировать, в чём проблема во всех этих кандидатурах? Ну, какие там есть, может быть, повторяющиеся ошибки? Чего не хватает этим людям, чтобы к вам попасть?

Я вот когда думал о том, о чём мы сегодня будем говорить, я подумал, очень хотелось рассказать о своём тестовом задании, которое предусматривает как раз soft skills, hard skills, но потом я подумал, что если о нём расскажу, то мне придётся придумывать новое. Блин! Я его очень долго придумал.

Ну, заметьте, на самом деле Федя уже подсказал, оно больше про soft, чем про hard.

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

Именно с точки зрения soft skills?

Да, с точки зрения soft skills. Хардскилы на моих проектах, они достаточно легко передаются, потому что у нас очень хорошая документация, у нас очень хорошие практики используются. И для того, чтобы просто начать писать, хоть как-то закрывать задачи бизнеса, можно за недельку прочитать список материалов, которые мы даем, и на вторую недельку начать его решать. Хардскилы-то мы здесь тоже можем подтянуть. Это я сейчас говорю про линейных программистов.

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

У меня есть два примера. Один ещё до того, как мы с Федей начали работать, уже мы вместе с Федей. Я не знаю, насколько он про коммуникацию, наверное, все-таки про коммуникацию тоже. В iGooods мы думали, что мы сможем поменять культуру компании целиком, то есть вот перестроить процессы целиком, и у нас не получилось. То есть мы на наших отчетных встречах, мы каждые две недели встречались с владельцами бизнеса. И рассказывали что-то. Мы ничего не соврали. Все, что мы говорили, все было правдой. И нам было чем гордиться. Но сейчас, с расстояния смотря на это, я понимаю, что гордились и хвастались мы какими-то мелочами, а слона в комнате мы и не видели, и не замечали. И если бы мы с самого начала сказали, что наша самая большая задача – это сделать кроссплатформенные команды, если бы мы 4 или 5 недель подряд на встречу приходили бы и говорили, что самое важное мы еще не сделали, зато смотри, сколько финтифлюшек классно получилось, то они бы, наверное, задали нам прямой вопрос, ребята, вы что делаете вообще? Давайте что-то менять. И тогда начался бы очень трудный, но очень важный разговор. Мы бы сказали, знаете, чуваки, для того, чтобы эту сложную штуку поменять, вам нужно вот такое тяжелое решение принять. Готовы его принимать? Да, нет. И это был бы какой-то уже настоящий разговор. Он был бы трудный, очень тяжелый. Я сейчас представляю это. Для меня, может быть, даже невыносимо тяжелый в те времена, потому что я был менее уверен в себе. Но он привел бы к результату, он привел бы к реальным изменениям. А так мы полгода что-то делали, и мы, честно говоря, недовольны результатом.

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

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

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

Короче, у меня в одном из моих прошлых проектов, где я еще без фейди работал, было такое, что компания, есть продукт, он приносит деньги, все работает, но ничего не прогается нового. Типа там 10 backend-программистов не могут одну простую штуку запилить. Даже я знаю, что она простая, но не могут запилить. И я привык работать с ребятами, с бэкендерами, которые очень самостоятельные, очень автономные. А там вообще не так. Было так, что, ну, ребята просто, типа, ничего не делают. Правильное решение в этой ситуации было просто всех уволить. Всех десятерых. Одним днем. Просто сказать все, как бы. А я несколько месяцев пытался с ними договориться, я пытался научиться давать им ответственность, требовать от них. Даже кого-то одного уволил. В общем, это была какая-то беспомощность. Я просто на самом деле начал в себе сомневаться. Я подумал, может быть это я дурак, может там реально все такое сложное. Хотя... Ну, вот такой опыт до сих пор я воспоминаю таким ужасом, потому что меня позвали настроить разработку, разработка плохая, а я несколько месяцев просто получал зарплату и ничего радикального не изменил. То есть, опять же, финтифлюшки, что-то улучшил, что-то стало лучше, но суть происходящего, то, что люди вообще типа ничего не делали, она не изменилась, и мне за это тоже стыдно.

А чем все закончилось?

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

У нас есть финальный вопрос. Что вы читаете в интернете или смотрите, или слушаете?

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

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

Точно, я вспомнил, я читаю рассылку Hacker News, она мне приходит раз в неделю, ну и пара таких более специализированных, связанных с Python, SQL и так далее.

Какие? Расскажи.

Если вы питанист, то наверняка подписаны на рассылку Python Weekly, это прям обязательно нужно читать, там есть все новости, все, что нужно, причем в сжатом хорошем виде, без чего-либо лишнего и кликбейта. Хакер-ньюс я читаю просто, чтобы понимать, что в мире происходит, что там в Суэцком канале, и такие вещи там всё тоже туда пролезают. И мне как-то такого хватает.

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

Я знаю, что ты смотришь какие-то необычные YouTube-каналы.

Это тема для отдельного подкаста. Но есть такие популярные, совсем популярные, типа Veritasium. Это такие известные YouTube-каналы, ютуберы. Мой YouTube, он довольно интересная образовательная платформа. Обычно говорят, что YouTube тупой. У меня это довольно интересно. Из такого чуть менее обычного Curious Droid. Такой лысый британец, рассказывает про космос и про всякие странные технические штуки. Ууу, есть Найл Рэд, он про химию делает офигенные видео. Ещё есть какой-то чувак, я, к сожалению, не помню, как его зовут. Ссылку, надеюсь, положим в описании. Там он делает генетику. То есть он показывает, как у себя дома сделать, например, пивные дрожжи, которые будут вырабатывать шёлк. Типа он заменяет часть генов у дрожжей для того, чтобы они вырабатывали шёлк. Вот. Такие вот ютьюберы.

Отличный образовательный контент. Супер. Спасибо. Я надеюсь, что вы скоро найдёте программистов, которые вам нужны. Хотя бы одного.

Я очень на это надеюсь.

Куда тебе писать, Самат?

Куда мне писать? В телеграм, в фейсбук, на почту, куда угодно.

Супер, спасибо.

Спасибо тебе.

Спасибо большое, Юль.

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

Это подкаст студии Либо-Либо, и мы его сделали вместе с сервисом онлайн-образования Яндекс Практикум. Над подкастом работали редактор Юль... Редактор или ведущая?

Редактор.

Нет, давай раздём по-другому, сейчас. Над подкастом работали редактор и ведущая Юля Яковлева, продюсер Павел Боровков, звукорежиссёр Нина Мамотина. За джингл спасибо Алексею Зеленскому.