Абстракции над этим всем, слава богу, придумали разработчики языков программирования, виртуальных машин, библиотек и прочие умные люди, которым это все очень интересно. А мне интересно бизнес-задачи решать. Еще раз повторю: я неплохо знаю, как все устроено) И свой язык программирования в универе делал и Таненбаума читал, так что не пойму при чем здесь ребенок\не ребенок. При этом я еще раз повторяю, что эти знания в работе были не более полезны, чем аэродинамика. Даже более страшную вещь скажу, для того, чтобы быть бэкенд-разработчиком сегодня, чаще всего не обязательно даже знать как работает TCP/IP, достаточно понимания HTTP. Вы вот используете буквы и слова, предложения складываете, а понимаете при этом что такое фонемы и морфемы? Похоже на позицию ребенка, знаете ли. Или вот вы чай завариваете, а понимаете ли все химические и физические процессы, которые при этом происходят? А вы уверены?
Абстракции для того и нужны, что бы для того, чтобы писать на любимом питухончике не нужно было уметь в уме переводить питон в ассемблер, а ассемблер в машинный код, понимаете о чем я? Я перекладываю JSON из запроса в базу данных и отдаю какой-то другой JSON в ответе. Похеру мне на планировщик операционный системы на работе, честно! Это я говорю при том, что я интересовался тем, как все и работает и книжки читал, но эта информация была полезна мне в работе не больше, чем знание аэродинамики.
добавление новых фич - это тоже "изменение существующего кода", как и удаление устаревших фич.
Все верно, с этим никто не спорит, тезис про time-to-market это никак не отменяет. Нас одинково интересует time-to-market как изменения старых фич, так и добавления новых, так и удаления) Это очевидно.
Я давно в IT и наблюдал эволюцию подхода к кодированию своими глазами. Начиная от "программа должна правильно выполнять свою задачу" (write), через "программа также должна быть ещё и понятна" (read) и до "программа, до кучи, должна быть ещё и легко изменяемой" (modify).
Хорошо, но как игнорирование тестов в определенной ситуации, или, например, непрохождение code-review улучшает показатели write/read/modify?
Потому что главной задачей разработчика ПО является как раз таки поддержание кодовой базы в актуальном состоянии, чтобы она могла продолжать решать задачи бизнеса
Абсолютно верно. Но упущена КРИТИЧЕСКАЯ деталь. Бизнес бывает разный. Это не единая сущность. И у разного бизнеса мало того, что есть разные потребности, бывают еще и разные стадии жизненного цикла. Невероятно странно было бы использовать теже подходы, что используются при разработке банковского ПО для создания лендинга сельского цветочного магазина, не так ли?
Не просто создать приложение "согласно ТЗ" и свалить в закат, а дать инструмент, способный эффективно работать в изменяющейся среде
Тут все верно, но опять же нужно уточнить, что понятие "эффективно" для каждой бизнес-задачи будет свое. У всех будут свои метрики. Именно из-за этого уточнения ломается следующая часть утверждения.
продолжительное время, и поддерживать этот инструмент в актуальном состоянии.
Далеко не всему бизнесу нужна поддержка ПРОДОЛЖИТЕЛЬНОЕ время. В качестве самого яркого примера я приведу стартап. Вот вы с другом сели и придумали классную идею проекта. Какой бы классной она ни была, с вероятностью примерно в 95% она никому кроме вас с другом нахер не нужна. На этом этапе ваша бизнес-задача не состоит в том, чтобы создать легко поддерживаемый продукт с высоким качеством кода. Почему? Потому что это существенно удорожает разработку именно на ранних стадиях проекта. А у вас нет еще ни одного клиента, прибыли и вы не знаете, сможете ли вообще отбить свои затраты на разработку. Оверинжиниринг на этом этапе - крайне распространенная причина провала проекта вообще. Многие просто даже до рынка не доходят.
При всем при этом, есть компания, ну, скажем Ericson, которая поставляет в том числе софт для вышек сотовой связи с каких-то бородатых годов, когда еще JavaScript даже в зародыше не было. Очевидно, что в такой корпорации для того софта, подходы к разработке должны быть совершенно иные. И там как раз нельзя делать все то, о чем тут пишет автор. Там надо именно что СТРОГО придерживаться принятых стандартов.
Автор поста не побоялся привнести свет в массы и заслуженно получил минусов, потому что массы не любят, когда их просвещают ;)
По причинам, которые я описал выше, я поставил автору минус. Автор посчитал, что суть программирования не в том, что приносить пользу бизнесу исходя из задач, потребностей и жизненного цикла бизнеса, а в какой-то его субъективной красоте кода.
Для меня это примерно как если бы психолог на сеансе мне сказал, что суть психологии не в том, чтобы помочь клиенту, а в том, что бы за его деньги убедить его в своих(психолога) представлениях о жизни.
Это заблуждение. Хорший код может заменить ЧАСТЬ документации. Тольку ту, которая предназначена непосредственно для разработчиков. А это далеко не ВСЯ документация. Не говоря уж о том, что лазить по условному файлу routes.php вместо того, чтобы открыть привычный Swagger - такое себе удовольствие. А это пример именно разработческой документации, которую по вашему может заменить код. Может. И из буханки хлеба трамвай можно сделать, да, но зачем?
Вы пытаетесь опровергнуть мой тезис о том, что тесты и документации в крупной корпорации должны быть везде словами:
> Всякие канареечные релизы (тест на проде), автотесты препрода и т.д. снижают риски
ТАК Я ЖЕ ОБ ЭТОМ И ГОВОРЮ!! Снижают риски вводя девопс подход, при котором НЕЛЬЗЯ мержить ветку без код ревью. Снижают риски написанием тестов и не только модульных, а еще и функциональных, интеграционных и всяких других) Корпорации не снижат количество стандартов и бюрократии, а как раз таки повышают. Даже по вашим же словам комментом выше)
Вот с годами развития IT-индустрии, выяснилось, что в проектах с большой историей и большим количеством разработчиков эти "риски" выстреливают часто. По этой причине и придуманы все эти практики вроде document first, TDD, CI\CD, code review и прочее. Неужели так сложна мысль о том, что все это придумали не потому что работы было маловато, а как раз наоборот?)
Программа это некий исполняемый файл. Что значит исполняемый файл? То, что он содержит набор инструкций, который может быть выполнен компьютером. Должен ли этот набор инструкций быть понятень человеку? Нет! В моем понимании машинный код не является кодом в том смысле, в котором идет рассуждение в статье. Его уж точно нельзя назвать ни легко изменяемым, ни легко читаемым.
Бизнес не интересует и не должен интересовать КОД вообще ни в каком виде. И про изменяемость вы подменяете понятия. Бизнесу пофигу насколько легко изменять код, его интересует, насколько программа может быстро и легко адаптироваться к новым бизнес-требованиям. Программма может адаптироваться к новым бизнес-требованиям без измнения в коде. Код никого, кроме непосредственно программиста вообще не интересует. Если завтра придумают инструмент, где ты не пишешь код, а рисуешь блок-схемы в Figma и из этого получаешь рабочие программы, все внезапно перейдут на такой инструмент - то и программисты про код забудут.
Нет. Вот есть сервис. Его считали "маленьким и неважным". Допустим, он получал прогноз погоды(придумайте другой пример, это неважно), чтобы показать его в кабинете клиента. Вот вы сделали компонент и забыли. И все работало 2 года. Документацию вы решили не писать, тестами решили не покрывать, да и вообще на все забили, сделали "чтобы работало". И вот сейчас оно сломалось. Отсутствие тестов и документации определенно стало техническим долгом, который теперь имеет свое воплощение во времени работы программистов и деньгах компании.
Технический долг это про "снизить стоимость сейчас" и "заплатить потом". Это он и есть.
По той же причине, почему в каждом макдональдсе должны быть одинаковые граммовки, форма и бизнес-процессы. Это называется стандарты. Когда любая группа людей вырастает до определенного масштаба стандарты просто необходимы. Типичный enterprise-проект - банковская система. Ядро написано на Java в 2004 году. Какие-то части переписали на новые версии языка, какие-то нет, сама система обросла дополнительными сервисами на PHP, потом появились сервисы на NodeJS, появились консумеры АПИ, находящиеся вне компании. Система становится все сложнее и сложнее и вот ее поддерживает уже 400 программистов. Если в таких системах начинаешь отходить от стандартов хоть на шаг, то все неизбежно и очень быстро приходит в хаос. Сегодня вам всем дружно очевидно "что и как делает эта штука", а через 5 лет команда сменилась целиком уже несколько раз. А документации нет. А ведь было очевидно. И вот вы тратите кучу времени и денег просто чтобы понять что это вообще такое. Да и каждый член команды тот же час начнет трактовать почти все случаи как "это не супер важно" или "это же очевидно", "да я тут только одну строчку поменял, ревью можно не делать". Единственное исключение - когда вы пишите стандарт на то, в каких случаях можно и нужно отходить от стандартов. И то каждый будет интерпретировать все по-своему. Это обычная проблема в любых проектах на которых работает много людей, не только программирование. Одно дело построить дачу и совершенно другое строить Бурдж-Халифа. Да, иногда при причесывании всех под одну гребенку бывает так, что самым умным приходится отрезать голову, но в случае с кровавым enterprise важнее скорее стабильное качество и прогнозируемость релизов, нежели некая нерегулярная краткосрочная "скорость" за счет технического долга.
Не могу говорить о тех местах, где вы работаете, но почти везде где работал я - существовал процесс постановки и обсуждения задач, смысл которого для разработчика и заключается в том, чтобы узнать все, что необходимо о задаче. Чем выше уровень разработчика, тем важнее для него вопрос: "Зачем эта задача бизнесу". Я, как тимлид и технический директор нередко сталкивался с тем, что более простое и дешевое решение задачи лежит вообще не в плоскости разработки. В современных командах вопросы "зачем", "что", "почему" и "как" решаются, как правило между продакт-менеджером и руководителем разработки. Это что касается небольших команд. Что касается enterprise-разработки, я надеюсь, не нужно объяснять, почему Code-Review должно проходить каждый раз, почему нужно докапываться до мелочей и вкусовщины, почему нужно документировать даже очевидные узлы и так далее.
Так-то оно так, но в целом советы в духе: "Хорошо быть богатым и здоровым, а быть бедным и больным - плохо". Проблемы возникают не потому, что программистам и менеджерам только дай волю лишнюю работу поделать. Нет, проблема в том, что чаще всего определить что является важным, а что нет крайне сложно. А еще бывает так, что сегодня что-то важно, а уже завтра нет и наоборот.
Ну вот это утверждение, на котором строится вся статья - явно очень спорное. Кому нужен код, который не работает? Кому нужен код, который легко изменять, но не решает свои задачи? Зачем нужно изменять код, который хорошо решает свою задачу? Из неверного посыла сформирована статья.
Вообще посыл о том, что программист это человек, который пишет код, а программирование === написание кода - очень вредно и для вас и для читателя. Это приведет вас в карьерный тупик. Программист должен решать задачи бизнеса, используя для этого, в том числе, разработку ПО. Задача программиста - не КОД. Задача программиста - решение бизнес-задачи. Иногда решение заключается в том, чтобы НЕ ПИСАТЬ КОД вообще.
Хорошо, что написали статью. Полностью согласен. Имею опыт и в крупных компаниях с десятками команд и в быстрорастущих стартапах и в совсем молодых. Польностью согласен с мыслями. Сколько стрел и мечей уже было сломано в спорах с бизнесом и коллегами на эту тему.... Про DDD, конечно, жирненько получилось, если не читать комментарии, можно и не понять мысль
Я много нанимал людей и устраивался на работу сам. В целом со статьей согласен, но на всякий случай продублирую, что все сильно зависит от размера компании. Одно дело, когда тебе надо закрыть 2-3-10 позиций и лид может поговорить с каждым кандидатом "по душам" и другое дело, когда тебе надо закрыть 100 позиций и у тебя тысячи кандидатов. Для меня вопросы на собеседовании являются лакмусовой бумажкой того, какая команда сидит на той стороне, что за компания и какой там менеджмент. Особенно устраиваясь на более менеджерские позиции это становится критически важно. Если меня с более чем 10 летним подтвержденным бэкграундом на позицию CTO просят разливать воду по ведрам неподходящего размера, или объяснять отличия абстрактного класса от интерфейса, мы скорее всего заведомо не подходим друг другу.
Тоже так думал до тех пор пока не оказался в страшной ситуации микроменджмента со стороны некомпетентного руководителя, который к тому же брал на себя непосредственно технические решения(в которых он тоже не понимал) и не прислушивался к тому, что я говорил, что так делать нельзя, не надо и это приведет к еще большим проблемам. И вот, ты уже по 4 часа в день сидишь с ним в зуме, делаешь какую-то лютую дичь. И платят тебе чуть больше, чем на прошлом месте, вот только эмоциональных ресурсов это жрет в 100 раз больше. Протянул 2 года, но когда все-таки ушел - огромная гора свалилась с моих плеч.
Абстракции над этим всем, слава богу, придумали разработчики языков программирования, виртуальных машин, библиотек и прочие умные люди, которым это все очень интересно. А мне интересно бизнес-задачи решать. Еще раз повторю: я неплохо знаю, как все устроено) И свой язык программирования в универе делал и Таненбаума читал, так что не пойму при чем здесь ребенок\не ребенок. При этом я еще раз повторяю, что эти знания в работе были не более полезны, чем аэродинамика. Даже более страшную вещь скажу, для того, чтобы быть бэкенд-разработчиком сегодня, чаще всего не обязательно даже знать как работает TCP/IP, достаточно понимания HTTP.
Вы вот используете буквы и слова, предложения складываете, а понимаете при этом что такое фонемы и морфемы? Похоже на позицию ребенка, знаете ли. Или вот вы чай завариваете, а понимаете ли все химические и физические процессы, которые при этом происходят? А вы уверены?
Абстракции для того и нужны, что бы для того, чтобы писать на любимом питухончике не нужно было уметь в уме переводить питон в ассемблер, а ассемблер в машинный код, понимаете о чем я? Я перекладываю JSON из запроса в базу данных и отдаю какой-то другой JSON в ответе. Похеру мне на планировщик операционный системы на работе, честно!
Это я говорю при том, что я интересовался тем, как все и работает и книжки читал, но эта информация была полезна мне в работе не больше, чем знание аэродинамики.
Все верно, с этим никто не спорит, тезис про time-to-market это никак не отменяет. Нас одинково интересует time-to-market как изменения старых фич, так и добавления новых, так и удаления) Это очевидно.
Хорошо, но как игнорирование тестов в определенной ситуации, или, например, непрохождение code-review улучшает показатели write/read/modify?
Абсолютно верно. Но упущена КРИТИЧЕСКАЯ деталь. Бизнес бывает разный. Это не единая сущность. И у разного бизнеса мало того, что есть разные потребности, бывают еще и разные стадии жизненного цикла. Невероятно странно было бы использовать теже подходы, что используются при разработке банковского ПО для создания лендинга сельского цветочного магазина, не так ли?
Тут все верно, но опять же нужно уточнить, что понятие "эффективно" для каждой бизнес-задачи будет свое. У всех будут свои метрики. Именно из-за этого уточнения ломается следующая часть утверждения.
Далеко не всему бизнесу нужна поддержка ПРОДОЛЖИТЕЛЬНОЕ время. В качестве самого яркого примера я приведу стартап. Вот вы с другом сели и придумали классную идею проекта. Какой бы классной она ни была, с вероятностью примерно в 95% она никому кроме вас с другом нахер не нужна. На этом этапе ваша бизнес-задача не состоит в том, чтобы создать легко поддерживаемый продукт с высоким качеством кода. Почему? Потому что это существенно удорожает разработку именно на ранних стадиях проекта. А у вас нет еще ни одного клиента, прибыли и вы не знаете, сможете ли вообще отбить свои затраты на разработку. Оверинжиниринг на этом этапе - крайне распространенная причина провала проекта вообще. Многие просто даже до рынка не доходят.
При всем при этом, есть компания, ну, скажем Ericson, которая поставляет в том числе софт для вышек сотовой связи с каких-то бородатых годов, когда еще JavaScript даже в зародыше не было. Очевидно, что в такой корпорации для того софта, подходы к разработке должны быть совершенно иные. И там как раз нельзя делать все то, о чем тут пишет автор. Там надо именно что СТРОГО придерживаться принятых стандартов.
По причинам, которые я описал выше, я поставил автору минус. Автор посчитал, что суть программирования не в том, что приносить пользу бизнесу исходя из задач, потребностей и жизненного цикла бизнеса, а в какой-то его субъективной красоте кода.
Для меня это примерно как если бы психолог на сеансе мне сказал, что суть психологии не в том, чтобы помочь клиенту, а в том, что бы за его деньги убедить его в своих(психолога) представлениях о жизни.
Какие фреймворки? Наверное красивые))
Да и хер бы с ним, если с ОС не работаешь) А - абстракции
Или вы? В статье ведь речь не про продукт, а про код. Нужно ли объяснять, что продукт и код это вообще разные вещи?
Это заблуждение. Хорший код может заменить ЧАСТЬ документации. Тольку ту, которая предназначена непосредственно для разработчиков. А это далеко не ВСЯ документация. Не говоря уж о том, что лазить по условному файлу routes.php вместо того, чтобы открыть привычный Swagger - такое себе удовольствие. А это пример именно разработческой документации, которую по вашему может заменить код. Может. И из буханки хлеба трамвай можно сделать, да, но зачем?
Вы пытаетесь опровергнуть мой тезис о том, что тесты и документации в крупной корпорации должны быть везде словами:
> Всякие канареечные релизы (тест на проде), автотесты препрода и т.д. снижают риски
ТАК Я ЖЕ ОБ ЭТОМ И ГОВОРЮ!! Снижают риски вводя девопс подход, при котором НЕЛЬЗЯ мержить ветку без код ревью. Снижают риски написанием тестов и не только модульных, а еще и функциональных, интеграционных и всяких других) Корпорации не снижат количество стандартов и бюрократии, а как раз таки повышают. Даже по вашим же словам комментом выше)
Вот с годами развития IT-индустрии, выяснилось, что в проектах с большой историей и большим количеством разработчиков эти "риски" выстреливают часто. По этой причине и придуманы все эти практики вроде document first, TDD, CI\CD, code review и прочее. Неужели так сложна мысль о том, что все это придумали не потому что работы было маловато, а как раз наоборот?)
Программа это некий исполняемый файл. Что значит исполняемый файл? То, что он содержит набор инструкций, который может быть выполнен компьютером. Должен ли этот набор инструкций быть понятень человеку? Нет! В моем понимании машинный код не является кодом в том смысле, в котором идет рассуждение в статье. Его уж точно нельзя назвать ни легко изменяемым, ни легко читаемым.
Бизнес не интересует и не должен интересовать КОД вообще ни в каком виде. И про изменяемость вы подменяете понятия. Бизнесу пофигу насколько легко изменять код, его интересует, насколько программа может быстро и легко адаптироваться к новым бизнес-требованиям. Программма может адаптироваться к новым бизнес-требованиям без измнения в коде. Код никого, кроме непосредственно программиста вообще не интересует. Если завтра придумают инструмент, где ты не пишешь код, а рисуешь блок-схемы в Figma и из этого получаешь рабочие программы, все внезапно перейдут на такой инструмент - то и программисты про код забудут.
Добавлю, что большинство упавших продов в моей жизни начиналось именно с да я тут только одну строчку поменял, ревью можно не делать
Нет. Вот есть сервис. Его считали "маленьким и неважным". Допустим, он получал прогноз погоды(придумайте другой пример, это неважно), чтобы показать его в кабинете клиента. Вот вы сделали компонент и забыли. И все работало 2 года. Документацию вы решили не писать, тестами решили не покрывать, да и вообще на все забили, сделали "чтобы работало".
И вот сейчас оно сломалось.
Отсутствие тестов и документации определенно стало техническим долгом, который теперь имеет свое воплощение во времени работы программистов и деньгах компании.
Технический долг это про "снизить стоимость сейчас" и "заплатить потом". Это он и есть.
По той же причине, почему в каждом макдональдсе должны быть одинаковые граммовки, форма и бизнес-процессы. Это называется стандарты. Когда любая группа людей вырастает до определенного масштаба стандарты просто необходимы. Типичный enterprise-проект - банковская система. Ядро написано на Java в 2004 году. Какие-то части переписали на новые версии языка, какие-то нет, сама система обросла дополнительными сервисами на PHP, потом появились сервисы на NodeJS, появились консумеры АПИ, находящиеся вне компании. Система становится все сложнее и сложнее и вот ее поддерживает уже 400 программистов. Если в таких системах начинаешь отходить от стандартов хоть на шаг, то все неизбежно и очень быстро приходит в хаос. Сегодня вам всем дружно очевидно "что и как делает эта штука", а через 5 лет команда сменилась целиком уже несколько раз. А документации нет. А ведь было очевидно. И вот вы тратите кучу времени и денег просто чтобы понять что это вообще такое. Да и каждый член команды тот же час начнет трактовать почти все случаи как "это не супер важно" или "это же очевидно", "да я тут только одну строчку поменял, ревью можно не делать". Единственное исключение - когда вы пишите стандарт на то, в каких случаях можно и нужно отходить от стандартов. И то каждый будет интерпретировать все по-своему.
Это обычная проблема в любых проектах на которых работает много людей, не только программирование. Одно дело построить дачу и совершенно другое строить Бурдж-Халифа.
Да, иногда при причесывании всех под одну гребенку бывает так, что самым умным приходится отрезать голову, но в случае с кровавым enterprise важнее скорее стабильное качество и прогнозируемость релизов, нежели некая нерегулярная краткосрочная "скорость" за счет технического долга.
Не могу говорить о тех местах, где вы работаете, но почти везде где работал я - существовал процесс постановки и обсуждения задач, смысл которого для разработчика и заключается в том, чтобы узнать все, что необходимо о задаче. Чем выше уровень разработчика, тем важнее для него вопрос: "Зачем эта задача бизнесу". Я, как тимлид и технический директор нередко сталкивался с тем, что более простое и дешевое решение задачи лежит вообще не в плоскости разработки.
В современных командах вопросы "зачем", "что", "почему" и "как" решаются, как правило между продакт-менеджером и руководителем разработки. Это что касается небольших команд.
Что касается enterprise-разработки, я надеюсь, не нужно объяснять, почему Code-Review должно проходить каждый раз, почему нужно докапываться до мелочей и вкусовщины, почему нужно документировать даже очевидные узлы и так далее.
Так-то оно так, но в целом советы в духе: "Хорошо быть богатым и здоровым, а быть бедным и больным - плохо".
Проблемы возникают не потому, что программистам и менеджерам только дай волю лишнюю работу поделать. Нет, проблема в том, что чаще всего определить что является важным, а что нет крайне сложно. А еще бывает так, что сегодня что-то важно, а уже завтра нет и наоборот.
Ну вот это утверждение, на котором строится вся статья - явно очень спорное. Кому нужен код, который не работает? Кому нужен код, который легко изменять, но не решает свои задачи? Зачем нужно изменять код, который хорошо решает свою задачу? Из неверного посыла сформирована статья.
Вообще посыл о том, что программист это человек, который пишет код, а программирование === написание кода - очень вредно и для вас и для читателя. Это приведет вас в карьерный тупик. Программист должен решать задачи бизнеса, используя для этого, в том числе, разработку ПО. Задача программиста - не КОД. Задача программиста - решение бизнес-задачи. Иногда решение заключается в том, чтобы НЕ ПИСАТЬ КОД вообще.
Я так понял, в 2008
Хорошо, что написали статью. Полностью согласен. Имею опыт и в крупных компаниях с десятками команд и в быстрорастущих стартапах и в совсем молодых. Польностью согласен с мыслями. Сколько стрел и мечей уже было сломано в спорах с бизнесом и коллегами на эту тему.... Про DDD, конечно, жирненько получилось, если не читать комментарии, можно и не понять мысль
Я много нанимал людей и устраивался на работу сам. В целом со статьей согласен, но на всякий случай продублирую, что все сильно зависит от размера компании. Одно дело, когда тебе надо закрыть 2-3-10 позиций и лид может поговорить с каждым кандидатом "по душам" и другое дело, когда тебе надо закрыть 100 позиций и у тебя тысячи кандидатов.
Для меня вопросы на собеседовании являются лакмусовой бумажкой того, какая команда сидит на той стороне, что за компания и какой там менеджмент. Особенно устраиваясь на более менеджерские позиции это становится критически важно.
Если меня с более чем 10 летним подтвержденным бэкграундом на позицию CTO просят разливать воду по ведрам неподходящего размера, или объяснять отличия абстрактного класса от интерфейса, мы скорее всего заведомо не подходим друг другу.
Тоже так думал до тех пор пока не оказался в страшной ситуации микроменджмента со стороны некомпетентного руководителя, который к тому же брал на себя непосредственно технические решения(в которых он тоже не понимал) и не прислушивался к тому, что я говорил, что так делать нельзя, не надо и это приведет к еще большим проблемам.
И вот, ты уже по 4 часа в день сидишь с ним в зуме, делаешь какую-то лютую дичь. И платят тебе чуть больше, чем на прошлом месте, вот только эмоциональных ресурсов это жрет в 100 раз больше. Протянул 2 года, но когда все-таки ушел - огромная гора свалилась с моих плеч.