Здравствуйте, меня зовут Дмитрий Карловский, и я.. многим тут больше известен как автор фреймворка $mol, названного так в честь моего маленького друга - доллара, так как позволяет здорово экономить деньги при разработке больших проектов. Но сегодня речь не о нём, а о том, как мы, программисты, осознано или нет обманываем бизнес, вынуждая его тратить много денег ради мизерного выхлопа. Можете глянуть видео запись..
А можете почитать несколько расширенную текстовую расшифровку с более выверенными формулировками..
Какая компания?
Я почти 30 лет в программировании, из них 20 занимаюсь этим профессионально. Вот наиболее известные компании, где я работал..
Кто узнал себя в этом списке? Надеюсь, вы меня не побьёте, так как далее я буду нас сильно ругать. На всякий случай всё же запаситесь огнетушителем.
Какая фронтенд-технология?
Работал я профессионально как с различными noname велосипедами, так и с довольно известными технологиями..
Это конечно далеко не всё, с чем я знаком, это лишь то, за работу с чем мне платили деньги.
Кто не узнал себя в этом списке? Значит мы крутимся в разных экосистемах, и нам с вами будет о чём поговорить.
Какой левел?
Прошёл я путь по карьерной лестнице от джуна, который простые вещи делает сложным способом, а сложные не может сделать вообще, до синьора, который сложные вещи делает простым способом, а простые делать просто лень. А уперевшись в стеклянный потолок, занялся своими проектами, которые делаю так, как считаю правильным, тогда, когда есть для этого настроение.
Есть ли тут джуны? Надеюсь, мой рассказ не отпугнёт вас от желания пройти весь этот путь.
А есть ли мидлы? Вы каждый день крутитесь во всём этом дикообразии, так что прошу прощения, если у вас возникнут вьетнамские флешбеки.
А есть ли синьоры? Очень приятно, что меня пришли послушать и серьёзные ребята.
Что любят программисты?
Конечно же писать свои велосипеды!
Это просто интересно.
Это даёт саморазвитие.
Это развивает прогресс.
Это тешит самолюбие.
Все самые крутые разработки когда-то были просто наколеночными велосипедами талантливых людей, которые они не бросили, а улучшали, попутно повышая и свою экспертизу.
Чего боится бизнес?
Конечно же наших самописных велосипедов!
Часто имеют низкое качество.
Требуют много времени для доведения до ума.
Привязаны к автору.
Потратив кучу времени на разработку и вылизывание, автор велосипеда может покинуть проект и тогда бизнес остаётся у разбитого корыта. Новый программист смотрит на всё это, говорит "это невозможно поддерживать, надо всё переписывать", и.. пилит новый велосипед. И так несколько кругов, пока не будет создан такой велосипед, который никому не захочется переписывать. Ну или пока либо ишак не сдохнет, либо падишах. Но не будем о грустном..
Как бизнес закручивает гайки?
Требует коробочные решения.
Верит большим корпорациям.
Следует за рынком труда.
Давайте обсудим эти чаянья, но сперва разберёмся с уровнями абстракций..
Какие бывают решения?
Я выделяю 4 уровня решений помимо языкового..
Уровень | Определение | Примеры |
|---|---|---|
Библиотека | Полный контроль над всем | jQuery, Backbone, React |
Фреймворк | Единые архитектурные рамки | Angular, Vue, Ember |
Конструктор | Сборка из готовых кирпичиков | ExtJS, SAPUI5, $mol |
Платформа | Подстройка под себя уже готового | SAP, 1C, Drupal, Wordpress |
Чтобы проиллюстрировать ключевую разницу между уровнями, позвольте рассказать вам одну историю из жизни..
Зачем нужны высокоуровневые решения?
В одной компании мы разрабатывали свой фреймворк на базе React. И решили мы как-то сделать простое приложение для ведения заметок для проверки его в деле. Заняло у нас это несколько дней, но результат получился ещё не готовый к продакшену: нужны были доработки дизайна, фиксы багов и тд.
Неудовлетворённый таким положением дел, я взял свой любимый конструктор $mol и сделал аналогичное приложение за 2 часа (я засекал). И оно мало того, что было готово к продакшену, так ещё и обладало большей функциональностью. До сих пор использую его для своих личных нужд практически в первозданном виде..
Но и это ещё не конец! Тут мой коллега берёт платформу 1С и делает аналог вообще за пол часа. Казалось бы, чем выше уровень, тем быстрее разработка. Однако, необходимо признать, что получившееся приложение выглядело так себе, было не удобным, но самое страшное - не хватало некоторых фич, которые платформа не поддерживала вообще. Добавление оных, если и было возможно, то потребовало бы куда больше времени, чем мы сэкономили на использовании более высокоуровневого решения.
Ключевой вывод из этой истории: чем выше уровень решения, тем быстрее вы выполняете типовые задачи, но кастомизации зачастую даются с большим трудом. Зачастую, но не всегда. И $mol тут редкостное исключение, ведь проектировался он мной под простоту кастомизации без компромиссов со скоростью разработки.
Большие компании плохого не посоветуют?
На одном уровне абстракции слишком много решений. Какое же выбрать? Конечно же мы отдаём предпочтение крупным корпорациям с кучей бабла. Мы ожидаем, что большая компания потратила кучу времени и денег, чтобы проверить все варианты архитектур, выбрала наилучший из них, отполировала и представила общественности.
Ага, конечно. Возьмём историю с React. Когда FaceBook выпустила его в свет и распиарила на весь мир как серебряную пулю, в самой этой социальной сети React ещё не использовался. И только когда куча компаний на него подсела, набила всевозможных шишек, переписала несколько раз с свои приложения, только тогда в самом FaceBook начали появляться части написанные на React. Спасибо за бета-тест, как говорится.
Особую пикантность этой истории придаёт тот факт, что FaceBook, не смотря на кучу бабла и людей, является технологически весьма простым приложением. А вот, например, Яндекс - куда более крупный. Ведь это сотни проектов, которые должны быть выполнены в едином стиле, и по максимуму использовать наработки друг друга.
Для решения проблем, которые есть лишь в по настоящему крупных проектах, у Яндекса был даже разработан свой фреймворк - BEM. Я работал в Яндексе как раз, когда он только зарождался, так что прекрасно понимаю проблемы, которые он решал. Но уже в тот момент его подходы были весьма консервативными, а на текущий момент они и вовсе устаревшие.
По хорошему, его надо было бы осовременить, и тогда получилось бы что-то типа $mol. Фактически кроме BEM и $mol сейчас нет ни одного решения, которое бы действительно решало проблемы большого энтерпрайза, а не просто выглядело как энтерпрайз (привет, Angular).
Но, под давлением ситуации на рынке труда, где любой войтивайти, выучивший за месяц, как писать шаблоны на JSX, пишет у себя в резюме Senior React Developer, Яндекс отказался от своего решения в пользу React. Вы только гляньте, как разработчики буквально резали свою архитектуру по живому, чтобы хоть как-то приспособить React под свои нужды:
Получается абсурдная ситуация: технологически маленькая экстремистская компания FaceBook диктует огромному православному Яндексу как писать код. И ладно бы диктовала что-то хорошее. Но нет, код только деградирует. А ведь именно такие крупные компании как Яндекс имеют все возможности разрабатывать и внедрять лучшие технологические решения, двигающие индустрию вперёд. Но вместо этого.. компании поменьше ориентируются на выбор крупных компаний, и всё катится во всем известное место.
Большая компания же не убьёт свой проект?
Даже если проект приносит по меркам обычного работяги огромные суммы, то по меркам большой компании, это могут быть просто крошки на столе. Так что проект может быть легко закрыт, если менеджмент посчитает, что проект приносит недостаточно прибыли. А уж про проекты, приносящие лишь убытки, и говорить нечего.
Одним из таких проектов в своё время стал, например, AngularJS. Многие компании тогда делали свои стартапы именно на нём. И сколько же счастья было в их глазах, когда Google такой вышел и сказал, мол весь ваш только что написанный код теперь легаси, и предложил полностью переписать его на совершенно другом фреймворке с похожим названием - Angular. Что ж, спи спокойно AngularJS, ты прожил почти 6 лет.
И даже если разработчики горят проектом и хотят его дальше развивать - это не всегда возможно по лицензионным причинам. А если это ещё и закрытая разработка, то она так и умирает в недрах компании.
Так, например, случилось с моей интеграцией Angular + MobX + SuspenseAPI, позволяющей капитально снизить сложность и, как следствие, стоимость разработки на Angular.
Или с более амбициозным проектом - легковесным WYSIWYG редактором, который и для комментариев было бы не дорого затянуть, и документы на сотни страниц можно было бы редактировать с pixel-perfect выводом на печать.
Не основной бизнес - первый кандидат на оптимизацию.
Даже если разрабы горят проектом - у них нет прав.
Ну ладно, будем верить в долгую поддержку..
Хороша ли документация от большой компании?
Решения от большой компании часто сопровождаются обширной документацией, ведь она может позволить себе нанять толпу технических писателей, которые напишут много текста.
Однако, важно иметь ввиду, что по настоящему хорошая документация должна в максимально лаконичной форме быстро отвечать на возникающие у прикладника вопросы, а не вываливать на него тонны информации.
Если взять хорошее техническое решение, то оно обычно настолько просто в использовании, что зачастую достаточно краткого описания, несколько примеров, и можно идти в бой.
В переусложнённых же решениях так просто уже не разберёшься. Так что талмуды текстов, кукбуков, видеоуроков становятся жизненно необходимыми. Иначе вообще ничего сделать не получится.
Но какая бы документация ни была исчерпывающей, в ней всё равно остаются пробелы. И если решение простое, то нет проблемы заглянуть в исходники и понять "ага, во я дурак, надо делать иначе" или "ага, у вас тут бага, держите мерж-реквест". С переусложнёнными же решениями такое уже не прокатывает. Открываешь такой исходники и понимаешь, что неделю только будешь разбираться, как оно вообще работает, и ещё пару недель потребуется, чтобы исправить проблему. Ну или проще написать issue вендору и ждать с моря погоды.
Обширная !== хорошая.
Следствие переусложнённости.
Всё равно будут пробелы.
Хороша ли поддержка от большой компании?
От большой компании мы ожидаем быстрое решение возникающих проблем, ведь она же может позволить себе нанять кучу высококвалифицированных разрабов на поддержку их продукта.
Ага, держи карман шире! Случаев обратного на моём веку было много, но наиболее ярким был связанный с Angular Router, который не обновлял адрес ссылки, когда менялось значение поля, от которого он зависел.
Казалось бы, обеспечение инвариантов - это основа любой реактивной системы. Оно должно работать как часы, иначе разработка превращается в ад отладки. То есть этой проблемы не должно было быть в принципе - она не должна допускаться уже на уровне архитектуры..
Но её не просто выпустили в прод, но и чинили несколько лет, исправив лишь в 10 версии. А до тех пор пользователи плакали, а прикладные разработчики тратили кучу времени на придумывание воркэраундов, чтобы хоть как-то с этим жить, добавляя ко всем ссылкам такого рода костыли..
[routerLinkActiveOptions]="{ __hack__: [ id, mode ] }"Они писали статьи и записывали видео о проблеме, которой не должно было быть вообще. И это лишь одна из многих, ведь Angular вышел в свет крайне сырым. Обилие проблем и сложность их решения - следствие переусложнённости решения. Даже самая божественная поддержка здесь бы не справилась, а тут она вообще бесплатная.
Хороша ли платная поддержка?
Есть у меня история и про коммерческую поддержку коммерческого коробочного продукта SAPUI5 от компании SAP. Делали мы как-то на нём бэкофис для маркетологов Ленты. И вот, сделали мы интерактивную табличку на 30 строк, а она так сильно тормозит, что пользоваться этим невозможно.
Пишем в поддержку, мол "что за дела? как ускорить?". На что нам был дан потрясающей лаконичности ответ: "а вы не выводите в таблицу больше 20 строк". Прекрасно, следующий месяц мы потратили на рефакторинг с прикручиванием к табличке пагинации.
Вообще, мы здорово налетались с этим коробочным решением: пролетели по срокам, влетели на бабки, а потом ещё и разработчики все разлетелись. Показать эту табличку я вам, конечно, не могу, но могу показать вам кое-что по интереснее. Вот смотрите, табличка на 10 тысяч строк, реализованная за 10 минут предельно наивным кодом..
И она не тормозит даже без поддержки от вендора. Примерно такого обычно ожидаешь от коробочного решения от большой компании за много-много денег: чтобы ты просто сел и поехал, не думая про архитектуру, оптимизации и тп. Чтобы профессионалы своего дела продумали всё за тебя и дали лучший инструмент из возможных. А с SAP-ом у нас получилось: "Спасибо, что заплатили. Следующий. А вы мучайтесь дальше сами, отстёгивая нам взносы".
Большое комьюнити же поможет?
Ну ладно, ничто не совершенно под луной. Но у популярного решения будет и большое комьюнити, и вместе мы решим все проблемы.. Ага, как бы не так..
У специалистов на вас нет времени.
Остальные ничем вам не помогут.
Зато страдать будешь не в одиночестве.
Комьюнити поможет вам с тривиальными вопросами, ответы на которые есть в документации, если не полениться её прочитать. Но чуть менее тривиальный вопрос, и вы в жопе: в лучшем случае вам ничего не ответят, а в худшем такого насоветуют, что лучше бы молчали. Плюс вам несколько раз объяснят, какой вы дурак, раз хотите от инструмента таких странных вещей как эффективность работы, адекватное поведение в исключительных ситуациях, минимум писанины и максимум гибкости.
Ладно, наивно было бы ожидать бесплатную помощь..
Мы же наймём хорошего спеца?
Чем больше комьюнити той или иной технологии, тем проще найти специалиста на ней. Однако, одно дело искать плотника для создания табурета, и быть уверенным в результате. И совершенно другое - искать специалиста по закручиванию шурупов крестовой отвёрткой и ожидать, что собранный им табурет не развалится, когда вы на него сядете.
Много дилетантов: jQuery-программист, React-девелопер.
Мало профи: знают разные фреймворки и разные языки.
Курица или яйцо?
К сожалению, часто вместо того, чтобы выбирать технологии, основываясь на технической целесообразности, тем самым популяризируя лучшие инструменты, мы выбираем популярные технологии, в надежде, что среди сотен дилетантов найдём хоть одного профи, но при этом усложняя разработку, что требует найма всё большего числа разработчиков. А больше вакансий - это больше внимания разработчиков именно к этой технологии, ведь все хотят быть востребованными.
Разрабы учат то, что указывают в вакансиях.
Технологии выбирают по числу специалистов.
Узкий спец быстрее вольётся?
Но даже найдя разработчика, например, "на React", важно иметь ввиду, что это великое знание - на самом деле капля в море необходимого для разработки именно вашего проекта. И чем ниже уровень этой технологи, тем меньше эта капля, и тем больше надо знать вещей за её пределами. Тот же React - это просто разросшийся XML-шаблонизатор.
Отсюда вывод: лучше нанимать талантливых и опытных людей, ведь они быстро разберутся в вашем проекте и смогут его улучшить, даже если изначально и не знакомы с той технологией, которая лучше всего подошла проекту по техническим соображениям.
Что должны делать программисты?
Объяснить бизнесу последствия выбранных решений.
Провести анализ существующих коробок.
Обосновать написание своей, если остальные не годятся.
Но это долго, сложно и порой безрезультатно. Так, например, однажды меня хантили в стартап на роль техдира, чтобы я возглавил их разработку, построил архитектуру, собрал команду и вот это всё. Но наше партнёрство сорвалось с буквально такими словами: "ты просто самый звёздный кандидат, идеально нам подходишь, но мы решили делать проект на Реакт". То есть человек был готов доверить мне технический успех проекта, но не был готов доверить выбор.. шаблонизатора? Серьёзно?
Что программисты реально делают?
Программисты - люди умные и ленивые, так что они быстро смекнули лайфхак..
Берут низкоуровневую библиотеку.
Называют её UI-фреймворком.
Спокойно пилят свои велосипеды поверх.
На другом проекте как раз пилили свой MVC конструктор интерфейсов "на Реакт", где последний отвечал за отображение, которое через MobX реагировало на модель.
Так я и не понял, зачем там, собственно, нужен был Реакт, ведь через тот же MobX легко делать точечный рендеринг безо всякого Virtual DOM. Не говоря уж о том, что ещё проще, быстрее и дешевле было бы взять, высокоуровневый $mol, и за пару месяцев допилить его под свои нужды, а не решать несколько лет детские болезни в своём велосипеде.
Но, как мне не раз заявляли, "использовать не распиаренные технологии - большой финансовый и продуктовый риск".
Бизнес правда этого ждёт?
Каждый проект имеет уникальную архитектуру.
Одни и те же детские болезни в каждом проекте.
Программисты вовсе не взаимозаменяемы.
Каждый год всё переписывается под веяния моды.
Медленная разработка с отрицательным ускорением.
Прогрессирующее увеличение команд для сохранения темпа.
Вот и получается, что бизнес теряет время и деньги, пока программисты развлекаются велосипедостроением, тычась как слепые котята из стороны в сторону: вчера были классовые компоненты, сегодня - функциональные; вчера всё заворачивали в HOC-и, сегодня - внедряют Hook-и; вчера хранили состояние в MobX, сегодня - в Redux. И это всё ещё "на React".
И ладно бы новые веяния были существенно лучше. Но зачастую я вижу, как одно кривое решение меняют на.. ещё более кривое. И так каждый год под давлением хайпа меняют шило на мыло, мыло на верёвку, верёвку на гвоздь в крышку проекта.
Пользователь правда доволен?
Приложение долго грузится.
Интерфейс дико тормозит.
Аккумулятор быстро садится.
Память утекает в трубу.
Хоть за все эти наши развлечения и платит в итоге конечный пользователь, но взамен мы ему даже не можем предоставить должный уровень сервиса.
Так, например, недавно я столкнулся с Самокатом. Это food-tech стартап такой. За кучу денег наняли толпу программистов. Они взяли всё самое модное: React в качестве "кроссплатформеннго фреймворка"; ReactNative, чтобы летало на мобилках; GraphQL для эффективного общения с сервером; MobX для хранения состояния. Не знаю как последний сюда затесался. Думаю скоро на Effector перепишут, а то MobX уже выходит из моды.
И вот, открываю я их сайт, чтобы потратить купон, а через веб у них только лендинг - извольте ставить приложение. Вот тебе и "веб-фреймворк". Руки ещё не дошли, наверно, веб-фреймворк в вебе завести. Ладно, ставим приложение и.. ждём пол минуты пока оно просто запустится. Вот тебе и GraphQL, позволяющий все нужные данные вытянуть одним запросом. Тыкаем по кнопкам, а реакция от приложения поступает лишь через пару секунд с красивой.. лагающей анимацией. Вот тебе и ReactNative с рендерингом в отдельном потоке.
У меня, конечно, не последний айфон на Apple M1 Max, но реально, этот результат 4 лет разработки, чтобы показать каталог на пару десятков товаров, - никуда не годится. То чувство, когда накосячили другие, а стыдно мне. Ведь я тоже из этих, из фронтендеров. Но как пользователь я плачу всё больше и больше, ибо кейс Самоката не единичный, а тенденция.
Мы же видим эти проблемы?
Мы, программисты, уже настолько заврались, что обманываем не только бизнес, но и своих коллег, и даже самих себя. Вы только гляньте пресс-релизы от больших компаний, где они хвастаются, как хорошо оптимизировали свои приложения..
Типичный комментарий из первых же: стало медленнее, меньше функциональности, больше багов и больше потребление памяти. Ну, зато кто-то получил зарплату, и скорее всего даже премию.
Бизнес же это устраивает?
Это только в теории бизнес максимизирует доходы и минимизирует расходы. Если бы он знал, как мы транжирим бабки, он бы нас всех поувольнял. Но он ничего в этом не понимает, оценить долгосрочные финансовые последствия технических решений не способен. Так что всё, что ему остаётся, - нанимать всё больше людей.
Нет экспертизы, чтобы понять неоптимальность.
Плохие технические решения заливаются деньгами.
Однажды я работал в Райке, где мы пилили проект на JavaScript + ExtJS + собственные велосипеды. Только-только отвязали его от JSP. И тут приходит к нам новый разработчик, который очень хочет попробовать язык Dart от Google в деле. Долго ходил он обедать с техдиром, пока таки не убедил его прыгнуть в этот омут с головой.
Причём главный аргумент был, вы только не смейтесь, что в JavaScript (и как следствие в TypeScript) много разных библиотек разного качества, и приходится выбирать, а для Dart есть лишь прекрасная стандартная библиотека от Гугла, и выбирать больше не из чего.
Эта авантюра обернулась в превращение проекта в лоскутное одеяло с бандлами на десятки мегабайт. За 8 лет они вложили кучу средств в продвижение Dart, найм кучи программистов и их переобучение, перепробовали сырой Dart, PolymerDart, AngularDart, Dart + OverReact, и, наконец, пришли к TypeScript + React. На моей практике это выдался самый дорогой эксперимент, выбросивший миллионы долларов в трубу с получением в итоге тонн легаси кода, которые неизбежно придётся снова переписывать.
Как мы до этого докатились?
IT индустрия (и особенно фронтенд) растёт гораздо быстрее, чем появляются и набираются опыта таланты. Это приводит к тому, что технические решения с далеко идущими последствиями часто принимаются не профессионалами. Выбор кривых технологий приводит к большим накладным расходам, что вынуждает раздувать штат под этими непрофессионалами. В результате мы получаем людей с сомнительным опытом у руля больших кораблей. И они рулят не в светлое будущее, а куда попало.
Решения принимают люди с узким кругозором или без технического бэкграунда.
Технологии выбирают "по звёздочкам", а не по технической целесообразности.
Что же с этим всем делать?
Простого ответа у меня нет, поэтому я приглашаю вас к дискуссии. Отмечу, однако, несколько своих соображений.
В IT сильный дефицит кадров, а хороших кадров - острый дефицит. Поэтому наивно надеяться на быстрый найм, а стоит вкладываться в повышение эффективности работы существующих разработчиков. А это не только и не столько обучение. Куда важнее выбор и создание более эффективных инструментов.
Вкладываясь в инновации, в долгосрочной перспективе мы получаем конкурентное преимущество. Но тут важно не просто бежать за хайпом и пилить очередной никому не нужный кривой велосипед. А важно трезво и объективно оценивать не только технические, но и бизнес последствия технических решений. А для этого нам нужно формировать культуру технического анализа:
Перед реализацией новой фичи, составляется документ с описанием вариантов решений, анализом их сильных и слабых сторон, и обоснованием выбора одного из них. После чего проводится ревью, где другие разработчики помогают улучшить анализ, если автор что-то не учёл. И только после всего этого начинается собственно написание кода. Примеры можно найти на $mol вики.
Можно назвать это "разработкой через анализ", по аналогии с модной сейчас "разработкой через тестирование". Раньше на предложение написать тесты менеджер отвечал нам, что "сроки горят, давай потом". А потом так и не наступало, код без тестов было сложно поддерживать, а тот же менеджер приходил с претензией "почему на перекрасить кнопочку нужно 2 месяца?!?" и слушать не хотел о том, что это последствия его недальновидного решения.
Теперь же мы уже договорились и не спрашиваем про тесты, а сразу их пишем, так как все понимают, что это неотъемлемая часть разработки - понимать, что всё работает так, как задумано. Так же и анализ должен стать неотъемлемой частью разработки, чтобы мы понимали, что задумано было в наилучшем виде, и мы не потратим время зря. За всю мою двадцатилетнюю карьеру лишь в одной компании я наблюдал такую практику. И это была, внезапно, в 1С. Но хотелось бы видеть это везде.
Один Бык >> семеро бычат!
На велосипедах тандемом с бизнесом!
Но сперва хорошо подумай!
Да кто мы такие?
Как говорил один мой коллега: ты начальник - я дурак; я начальник - ты дурак.
Но позвольте напомнить вам, что вы не рабы, а интеллектуальная элита современности. Вы создаёте новые информационные миры и только вы имеете квалификацию и талант определять, как они будут работать.
Так что поднимите голову. Расправьте плечи. Честно и прямо объясните бизнесу, что это не он покупает вас как программеров лёгкого поведения, а это вы даёте ему возможность вложить в вас свои средства, чтобы заработать гораздо больше.
Но для этого он должен хотя бы не мешать вам делать своё дело хорошо. И речь не про "клац-клац и в продакшен", а про создание миров с непротиворечивой логикой, автоматизацией рутины и инновациями, двигающими индустрию по пути прогресса.
Что ещё интересного расскажешь?
habhub.hyoo.ru - мои статьи
nin-jin/slides - мои выступления
Core Dump - видео о фундаментальном
mol_news - новости гильдии гипер-дев
nin_jin - связь со мной
Ответочка
🤩 Хороший доклад, подняты интересные проблемы
😊 Чувствуется фундаментальный подход. Но на мой взгляд, доклад был несколько про другое. Как мне показалась, скорее про проблемы в АйТи.
😊 с $mol мы бы вообще эту конференцию закрыли бы
😊 Отличная идея, удачи в продвижении и развитии! Все дурят бизнес, не только программисты :)
😐 Прочитав тему доклада, ожидал другого содержания. Но фактическое содержание доклада было интересным
😒 Так и не выкупил поинта докладчика. Кликбейт, который отвлек от других докладов.
😒 Название кликбейтное, подача монотонная, по факту какой-то пиар собственной технологии вышел, а не глубокое рассуждение на заявленную тему.
😠 Какой-то сюр, я вообще не понял о чем доклад
