О работе над продуктом
Почти всю свою карьеру я так или иначе занят в продуктовой разработке. Помимо продуктов я делал собственно демо-проекты и разнообразные прототипы других продуктов.
На старой работе у нас был такой термин "продуктизация". Это когда бралось решение, сделанное кастомного под определенного заказчика, творчески переосмыслялось и впихивалось в продукт. Идея была в том, что эта кастомная функциональность могла бы пригодиться кому-нибудь в будущем. Одной из моих задач, как технического руководителя одного из продуктов, было отбиваться от запросов на такие всякие разные продуктизации. А если уж и брать что-то — то думать, как сделать фичу как можно более универсальной.
Вся эта штука здорово профдеформирует личность. Теперь я не могу просто так взять и закодить что-нибудь жестко под спецификации, даже если понятно что проект одноразовый. Мозг непроизвольно начинает думать как бы сделать решение более гибким, какие сценарии предусмотреть, как бы это все генерализировать так, чтобы потом, когда, может быть, придут за доработкой, то сделать её не из говна и палок а изящно встроить в как раз подготовленное год назад место.
Впрочем, ожидания часто разбиваются о жестокую реальность и оказывается, что предусмотрели далеко не все, и уже в красивую архитектуру нужно добавлять немножко костылей, чтобы новая фича завелась.
С другой стороны, мне кажется, что для инженера это все-таки полезная привычка — продумывать сценарии использования как можно более общими, и строить решение с оглядкой на них. Естественно, везде важен баланс. Когда времени мало, то не до разработки фреймворков, захардкодили, чик чик и в продакшн. Так этот уродец и живет, пока не сменится поколение разработчиков, и новые ребята не сожгут все напалмом, поверху построив как им кажется на этот раз уже хорошее решение. Вот правда ожидает судьба предшественников...
Вот сегодня приехала мне задача увеличить максимальный размер принимаемых определённым API файлов. Раньше ограничения не было, но какие-то ребята додумались слать видео по 50 мегабайт. Сделали ограничение в 10 мегабайт, хардкодом, потому что не было времени (или уже не помню почему). Сегодня оказалось что один из клиентов этого API присылает файлы по 11 мегабайт и здорово было бы лимит увеличить. Можно перехаркодить значение. Можно внести настройку в базу. Но тогда на каждый запрос надо ходить в базу, а это плохо. Значит нужно сверху навернуть кеширование. Хорошо. Но клиентов у API много и разных. Некоторые могут попросить оставить 10 MiB. Делать настройку per-application или per-customer? Если добавлять настройку то нужно добавлять поле в базу для этого клиента. Или записать в json-конфиг его подключения. Но если добавлять в json-конфиг, то нужно добавлять поля в классы(прости Господи) дто, нужно добавлять настройку в админку (которая написана отдельным приложением), добавлять валидацию, устаналивать дефолтное значение, мигрировать существующие конфиги на новые, с добавленным полем, добавлять код чтения настройки уже не из общесистемных настроек, а из конфига подключения...В общем работы на день есть точно.
А начиналось-то все просто, давайте увеличим лимит на 10 мегабайт? Поэтому я перехардкодил существующее значение. Будем проделывать правильную работу в следующий раз, когда потребуется изменение, градуируя улучшения.
Почти всю свою карьеру я так или иначе занят в продуктовой разработке. Помимо продуктов я делал собственно демо-проекты и разнообразные прототипы других продуктов.
На старой работе у нас был такой термин "продуктизация". Это когда бралось решение, сделанное кастомного под определенного заказчика, творчески переосмыслялось и впихивалось в продукт. Идея была в том, что эта кастомная функциональность могла бы пригодиться кому-нибудь в будущем. Одной из моих задач, как технического руководителя одного из продуктов, было отбиваться от запросов на такие всякие разные продуктизации. А если уж и брать что-то — то думать, как сделать фичу как можно более универсальной.
Вся эта штука здорово профдеформирует личность. Теперь я не могу просто так взять и закодить что-нибудь жестко под спецификации, даже если понятно что проект одноразовый. Мозг непроизвольно начинает думать как бы сделать решение более гибким, какие сценарии предусмотреть, как бы это все генерализировать так, чтобы потом, когда, может быть, придут за доработкой, то сделать её не из говна и палок а изящно встроить в как раз подготовленное год назад место.
Впрочем, ожидания часто разбиваются о жестокую реальность и оказывается, что предусмотрели далеко не все, и уже в красивую архитектуру нужно добавлять немножко костылей, чтобы новая фича завелась.
С другой стороны, мне кажется, что для инженера это все-таки полезная привычка — продумывать сценарии использования как можно более общими, и строить решение с оглядкой на них. Естественно, везде важен баланс. Когда времени мало, то не до разработки фреймворков, захардкодили, чик чик и в продакшн. Так этот уродец и живет, пока не сменится поколение разработчиков, и новые ребята не сожгут все напалмом, поверху построив как им кажется на этот раз уже хорошее решение. Вот правда ожидает судьба предшественников...
Вот сегодня приехала мне задача увеличить максимальный размер принимаемых определённым API файлов. Раньше ограничения не было, но какие-то ребята додумались слать видео по 50 мегабайт. Сделали ограничение в 10 мегабайт, хардкодом, потому что не было времени (или уже не помню почему). Сегодня оказалось что один из клиентов этого API присылает файлы по 11 мегабайт и здорово было бы лимит увеличить. Можно перехаркодить значение. Можно внести настройку в базу. Но тогда на каждый запрос надо ходить в базу, а это плохо. Значит нужно сверху навернуть кеширование. Хорошо. Но клиентов у API много и разных. Некоторые могут попросить оставить 10 MiB. Делать настройку per-application или per-customer? Если добавлять настройку то нужно добавлять поле в базу для этого клиента. Или записать в json-конфиг его подключения. Но если добавлять в json-конфиг, то нужно добавлять поля в классы(прости Господи) дто, нужно добавлять настройку в админку (которая написана отдельным приложением), добавлять валидацию, устаналивать дефолтное значение, мигрировать существующие конфиги на новые, с добавленным полем, добавлять код чтения настройки уже не из общесистемных настроек, а из конфига подключения...В общем работы на день есть точно.
А начиналось-то все просто, давайте увеличим лимит на 10 мегабайт? Поэтому я перехардкодил существующее значение. Будем проделывать правильную работу в следующий раз, когда потребуется изменение, градуируя улучшения.
Беспомощность
Обычно у разработчиков не возникает проблем с решением задач. Поисковики, стековерфлоу, куча мануалов, в принципе все типовые задачи уже давным-давно решены, а нетиповые — так их делают опытные люди.
За всю карьеру полностью прочувствовать свою беспомощность и неспособность справиться с задачей меня угораздило только один раз (ну и еще было много других мелких случаев, когда просто задача давалась тяжело, но удавалось как-то разрулить).
Дело было в 2009-2010 году — работал я значит в корпорации, подпиливал свой маленький (тогда) продукт, в ус не дул. Как вдруг решили меня отправить на демо-проект (2-4 недели угарной разработки потемкинских деревень из говна и палок). Я уже на таких проектах бывал, но всегда работал со "своими" компонентами, которые я же поддерживал, или хотя бы знал. Но тут была совсем другая бизнес-область, суть была такова — интегрироваться с Network Discovery какого-то вендора сетевых железяк (Ericcson что ли? не помню), получать от них данные и на основании этих данных заводить у нас в системе карту устройств. Как-то так.
Цимес был в том, что для таких вещей в компании уже давно разработали продукт, и нужно было только его законфигурировать. А конфигурация производилась с помощью написания XSLT-трансформаций, о которых я впервые услышал как раз на этом проекте.
Часть команды поехала к заказчику в штаты, часть осталась в CIS. Из штатов коллега присылал мне задания и тестовые данные, я а пытался что-то из этого сделать. Получалось очень плохо. Среди сотрудников в комнате никто не работал с XSLT, скилл обучения и поиска тогда у меня был не очень хороший, а задания были довольно сложными, то есть hello world примеры не прокатывали. В общем в этот момент я и ощутил невероятную беспомощность, когда не к кому пойти, не у кого спросить, и нет времени обучаться, потому что демонстрации были прибиты гвоздями к определенным датам. Старший коллега, который выдавал задачи (собственно он и сидел в штатах) писал эти трансформации на раз-два, но я или не мог ничего понять из его примеров, или просто смотрел как он переделывал мои xmlины сокращая объем в несколько раз и попутно исправляя кучу багов. Я пытался воззвать к руководству и объяснить им что я ни черта не понимаю в этих штуках и им бы лучше найти толкового специалиста, а то щас все завалим, но был услышан не сразу и страдал пару недель. Щас то я бы наверное как-то на опыте бы выехал, а тогда было совсем плохо. Дему конечно же сделали, правда проект не стартанул.
Спустя годы уже я сам забыл каково это — быть беспомощными и поставил в такое же положение одного из джунов, которые у меня работали — дал ему задачу на распознавание текста на изображениях. Задача оказалась выше его возможностей, о чем он прямо заявлял, но я предлагал еще потыкать и попробовать разные штуки (мануалов в интернете по OCR куча же, чего сложного!). В итоге месяц времени он непостижимым образом выдержал, но удовлетворительного результата, очевидно, мы так и не добились, зато получили демотивированного товарища.
Старайтесь отслеживать такие состояния (только не надо их путать с нежеланием обучаться) и не попадать в них, а так же здраво оценивать возможности своих людей.
Обычно у разработчиков не возникает проблем с решением задач. Поисковики, стековерфлоу, куча мануалов, в принципе все типовые задачи уже давным-давно решены, а нетиповые — так их делают опытные люди.
За всю карьеру полностью прочувствовать свою беспомощность и неспособность справиться с задачей меня угораздило только один раз (ну и еще было много других мелких случаев, когда просто задача давалась тяжело, но удавалось как-то разрулить).
Дело было в 2009-2010 году — работал я значит в корпорации, подпиливал свой маленький (тогда) продукт, в ус не дул. Как вдруг решили меня отправить на демо-проект (2-4 недели угарной разработки потемкинских деревень из говна и палок). Я уже на таких проектах бывал, но всегда работал со "своими" компонентами, которые я же поддерживал, или хотя бы знал. Но тут была совсем другая бизнес-область, суть была такова — интегрироваться с Network Discovery какого-то вендора сетевых железяк (Ericcson что ли? не помню), получать от них данные и на основании этих данных заводить у нас в системе карту устройств. Как-то так.
Цимес был в том, что для таких вещей в компании уже давно разработали продукт, и нужно было только его законфигурировать. А конфигурация производилась с помощью написания XSLT-трансформаций, о которых я впервые услышал как раз на этом проекте.
Часть команды поехала к заказчику в штаты, часть осталась в CIS. Из штатов коллега присылал мне задания и тестовые данные, я а пытался что-то из этого сделать. Получалось очень плохо. Среди сотрудников в комнате никто не работал с XSLT, скилл обучения и поиска тогда у меня был не очень хороший, а задания были довольно сложными, то есть hello world примеры не прокатывали. В общем в этот момент я и ощутил невероятную беспомощность, когда не к кому пойти, не у кого спросить, и нет времени обучаться, потому что демонстрации были прибиты гвоздями к определенным датам. Старший коллега, который выдавал задачи (собственно он и сидел в штатах) писал эти трансформации на раз-два, но я или не мог ничего понять из его примеров, или просто смотрел как он переделывал мои xmlины сокращая объем в несколько раз и попутно исправляя кучу багов. Я пытался воззвать к руководству и объяснить им что я ни черта не понимаю в этих штуках и им бы лучше найти толкового специалиста, а то щас все завалим, но был услышан не сразу и страдал пару недель. Щас то я бы наверное как-то на опыте бы выехал, а тогда было совсем плохо. Дему конечно же сделали, правда проект не стартанул.
Спустя годы уже я сам забыл каково это — быть беспомощными и поставил в такое же положение одного из джунов, которые у меня работали — дал ему задачу на распознавание текста на изображениях. Задача оказалась выше его возможностей, о чем он прямо заявлял, но я предлагал еще потыкать и попробовать разные штуки (мануалов в интернете по OCR куча же, чего сложного!). В итоге месяц времени он непостижимым образом выдержал, но удовлетворительного результата, очевидно, мы так и не добились, зато получили демотивированного товарища.
Старайтесь отслеживать такие состояния (только не надо их путать с нежеланием обучаться) и не попадать в них, а так же здраво оценивать возможности своих людей.
Тьюринг-полные круды
В любой системе, которая имеет дело с реальным миром так или иначе присутствуют куча условий и ветвлений.
Например, нам приходят заказы. От разных контрагентов. Но контрагентов есть множество видов, и заказ каждого отдельного вида обрабатывается по отдельной логике.
Разработчик, задолбавшись реализовывать n-дцатое условие в коде, рано или поздно решает написать некую конфигурацию бизнес-правил обработки этих самых заказов, дать в руки бизнес-людям конфигуратор и свалить в закат. Вроде все просто, реализовал десяток блочков, как-то их собрал в кучку под каждый отдельный случай и все работает, можно пить смузи.
Но бизнес приходит с новыми требованиями. Там, где раньше были только составные условия типа ИЛИ теперь появляются И и НЕ. Там, где была последовательная обработка всех правил по очереди, теперь появляются ветвления и дополнительные условия.
Монстр обрастает кастомными обработчиками, спец-функциями, простым шаблонизатором с переменными... Это все дело нужно как-то поддерживать и дебажить и вот уже появляется расширенная система логирования, вначале для разработчиков, а потом уже и для бизнес-людей, чтобы они сами могли смотреть, почему их штука не работает как надо и не дергать девелоперов.
Ну и апофеозом этого дела будет встраивание скриптового языка (js/groovy и тд) в условия и действия. Цикл замкнулся. Поздравляю, ваш круд теперь тьюринг-полный.
Я наблюдал это и в больших проектах и в маленьких. Рано или поздно хардкода начинает не хватать, и разработка изобретает очередной велосипед, вначале беговел и потихоньку превращая это все дело в мотоцикл из безумного макса.
Готовых отчетов по данным не хватает, и вот аналитикам в руки уже дается база, SQL или BI-система куда разработчики сгружают подготовленные данные.
Множество промежуточных этапов казалось бы можно было бы и избежать, если начать разработку всех этих хитрых движков заранее, на старте проекта, да вот нет. Во-первых, громадный оверкилл, а во-вторых, все равно не угадаете, что понадобится.
В любой системе, которая имеет дело с реальным миром так или иначе присутствуют куча условий и ветвлений.
Например, нам приходят заказы. От разных контрагентов. Но контрагентов есть множество видов, и заказ каждого отдельного вида обрабатывается по отдельной логике.
Разработчик, задолбавшись реализовывать n-дцатое условие в коде, рано или поздно решает написать некую конфигурацию бизнес-правил обработки этих самых заказов, дать в руки бизнес-людям конфигуратор и свалить в закат. Вроде все просто, реализовал десяток блочков, как-то их собрал в кучку под каждый отдельный случай и все работает, можно пить смузи.
Но бизнес приходит с новыми требованиями. Там, где раньше были только составные условия типа ИЛИ теперь появляются И и НЕ. Там, где была последовательная обработка всех правил по очереди, теперь появляются ветвления и дополнительные условия.
Монстр обрастает кастомными обработчиками, спец-функциями, простым шаблонизатором с переменными... Это все дело нужно как-то поддерживать и дебажить и вот уже появляется расширенная система логирования, вначале для разработчиков, а потом уже и для бизнес-людей, чтобы они сами могли смотреть, почему их штука не работает как надо и не дергать девелоперов.
Ну и апофеозом этого дела будет встраивание скриптового языка (js/groovy и тд) в условия и действия. Цикл замкнулся. Поздравляю, ваш круд теперь тьюринг-полный.
Я наблюдал это и в больших проектах и в маленьких. Рано или поздно хардкода начинает не хватать, и разработка изобретает очередной велосипед, вначале беговел и потихоньку превращая это все дело в мотоцикл из безумного макса.
Готовых отчетов по данным не хватает, и вот аналитикам в руки уже дается база, SQL или BI-система куда разработчики сгружают подготовленные данные.
Множество промежуточных этапов казалось бы можно было бы и избежать, если начать разработку всех этих хитрых движков заранее, на старте проекта, да вот нет. Во-первых, громадный оверкилл, а во-вторых, все равно не угадаете, что понадобится.
👍1
Прогресс регресс
Уже несколько лет подряд я ретроспективно оцениваю решения и поступки которые совершал в прошлом году. И каждый раз думаю — "черт, как я мог творить такую дичь? зачем я в это вписывался? зачем соглашался? почему не приложил больше усилий для?".
Что характерно, история повторяется каждый год. То есть вроде бы и думаешь — "ну все, в этот раз такой шляпы не будет", а нет, проходит год и опять понимаешь что делал дичь. Да, не такую, как 5 лет назад, например, но все равно дичь.
И так каждый год.
Где-то читал цитату, типа если ты не считаешь что год назад ты был дураком то ты не прогрессируешь. Может быть, может быть.
Согласно этому утверждению, прогрессировать у меня получается неплохо 😄
p.s. это не про майнинг битка в 2008 или другие околослучайнолотерейные вещи, "знал бы прикуп, жил бы в Сочи", нет. Это больше про осмысленную ежедневную рутину, работу, проекты и так далее.
Уже несколько лет подряд я ретроспективно оцениваю решения и поступки которые совершал в прошлом году. И каждый раз думаю — "черт, как я мог творить такую дичь? зачем я в это вписывался? зачем соглашался? почему не приложил больше усилий для?".
Что характерно, история повторяется каждый год. То есть вроде бы и думаешь — "ну все, в этот раз такой шляпы не будет", а нет, проходит год и опять понимаешь что делал дичь. Да, не такую, как 5 лет назад, например, но все равно дичь.
И так каждый год.
Где-то читал цитату, типа если ты не считаешь что год назад ты был дураком то ты не прогрессируешь. Может быть, может быть.
Согласно этому утверждению, прогрессировать у меня получается неплохо 😄
p.s. это не про майнинг битка в 2008 или другие околослучайнолотерейные вещи, "знал бы прикуп, жил бы в Сочи", нет. Это больше про осмысленную ежедневную рутину, работу, проекты и так далее.
Удаленная работа в офисе
В больших корпорациях часто есть множество офисов, рассосредоточеных по всему миру. В конторе, где я раньше работал, было 2 офиса в Украине, 5+ офисов в РФ и бесчисленное количество команд, которые сидели у заказчика по всем странам и часовым поясам мира.
Из-за большого количества проектов, практически всегда команда собиралась из разных офисов. Очень редко было такое, что все сидели в одной комнате. Но, что интересно, не так редка была ситуация, когда человек был единственным, кто работал на проекте из его окружающих. То есть ты спокойно мог годами вообще никак не пересекаться с коллегами из комнаты, где ты сидишь. В запущеном случае (саппорт например) мало того, что у тебя не было тиммейтов в твоем офисе, так еще и во всем постсовковом регионе.
То есть, на самом деле, это была самая настоящая удаленная работа. Только из офиса. При этом, компания не разрешала работать удаленно из дому (или разрешала но очень-очень ограниченно). Парадокс, да? Твой босс сидит в командировке уже больше полугода, ребята за соседними столами занимаются непонятно чем (или понятно чем, но это тебе фиолетово), но в офис все равно нужно ходить.
Не знаю, насколько часта такая ситуация в других конторах, но тогда мне это здорово рвало шаблон от бессмысленности происходящего.
В больших корпорациях часто есть множество офисов, рассосредоточеных по всему миру. В конторе, где я раньше работал, было 2 офиса в Украине, 5+ офисов в РФ и бесчисленное количество команд, которые сидели у заказчика по всем странам и часовым поясам мира.
Из-за большого количества проектов, практически всегда команда собиралась из разных офисов. Очень редко было такое, что все сидели в одной комнате. Но, что интересно, не так редка была ситуация, когда человек был единственным, кто работал на проекте из его окружающих. То есть ты спокойно мог годами вообще никак не пересекаться с коллегами из комнаты, где ты сидишь. В запущеном случае (саппорт например) мало того, что у тебя не было тиммейтов в твоем офисе, так еще и во всем постсовковом регионе.
То есть, на самом деле, это была самая настоящая удаленная работа. Только из офиса. При этом, компания не разрешала работать удаленно из дому (или разрешала но очень-очень ограниченно). Парадокс, да? Твой босс сидит в командировке уже больше полугода, ребята за соседними столами занимаются непонятно чем (или понятно чем, но это тебе фиолетово), но в офис все равно нужно ходить.
Не знаю, насколько часта такая ситуация в других конторах, но тогда мне это здорово рвало шаблон от бессмысленности происходящего.
Неразглашение зарплаты
Компании часто добавляют в договора пункты о неразглашении зарплат а руководство с HRами еще и грозит анальными карами и санкциями за нарушение этого пункта. В конторе где я раньше работал один из руководителей прямо заявлял — за разглашение зп увольняем сразу. О прецедентах никто не слышал, но все боялись.
Что интересно, в советские времена такого не было — все знали зарплаты друг друга. Социализм во все поля! Приходишь в бухгалтерию, расписываешься в ведомости и там видишь зарплаты всех остальных. Да и вообще тарифная сетка фиксированная, плановая экономика же.
Мне кажется что это не было проблемой в те времена, потому что повышение было получить невозможно за просто так, а только в результате какой-то формальной аттестации. То есть, нельзя было просто так прийти к боссу и сказать "товарищ начальник, я или повышайте мне зп или я ухожу на соседний завод потому что там дают больше". Получается что люди как бы не влияли на свою зарплату, поэтому это воспринималось как непреложный факт. Но, может быть, я и не прав.
Сейчас проблема з разглашениями очевидная — никто не знает как оценивать труд программиста, поэтому работает рынок, а тут уже кто во что себя горазд продать. Соответственно, легко возможны ситуации когда топ перформер получает меньше свеженанятого джуна. Поэтому внутри компании, в коллективе, обсуждение зарплаты табуированное, это в интересах работодателя. Не думаю, что у вас принято обсуждать зарплату даже запрет на это явно не прописан в контракте. Меньше знаешь — крепче спишь. Однако, если есть возможность, например случайно подсмотреть что у кого или узнать сумму налога (по которой, с помощью нехитрых вычислений можно определить базу), то это однозначно стоит сделать. Предупрежден — вооружён.
Обсуждать зп с корешами-девелоперами из других контор вполне себе комильфо и очень даже полезно. По крайней мере, у меня с этим проблем не было. Всякие зарплатные опросы хороши, но нет ничего лучше данных из первых рук. Заодно можно потроллить ребят, которые работают за миску риска.
Ну а людям со стороны, особенно в нашей стране, говорить свою зарплату однозначно не стоит — не поймут. Я несколько раз наивно отвечал на вопрос сколько щас зарабатывают программисты и всегда об этом жалел. Не нужно давать лишний повод для зависти и манипуляций. В последнее время я даже избегаю обсуждать работу и профессию, чтобы не провоцировать лишние расспросы.
Компании часто добавляют в договора пункты о неразглашении зарплат а руководство с HRами еще и грозит анальными карами и санкциями за нарушение этого пункта. В конторе где я раньше работал один из руководителей прямо заявлял — за разглашение зп увольняем сразу. О прецедентах никто не слышал, но все боялись.
Что интересно, в советские времена такого не было — все знали зарплаты друг друга. Социализм во все поля! Приходишь в бухгалтерию, расписываешься в ведомости и там видишь зарплаты всех остальных. Да и вообще тарифная сетка фиксированная, плановая экономика же.
Мне кажется что это не было проблемой в те времена, потому что повышение было получить невозможно за просто так, а только в результате какой-то формальной аттестации. То есть, нельзя было просто так прийти к боссу и сказать "товарищ начальник, я или повышайте мне зп или я ухожу на соседний завод потому что там дают больше". Получается что люди как бы не влияли на свою зарплату, поэтому это воспринималось как непреложный факт. Но, может быть, я и не прав.
Сейчас проблема з разглашениями очевидная — никто не знает как оценивать труд программиста, поэтому работает рынок, а тут уже кто во что себя горазд продать. Соответственно, легко возможны ситуации когда топ перформер получает меньше свеженанятого джуна. Поэтому внутри компании, в коллективе, обсуждение зарплаты табуированное, это в интересах работодателя. Не думаю, что у вас принято обсуждать зарплату даже запрет на это явно не прописан в контракте. Меньше знаешь — крепче спишь. Однако, если есть возможность, например случайно подсмотреть что у кого или узнать сумму налога (по которой, с помощью нехитрых вычислений можно определить базу), то это однозначно стоит сделать. Предупрежден — вооружён.
Обсуждать зп с корешами-девелоперами из других контор вполне себе комильфо и очень даже полезно. По крайней мере, у меня с этим проблем не было. Всякие зарплатные опросы хороши, но нет ничего лучше данных из первых рук. Заодно можно потроллить ребят, которые работают за миску риска.
Ну а людям со стороны, особенно в нашей стране, говорить свою зарплату однозначно не стоит — не поймут. Я несколько раз наивно отвечал на вопрос сколько щас зарабатывают программисты и всегда об этом жалел. Не нужно давать лишний повод для зависти и манипуляций. В последнее время я даже избегаю обсуждать работу и профессию, чтобы не провоцировать лишние расспросы.
Навіщо ходити до офісу
Ось уже два роки я працюю віддалено. В інтернетах купа матеріалів на тему чому віддалена робота це добре, або чому добре фрілансити, як почати і так далі. В осносному там фокусються на перевагах ремоуту.
Можу підтвердити що все що пишуть відповідає дійсності. Не брешуть.
Навіщо ж ходити до офісу?
Істотним недоліком віддаленої роботи з дому для мене є відсутність соціалізації. Людина—тварина соціальна, бачити інших та спілкуватися з ними вживу, а не через інтернет—обов'язково.
Тому раз на два місяці, коли я починаю сумувати за спілкуванням, я йду до офісу та балакаю з колегами. Десь за кілька годин, коли всі важливі питання обговорені, у повний зріст постають недоліки опенспейсу/офісу—в першу чергу шум, розмови довкола, стук каблуків по ламінату, смикання від колег, мітинги , кондиціонер, незручне крісло та стіл, відсутність сонячного світла і так далі. Коли я йду додому то щоразу думаю—„як добре, що завтра вранці не треба буде туди плентатись!“.
Офіс потрібно відвідувати щоб не забувати, що нічого доброго там немає.
На наступні кілька місяців я знову вільний від думок про опенспейс.
Вважаю що якщо регулярно ходити на різноманітні мітапи, зустрічатися з друзями, то потреба в соціалізації буде закрита, але в мене наразі то все якось не виходить. В будь-якому разі, до офісу треба час від часу зазирати щоб переконатися—ти все робиш правильно.
#лайфстайл
permalink | donate
Ось уже два роки я працюю віддалено. В інтернетах купа матеріалів на тему чому віддалена робота це добре, або чому добре фрілансити, як почати і так далі. В осносному там фокусються на перевагах ремоуту.
Можу підтвердити що все що пишуть відповідає дійсності. Не брешуть.
Навіщо ж ходити до офісу?
Істотним недоліком віддаленої роботи з дому для мене є відсутність соціалізації. Людина—тварина соціальна, бачити інших та спілкуватися з ними вживу, а не через інтернет—обов'язково.
Тому раз на два місяці, коли я починаю сумувати за спілкуванням, я йду до офісу та балакаю з колегами. Десь за кілька годин, коли всі важливі питання обговорені, у повний зріст постають недоліки опенспейсу/офісу—в першу чергу шум, розмови довкола, стук каблуків по ламінату, смикання від колег, мітинги , кондиціонер, незручне крісло та стіл, відсутність сонячного світла і так далі. Коли я йду додому то щоразу думаю—„як добре, що завтра вранці не треба буде туди плентатись!“.
Офіс потрібно відвідувати щоб не забувати, що нічого доброго там немає.
На наступні кілька місяців я знову вільний від думок про опенспейс.
Вважаю що якщо регулярно ходити на різноманітні мітапи, зустрічатися з друзями, то потреба в соціалізації буде закрита, але в мене наразі то все якось не виходить. В будь-якому разі, до офісу треба час від часу зазирати щоб переконатися—ти все робиш правильно.
#лайфстайл
permalink | donate
❤🔥1👎1
Слабоумие и отвага
Главный движитель карьерного роста — готовность бесстрашно брать на себя ответственность.
Когда долгое время работаешь простым разработчиком то как-то привыкаешь что все решения принимают за тебя — как делать продукт, какие технологии или стек выбирать, как развивать команду, куда расти тебе лично (менеджеру, ему же точно виднее). В этом мирке очень ценятся люди, которые не очкуют встать и сказать — "вот это сделаем так и так, я готов взяться/возглавить". Когда я только начинал менеджерить и беспокоился о решениях, которые нужно было принимать, то мой босс все время твердил — "лучше предложить хоть какой-то план, даже если он не очень хорош и взять на себя ответственность, нежели вообще ничего не делать". Люди любят когда к ним приходят с набором готовых решений или предложений, а не смотрят в глаза и говорят — "ну, что будем делать?".
Я неоднократно наблюдал некомпетентность менеджеров, но тем не менее их все объединяла уверенность и бесстрашие в принятии решений.
Другой РМ, с которым я довольно долго работал, говорил — "по крайней мере у нас есть план".
Что интересно, несмотря на всю эту мудрость я частенько попадал (и иногда продолжаю попадать) в следующую ситуацию — обнаруживается какая-то техническая проблема, которую в принципе, известно как решать, или понятны первые шаги, но вместо того, чтобы проактивно взяться за эту штуку "босс, вот тут такое дело, нам надо вот это и вот это сделать иначе швах. вот план как мы хотим это делать, вот достоинства, вот недостатки, аппрувишь?" я пускал все на самотек и дожидался пока все не рванет и не дойдет до руководства/заказчиков а дальше реактивно уже решал проблему. Но момент упускал и кредит доверия терял.
Не стоит беспокоиться о том, что ваш план будет неидеальным. Если посмотреть на индустрию, то сотни денег сжигаются из-за плохого планирования, делаются говенные продукты (G+, редизайн гмейла, слак ))), но никого это не волнует. Потому что есть люди, которые берут на себя ответственность за всё это безобразие.
И они — возле руля. Главное — не ссать.
Главный движитель карьерного роста — готовность бесстрашно брать на себя ответственность.
Когда долгое время работаешь простым разработчиком то как-то привыкаешь что все решения принимают за тебя — как делать продукт, какие технологии или стек выбирать, как развивать команду, куда расти тебе лично (менеджеру, ему же точно виднее). В этом мирке очень ценятся люди, которые не очкуют встать и сказать — "вот это сделаем так и так, я готов взяться/возглавить". Когда я только начинал менеджерить и беспокоился о решениях, которые нужно было принимать, то мой босс все время твердил — "лучше предложить хоть какой-то план, даже если он не очень хорош и взять на себя ответственность, нежели вообще ничего не делать". Люди любят когда к ним приходят с набором готовых решений или предложений, а не смотрят в глаза и говорят — "ну, что будем делать?".
Я неоднократно наблюдал некомпетентность менеджеров, но тем не менее их все объединяла уверенность и бесстрашие в принятии решений.
Другой РМ, с которым я довольно долго работал, говорил — "по крайней мере у нас есть план".
Что интересно, несмотря на всю эту мудрость я частенько попадал (и иногда продолжаю попадать) в следующую ситуацию — обнаруживается какая-то техническая проблема, которую в принципе, известно как решать, или понятны первые шаги, но вместо того, чтобы проактивно взяться за эту штуку "босс, вот тут такое дело, нам надо вот это и вот это сделать иначе швах. вот план как мы хотим это делать, вот достоинства, вот недостатки, аппрувишь?" я пускал все на самотек и дожидался пока все не рванет и не дойдет до руководства/заказчиков а дальше реактивно уже решал проблему. Но момент упускал и кредит доверия терял.
Не стоит беспокоиться о том, что ваш план будет неидеальным. Если посмотреть на индустрию, то сотни денег сжигаются из-за плохого планирования, делаются говенные продукты (G+, редизайн гмейла, слак ))), но никого это не волнует. Потому что есть люди, которые берут на себя ответственность за всё это безобразие.
И они — возле руля. Главное — не ссать.
Менеджеры-белки (истерички)
Оставлять гребцов в лодке одних, наедине с океаном нереализованных требований опасно (пойдут не туда), поэтому над разработчиками всегда ставят надсмотрщика-менеджера.
Когда начинается жопа, все горит и ломается, то, как правило, проблему может исправить только вдумчивая и длительная работа соответствующих специалистов. Однако если у инженера есть возможность прямо влиять на ситуацию — разбирать ошибки, читать стековерфлоу и пробовать-пробовать-пробовать починить, или есть в голове примерный план переписывания совсем уже прогнившего участка трубы, то у менеджера такой роскоши нет. Весь жар он должен загребать чужими руками, его для этого и наняли.
Но менеджер не может просто стоять в сторонке, не мешать ценными указаниями и смотреть как тушится пожар — тогда получается что от него вроде бы как ничего и не зависит, а так нельзя. Поэтому, чтобы оправдать свое (жалкое) существование, эти люди начинают изобретать планы, писать отчеты, рисовать графики, собирать заседания и комитеты, заставлять людей овертаймить, ну и самое главное — каждые полчаса спрашивать статус. "Ну что там?", "Ну как?", "Когда починишь?", "Это же просто сделать, почему так долго?". В легкой форме это все сливается в чат, который тут же мьютится, в тяжелой — начинаются звонки в мессенджеры и если совсем тяжко — то на телефон, потом хождение ногами лично, а на команду или человека проецируется повышенный градус истерии и неадеквата.
Их можно понять — если не можешь ничего сделать, то нужно хотя бы быть в курсе. Или давать ценные указания. Неопытный разработчик часто прогибается под такого руководителя и пытается воспринимать его всерьез, товарищи пожестче правильно управляют ожиданиями ("будет завтра, нет, быстрее сделать нельзя, нет, у меня сегодня дела вечером") а особо назойливых просто блокируют или игнорируют.
Особенно печален расклад когда менеджер это просто прокладка между заказчиком и разработчиком, который сам по себе не особо понимает что происходит вообще, но находится под давлением заказчика. Тогда приходится еще и тратить время на правильную коммуникацию и объяснение проблемы, вместо того, чтобы собственно заниматься работой.
Увы, ситуация такая на нашем рынке встречается довольно часто, особенно с гражданами которые пришли извне ІТ а не выросли из разработчиков/тестировщиков/аналитиков.
Оставлять гребцов в лодке одних, наедине с океаном нереализованных требований опасно (пойдут не туда), поэтому над разработчиками всегда ставят надсмотрщика-менеджера.
Когда начинается жопа, все горит и ломается, то, как правило, проблему может исправить только вдумчивая и длительная работа соответствующих специалистов. Однако если у инженера есть возможность прямо влиять на ситуацию — разбирать ошибки, читать стековерфлоу и пробовать-пробовать-пробовать починить, или есть в голове примерный план переписывания совсем уже прогнившего участка трубы, то у менеджера такой роскоши нет. Весь жар он должен загребать чужими руками, его для этого и наняли.
Но менеджер не может просто стоять в сторонке, не мешать ценными указаниями и смотреть как тушится пожар — тогда получается что от него вроде бы как ничего и не зависит, а так нельзя. Поэтому, чтобы оправдать свое (жалкое) существование, эти люди начинают изобретать планы, писать отчеты, рисовать графики, собирать заседания и комитеты, заставлять людей овертаймить, ну и самое главное — каждые полчаса спрашивать статус. "Ну что там?", "Ну как?", "Когда починишь?", "Это же просто сделать, почему так долго?". В легкой форме это все сливается в чат, который тут же мьютится, в тяжелой — начинаются звонки в мессенджеры и если совсем тяжко — то на телефон, потом хождение ногами лично, а на команду или человека проецируется повышенный градус истерии и неадеквата.
Их можно понять — если не можешь ничего сделать, то нужно хотя бы быть в курсе. Или давать ценные указания. Неопытный разработчик часто прогибается под такого руководителя и пытается воспринимать его всерьез, товарищи пожестче правильно управляют ожиданиями ("будет завтра, нет, быстрее сделать нельзя, нет, у меня сегодня дела вечером") а особо назойливых просто блокируют или игнорируют.
Особенно печален расклад когда менеджер это просто прокладка между заказчиком и разработчиком, который сам по себе не особо понимает что происходит вообще, но находится под давлением заказчика. Тогда приходится еще и тратить время на правильную коммуникацию и объяснение проблемы, вместо того, чтобы собственно заниматься работой.
Увы, ситуация такая на нашем рынке встречается довольно часто, особенно с гражданами которые пришли извне ІТ а не выросли из разработчиков/тестировщиков/аналитиков.
Нужно на вчера, давай быстрее
Крайне распространённая манипуляция — "нужно на вчера".
"Нам нужно срочно закрыть вакансию, не могли бы вы выйти пораньше?", "Два дня на подумать", "Багу срочно нужно пофиксить", "Фичу срочно надо выкатывать", "Никто, кроме тебя это не сможет сделать" и так далее.
Так вот, ничего не случится, если человек выйдет на две недели позже. Вы и так уже ищете два месяца подходящего, не подождете еще две недели?
Допустим, я ищу работу. Последнее, что стоит делать — соглашаться на первое предложение и отметать будущие возможные варианты, даже не рассмотрев их. Сколько мне надо будет, столько и буду думать. Если вы ставите меня в неудобные рамки — значит мне с вами не по пути.
Бага и так была месяц как, никто не умер. Пофиксим завтра. Или в понедельник.
Ничего не случится если выкатим фичу не завтра а через неделю. Ну конечно же кроме того, что менеджерку который пообещал большим боссам это сделать придется объяснять причину задержек.
Bus factor равный единице это проблема конкретного босса а не ваша.
Во всех этих случаях люди пытаются перекинуть на вас свои проблемы. Не поддавайтесь. Нужно ценить свое время, свои возможности, свое здоровье. Не ваша проблема, что контора долго не может найти нужных людей. Не ваша проблема, что рекрутер пообещала закрыть вакансию послезавтра. Не ваша проблема что процесс разработки организован так, что нужно овертаймить или тушить пожары. Не ваша проблема в том что менеджерье выставляет нереалистичные сроки а потом пушит команду "ну мы же закоммитились, надо выдавать".
Как я уже говорил (https://xn--r1a.website/full_of_hatred/52), контора и глазом не моргнёт, когда встанет вопрос о сокращениях и прочих пертурбациях связанных с бизнесом и выкинет вас на мороз. Если вы работаете в найме, то можно и нужно платить той же монетой. Ничего страшного не случится. Ну а если вас кикнут с формулировкой "не горят глаза", значит так им и нужно. Пусть ищут лохов, готовых жертвовать собой ради чужих интересов дальше.
Крайне распространённая манипуляция — "нужно на вчера".
"Нам нужно срочно закрыть вакансию, не могли бы вы выйти пораньше?", "Два дня на подумать", "Багу срочно нужно пофиксить", "Фичу срочно надо выкатывать", "Никто, кроме тебя это не сможет сделать" и так далее.
Так вот, ничего не случится, если человек выйдет на две недели позже. Вы и так уже ищете два месяца подходящего, не подождете еще две недели?
Допустим, я ищу работу. Последнее, что стоит делать — соглашаться на первое предложение и отметать будущие возможные варианты, даже не рассмотрев их. Сколько мне надо будет, столько и буду думать. Если вы ставите меня в неудобные рамки — значит мне с вами не по пути.
Бага и так была месяц как, никто не умер. Пофиксим завтра. Или в понедельник.
Ничего не случится если выкатим фичу не завтра а через неделю. Ну конечно же кроме того, что менеджерку который пообещал большим боссам это сделать придется объяснять причину задержек.
Bus factor равный единице это проблема конкретного босса а не ваша.
Во всех этих случаях люди пытаются перекинуть на вас свои проблемы. Не поддавайтесь. Нужно ценить свое время, свои возможности, свое здоровье. Не ваша проблема, что контора долго не может найти нужных людей. Не ваша проблема, что рекрутер пообещала закрыть вакансию послезавтра. Не ваша проблема что процесс разработки организован так, что нужно овертаймить или тушить пожары. Не ваша проблема в том что менеджерье выставляет нереалистичные сроки а потом пушит команду "ну мы же закоммитились, надо выдавать".
Как я уже говорил (https://xn--r1a.website/full_of_hatred/52), контора и глазом не моргнёт, когда встанет вопрос о сокращениях и прочих пертурбациях связанных с бизнесом и выкинет вас на мороз. Если вы работаете в найме, то можно и нужно платить той же монетой. Ничего страшного не случится. Ну а если вас кикнут с формулировкой "не горят глаза", значит так им и нужно. Пусть ищут лохов, готовых жертвовать собой ради чужих интересов дальше.
О сроках 1
Самая большая проблема разработки — сроки.
Бизнес любит ставить сроки (а как работать-то, без них?), разработчики не любят называть сроки, менеджеры любят занижать сроки, а в итоге они всегда продалбываются.
В чем я точно уверен — так это в том, что сроки на длинном временном промежутке планирования (год, а то и меньше) 100% будут сорваны. Даже если не изменятся требования (а они изменятся), не будет смены приоритетов (а они будут), не будет меняться состав команды (а люди будут приходить и уходить), и будут заложены буферы (работа занимает столько времени, сколько на нее отводится). Ни разу еще не видел большого проекта который бы вот запланировали и уложили. Впрочем, может быть, мало видел и такие проекты есть.
Так что если вас нанимают допустим в стартап и говорят что "наша цель — выпустить первую версию продукта через год" — можете смело рассчитывать на тройку лет кропотливого труда до первого релиза. Если вы слышите "через 3 года мы станем лидером в ХХХ" — ожидайте что вообще не станете никогда, или через 10 лет будете середнячками.
Более-менее адекватно работает планирование на коротких участках — пара недель-месяц. Но даже при таких раскладах разработчики ухитряются оптимистично смотреть в конец спринта а под конец опять не укладываться (https://xn--r1a.website/full_of_hatred/94)
Любимый вопрос бизнес-людей — "сколько времени займет сделать (сайт/продукт/фичу)"? На это можно спокойно отвечать: от месяца до бесконечности, в зависимости от пожеланий к качеству 🙂
Без сроков, увы, работать тоже нельзя — людям же нужно знать, когда они смогут пощупать то, что кодерки пытаются слепить по плохо написанным спецификациям...
Для меня сроки являются серьезным источником стресса. Во-первых они висят как дамоклов меч и это напрягает само по себе, а во-вторых, не знаю как кто, а я довольно сильно начинаю беспокоиться и переживать, если чувствую, что не укладываюсь. Иногда это можно обсудить заказчиком и растянуть их, но конкретно у меня часто бывает такое что задачи привязываются к ивентам из реального мира, и подвинуть их ну никак нельзя (например уже отпечатана реклама). Тут уж приходится трайхардить и срезать чтобы хоть как-то уложиться.
Самая большая проблема разработки — сроки.
Бизнес любит ставить сроки (а как работать-то, без них?), разработчики не любят называть сроки, менеджеры любят занижать сроки, а в итоге они всегда продалбываются.
В чем я точно уверен — так это в том, что сроки на длинном временном промежутке планирования (год, а то и меньше) 100% будут сорваны. Даже если не изменятся требования (а они изменятся), не будет смены приоритетов (а они будут), не будет меняться состав команды (а люди будут приходить и уходить), и будут заложены буферы (работа занимает столько времени, сколько на нее отводится). Ни разу еще не видел большого проекта который бы вот запланировали и уложили. Впрочем, может быть, мало видел и такие проекты есть.
Так что если вас нанимают допустим в стартап и говорят что "наша цель — выпустить первую версию продукта через год" — можете смело рассчитывать на тройку лет кропотливого труда до первого релиза. Если вы слышите "через 3 года мы станем лидером в ХХХ" — ожидайте что вообще не станете никогда, или через 10 лет будете середнячками.
Более-менее адекватно работает планирование на коротких участках — пара недель-месяц. Но даже при таких раскладах разработчики ухитряются оптимистично смотреть в конец спринта а под конец опять не укладываться (https://xn--r1a.website/full_of_hatred/94)
Любимый вопрос бизнес-людей — "сколько времени займет сделать (сайт/продукт/фичу)"? На это можно спокойно отвечать: от месяца до бесконечности, в зависимости от пожеланий к качеству 🙂
Без сроков, увы, работать тоже нельзя — людям же нужно знать, когда они смогут пощупать то, что кодерки пытаются слепить по плохо написанным спецификациям...
Для меня сроки являются серьезным источником стресса. Во-первых они висят как дамоклов меч и это напрягает само по себе, а во-вторых, не знаю как кто, а я довольно сильно начинаю беспокоиться и переживать, если чувствую, что не укладываюсь. Иногда это можно обсудить заказчиком и растянуть их, но конкретно у меня часто бывает такое что задачи привязываются к ивентам из реального мира, и подвинуть их ну никак нельзя (например уже отпечатана реклама). Тут уж приходится трайхардить и срезать чтобы хоть как-то уложиться.
О сроках 2
Хорошо работает только планирование рутинных задач. Типа "добавить отчет". Если мы уже делали похожие отчеты, то примерно знаем, сколько на них нужно будет потратить времени, накидываем ±пару дней и спокойно едем. А вот всякие околоисследовательские штуки, или что-то неизвестное можно только ограничивать временем вроде "давайте попробуем потратить 5 дней на исследование а дальше посмотрим". Ну это тоже такое себе планирование, потому что может оказаться что 5 дней мало, дальше берутся еще 5, потом еще, потом еще и вот уже два месяца ушло и только теперь стало ясно куда можно копать дальше.
Когда мне приезжает неизвестная задача то я как правило говорю "давайте мы поковыряем и за пару дней сделаем прототип а дальше будем смотреть". В целом подход работает, но были случаи, когда не получалось сделать вообще (например нам как-то нужно было распознавать текст с кассовых документов, но точность была довольно низкой, как ни старались) или прототип шёл на ура, а на реальных данных работал плохо (хитрое сравнение изображений отлично работало на тестовых фотках которые делал заказчик но быстро обломалось на пользовательских данных).
Ребята из Basecamp в противопоставление спринтам и аджайлу придумали целую философию "работа как гора" (https://m.signalvnoise.com/new-in-basecamp-see-where-projects-really-stand-with-the-hill-chart/). Кто-то занимается тотальным нано-таскингом и бьет скоуп на супер-мелкие задачи по полчаса, кто-то вотерфоллит и рисует диаграммы Гантта которая уже через неделю становится неактуальной. Кто-то работает без сроков 🙂
Но и без сроков тоже сильно можно расслабиться и забивать, особенно если деньги получаешь не за жопочасы в офисе а за выполненные задачи.
Еще для меня хорошо работает схема когда есть реально жесткие дедлайны и надо к ним успеть. Тогда я мобилизуюсь, и ударно батрачу несколько дней пока не будет готово. Но, по моим ощущениям после такого рубилова надо обязательно отдыхать несколько дней, иначе усталость и апатия. Этот подход отлично описал господин Дубаков и мне его модель сейчас кажется самой прикольной (https://medium.com/@mdubakov/94-давайте-пошлём-рабочую-неделю-в-жопу-e71a853e8f35) и походу я по ней в некотором смысле и живу, потому что у меня нет ни фиксированных выходных, ни праздников, а лишь периоды активностей и затишья.
Короче говоря, сроки — не соблюдаются, стресс от них — серьезный, и похоже что никто с этим ничего делать не собирается. Всем 5 дней по 8 часов в офисе, котаны!
Хорошо работает только планирование рутинных задач. Типа "добавить отчет". Если мы уже делали похожие отчеты, то примерно знаем, сколько на них нужно будет потратить времени, накидываем ±пару дней и спокойно едем. А вот всякие околоисследовательские штуки, или что-то неизвестное можно только ограничивать временем вроде "давайте попробуем потратить 5 дней на исследование а дальше посмотрим". Ну это тоже такое себе планирование, потому что может оказаться что 5 дней мало, дальше берутся еще 5, потом еще, потом еще и вот уже два месяца ушло и только теперь стало ясно куда можно копать дальше.
Когда мне приезжает неизвестная задача то я как правило говорю "давайте мы поковыряем и за пару дней сделаем прототип а дальше будем смотреть". В целом подход работает, но были случаи, когда не получалось сделать вообще (например нам как-то нужно было распознавать текст с кассовых документов, но точность была довольно низкой, как ни старались) или прототип шёл на ура, а на реальных данных работал плохо (хитрое сравнение изображений отлично работало на тестовых фотках которые делал заказчик но быстро обломалось на пользовательских данных).
Ребята из Basecamp в противопоставление спринтам и аджайлу придумали целую философию "работа как гора" (https://m.signalvnoise.com/new-in-basecamp-see-where-projects-really-stand-with-the-hill-chart/). Кто-то занимается тотальным нано-таскингом и бьет скоуп на супер-мелкие задачи по полчаса, кто-то вотерфоллит и рисует диаграммы Гантта которая уже через неделю становится неактуальной. Кто-то работает без сроков 🙂
Но и без сроков тоже сильно можно расслабиться и забивать, особенно если деньги получаешь не за жопочасы в офисе а за выполненные задачи.
Еще для меня хорошо работает схема когда есть реально жесткие дедлайны и надо к ним успеть. Тогда я мобилизуюсь, и ударно батрачу несколько дней пока не будет готово. Но, по моим ощущениям после такого рубилова надо обязательно отдыхать несколько дней, иначе усталость и апатия. Этот подход отлично описал господин Дубаков и мне его модель сейчас кажется самой прикольной (https://medium.com/@mdubakov/94-давайте-пошлём-рабочую-неделю-в-жопу-e71a853e8f35) и походу я по ней в некотором смысле и живу, потому что у меня нет ни фиксированных выходных, ни праздников, а лишь периоды активностей и затишья.
Короче говоря, сроки — не соблюдаются, стресс от них — серьезный, и похоже что никто с этим ничего делать не собирается. Всем 5 дней по 8 часов в офисе, котаны!
О рекрутерах-посредниках
Давно не было нытья о рекрутерах!
Все знают что на рынке есть рекрутинговые агенства. Типа мы вам подберем лучшего кандидата, овер 9000 лет экспертизы и все такое.
Такие конторы конечно же очень даже нужны всяким стартапам или компаниям, которые только заходят на рынок, вообще не имеют команды, или пока что не обзавелись внутренним рекрутером, а так же полезны для найма C-level людей и закрытия всяких экзотических вакансий.
Но вот что меня всегда забавляло — так это рекрутеры из агенств, которые перепродают тебе вакансию условного Люксофта или другого крупного игрока. То есть приходят такие и говорят — "привет братишка, у Люксофта вот есть вакансия, не хо поработать?". При том, что эта же вакансия как бы открыто висит на сайте этого самого Люксофта. Дальше происходит следующее — они просят поговорить по скайпу чтобы спросить стандартные вещи типа сколько денег хочешь, когда выходишь и почему уходишь и дальше передают эту инфу в собственноручно структурированном виде в Люксофт. Люксофт смотрит на их выводы (на самом деле нет), смотрит на CV и зовет к себе, чтобы опять провести точно такое же рекрутерское собеседование после чего передать технарям.
Рекрутеры из агенств, естественно, не имеют доступа к CRM компаний, поэтому не могут знать, что вы уже были в конторе, куда они вас зовут, а в случае вакансий у крупных контор, естественно, вы скорее всего там уже были, и возникает раздражение от того, что вас бомбят одинаковыми предложениями так, как будто вы их видите в первый раз.
Я понимаю, какую ценность дают такие рекрутеры компании-нанимателю — дополнительный пул кандидатов. Но какой толк от этого кандидату? Тратить время на общение с посредником, чтобы потом еще раз отвечать на те же вопросы уже непосредственно в компании? Спасибо, не надо. Работа рекрутера заканчивается ровно на этапе передачи вашего CV а дальше он или работает испорченным телефоном или просто ждет пока вас наймут.
Рекрутеры за найм получают хорошие деньги в виде процента от вашей месячной или годовой зарплаты, при этом все что они делают — это пересылают ваше CV (самые старательные форматируют под свой стандарт) в искомую контору. И все. Ничего не напоминает? Правильно, точно такие же граждане сдают или продают вам квартиру и пальцем не пошевелив, но при этом хотят свои 100% от месячной оплаты аренды или 5% от сделки за покупку.
Короче говоря, если ко мне придёт такой рекрутер и я увижу что вакансия висит на сайте конторы, то я из принципа пойду напрямую в контору, и буду просить у них sign-in бонус (который бы они иначе заплатили за найм). Потому что мне не нравится, когда люди получают деньги за настолько бесполезное посредничество.
Еще есть варик когда рекрутер специально под вас шерстит рынок на предмет интересных вакансий (типа риэлтора который бегает по объектам и ищет подходящий вам). Тогда да, ему есть смысл платить, он свои деньги отрабатывает. Но если к вам просто пришел рандомный человек и предлагает поработать в лидере рынка а потом начинаются "вначале нам нужно провести короткое интервью на 30 минут, а потом я передам ваше резюме заказчику" то нет, спасибо. Я сам напишу заказчику, так и для меня и для него будет быстрее и дешевле.
Давно не было нытья о рекрутерах!
Все знают что на рынке есть рекрутинговые агенства. Типа мы вам подберем лучшего кандидата, овер 9000 лет экспертизы и все такое.
Такие конторы конечно же очень даже нужны всяким стартапам или компаниям, которые только заходят на рынок, вообще не имеют команды, или пока что не обзавелись внутренним рекрутером, а так же полезны для найма C-level людей и закрытия всяких экзотических вакансий.
Но вот что меня всегда забавляло — так это рекрутеры из агенств, которые перепродают тебе вакансию условного Люксофта или другого крупного игрока. То есть приходят такие и говорят — "привет братишка, у Люксофта вот есть вакансия, не хо поработать?". При том, что эта же вакансия как бы открыто висит на сайте этого самого Люксофта. Дальше происходит следующее — они просят поговорить по скайпу чтобы спросить стандартные вещи типа сколько денег хочешь, когда выходишь и почему уходишь и дальше передают эту инфу в собственноручно структурированном виде в Люксофт. Люксофт смотрит на их выводы (на самом деле нет), смотрит на CV и зовет к себе, чтобы опять провести точно такое же рекрутерское собеседование после чего передать технарям.
Рекрутеры из агенств, естественно, не имеют доступа к CRM компаний, поэтому не могут знать, что вы уже были в конторе, куда они вас зовут, а в случае вакансий у крупных контор, естественно, вы скорее всего там уже были, и возникает раздражение от того, что вас бомбят одинаковыми предложениями так, как будто вы их видите в первый раз.
Я понимаю, какую ценность дают такие рекрутеры компании-нанимателю — дополнительный пул кандидатов. Но какой толк от этого кандидату? Тратить время на общение с посредником, чтобы потом еще раз отвечать на те же вопросы уже непосредственно в компании? Спасибо, не надо. Работа рекрутера заканчивается ровно на этапе передачи вашего CV а дальше он или работает испорченным телефоном или просто ждет пока вас наймут.
Рекрутеры за найм получают хорошие деньги в виде процента от вашей месячной или годовой зарплаты, при этом все что они делают — это пересылают ваше CV (самые старательные форматируют под свой стандарт) в искомую контору. И все. Ничего не напоминает? Правильно, точно такие же граждане сдают или продают вам квартиру и пальцем не пошевелив, но при этом хотят свои 100% от месячной оплаты аренды или 5% от сделки за покупку.
Короче говоря, если ко мне придёт такой рекрутер и я увижу что вакансия висит на сайте конторы, то я из принципа пойду напрямую в контору, и буду просить у них sign-in бонус (который бы они иначе заплатили за найм). Потому что мне не нравится, когда люди получают деньги за настолько бесполезное посредничество.
Еще есть варик когда рекрутер специально под вас шерстит рынок на предмет интересных вакансий (типа риэлтора который бегает по объектам и ищет подходящий вам). Тогда да, ему есть смысл платить, он свои деньги отрабатывает. Но если к вам просто пришел рандомный человек и предлагает поработать в лидере рынка а потом начинаются "вначале нам нужно провести короткое интервью на 30 минут, а потом я передам ваше резюме заказчику" то нет, спасибо. Я сам напишу заказчику, так и для меня и для него будет быстрее и дешевле.
О срачах в интернетах
Я большой любитель пообщаться. IRL получается не всегда, поэтому время от времени приходится сублимировать в форумы и прочие коменты. За полтора десятка лет я суммарно по всем форумам (кпишные usenet-конференции, разного рода тематические phpBB форумы, доу, хабр, vc и тд) напостил наверное тысяч 20 сообщений, а то и больше.
Дискутировать охота на интересные мне темы, но практически всегда мое мнение идет вразрез с мнением автора/большинства. Завязывается небольшой бокс по переписке, тратится время на поиск аргументов, на цитирование, попытки пробить брешь в стенах защиты оппонента и так далее.
Тем временем, пока мы ведем срачи, другие люди работают работу, выпускают продукты, пишут статьи и снимают видосы, выступают на конференциях. Однако, все эти активности требуют сосредоточенности, тогда как в каментах ничего не стоит написать кг/ам, получить свою микродозу допаминчика и дальше вяло отстреливаться. Люди, которые пишут статьи и выпускают продукты, "криэйторы", как правило, никогда не активничают в каментах — мне кажется что у них на это нет времени или они отлично понимают бесполезность дискуссий.
Я заметил, что проявлять излишнюю активность с соц.медиа можно лишь тогда, когда нечем заняться или накопилась усталость. Каждый раз, когда я ввязываюсь в перепалку на форумах, буквально через несколько сообщений я уже начинаю жалеть о том, что вообще решил оставить коммент. Толку от них минимум, так как дискуссия не структурируется и знания не фиксируются в удобоваримом виде, оппонента ты, как правило, не переубедишь, особенно, если это автор, в общем пустая трата времени. Каждый раз я расстраиваюсь от последствий, в основном потому что спешу выплеснуть злобу и агрессию и плохо излагаю свои мысли, вследствие чего оппонент легко меня опрокидывает, а спорить более обстоятельно, фундаментально — лень. Каждый раз обещаю себе прекратить заниматься ерундой и тратить время на что-то более полезное.
Но все равно, спустя некоторое время, увидев интересный или спорный материал, рука сама тянется написать какую-то колкость или разоблачение и история начинается сначала. Никак не могу избавиться от этой вредной привычки.
За долгое время таких срачей я точно понял — собеседника не переубедишь. Если хочешь донести свою мысль или парировать его материал — лучше всего будет написать свой. Хотя оппонент и его приспешники все равно останутся при своих, у тебя тоже появятся свои поклонники и ценители. Вместо переубеждения в деструктивной полемике лучше убеждать в созидательном ключе.
Я большой любитель пообщаться. IRL получается не всегда, поэтому время от времени приходится сублимировать в форумы и прочие коменты. За полтора десятка лет я суммарно по всем форумам (кпишные usenet-конференции, разного рода тематические phpBB форумы, доу, хабр, vc и тд) напостил наверное тысяч 20 сообщений, а то и больше.
Дискутировать охота на интересные мне темы, но практически всегда мое мнение идет вразрез с мнением автора/большинства. Завязывается небольшой бокс по переписке, тратится время на поиск аргументов, на цитирование, попытки пробить брешь в стенах защиты оппонента и так далее.
Тем временем, пока мы ведем срачи, другие люди работают работу, выпускают продукты, пишут статьи и снимают видосы, выступают на конференциях. Однако, все эти активности требуют сосредоточенности, тогда как в каментах ничего не стоит написать кг/ам, получить свою микродозу допаминчика и дальше вяло отстреливаться. Люди, которые пишут статьи и выпускают продукты, "криэйторы", как правило, никогда не активничают в каментах — мне кажется что у них на это нет времени или они отлично понимают бесполезность дискуссий.
Я заметил, что проявлять излишнюю активность с соц.медиа можно лишь тогда, когда нечем заняться или накопилась усталость. Каждый раз, когда я ввязываюсь в перепалку на форумах, буквально через несколько сообщений я уже начинаю жалеть о том, что вообще решил оставить коммент. Толку от них минимум, так как дискуссия не структурируется и знания не фиксируются в удобоваримом виде, оппонента ты, как правило, не переубедишь, особенно, если это автор, в общем пустая трата времени. Каждый раз я расстраиваюсь от последствий, в основном потому что спешу выплеснуть злобу и агрессию и плохо излагаю свои мысли, вследствие чего оппонент легко меня опрокидывает, а спорить более обстоятельно, фундаментально — лень. Каждый раз обещаю себе прекратить заниматься ерундой и тратить время на что-то более полезное.
Но все равно, спустя некоторое время, увидев интересный или спорный материал, рука сама тянется написать какую-то колкость или разоблачение и история начинается сначала. Никак не могу избавиться от этой вредной привычки.
За долгое время таких срачей я точно понял — собеседника не переубедишь. Если хочешь донести свою мысль или парировать его материал — лучше всего будет написать свой. Хотя оппонент и его приспешники все равно останутся при своих, у тебя тоже появятся свои поклонники и ценители. Вместо переубеждения в деструктивной полемике лучше убеждать в созидательном ключе.
И еще раз про комменты
Вдобавок к тому, что вместо полемики в комментах стоит писать свои материалы, я бы еще хотел коснуться важной темы — сути комментариев и дискуссий в нашей, пост-советской части интернетов.
По неизвестной мне причине (вероятно, из-за среды, но это не точно), большинство людей и комментаторов на наших просторах токсичны и агрессивны. Редко какое обсуждение обходится без прямых оскорблений и ad hominem, без позиции в стиле "я Д'Артаньян", без пассивной агрессии, троллинга, сортирного юмора и других хорошо знакомых всем штук. Я и сам частенько злоупотребляю этими техниками, а еще люблю специально писать комментарии, которые гарантированно соберут кучу лайков. Кучу лайков отлично собирает негатив приправленный юмором 🙂
Например, типичным первым ответом на вопрос "ноутбук для программиста, но не макбук?" будет "купи макбук, не мучайся )))". Проверено неоднократно, причем это вообще никак не зависит от тематики форума или поста.
На западных форумах такое можно встретить только на слабо модерируемых сабреддитах или 4чане, а у нас такая практика повсеместна.
Буквально вчера на HN был тред про трактора-комбайны с DRM и в комментах появился человек, который работал интерном в конторе-производителе тракторов. Он написал что DRM это вынужденная мера и привел какие-то аргументы. Ему ответил человек и вначале написал что-то вроде "от такого как ты удивительно было бы ожидать другого объяснения". Моментально прилетел модератор и попросил соблюдать community guidelines и быть вежливым. Где тонкая грань между свободой слова и цензурированием? Непонятно. Системы кармы типа хабровской плохо работают потому что люди минусуют не качество комментария, а точку зрения его автора.
Сама суть комментария предполагает короткое взаимодействие — и в нашем обществе это как правило выброс агрессии, бесполезный для адресата и для читателей. Те, кому действительно есть что сказать, придут в личку. Ко мне вот раз в 3 поста кто-то приходит и что-нибудь пишет.
Кроме того, обилие негативных комментариев создает иллюзию того, что ты делаешь плохо, хотя на самом деле, люди которым все понравилось, просто пройдут дальше (самые упоротые напишут "спасибо, классный пост"). Лучшим индикатором интересности поста будет количество просмотров/репостов.
Что с этим всем делать — не знаю 🙂 Надеюсь что со временем общество станет менее агрессивным.
Вдобавок к тому, что вместо полемики в комментах стоит писать свои материалы, я бы еще хотел коснуться важной темы — сути комментариев и дискуссий в нашей, пост-советской части интернетов.
По неизвестной мне причине (вероятно, из-за среды, но это не точно), большинство людей и комментаторов на наших просторах токсичны и агрессивны. Редко какое обсуждение обходится без прямых оскорблений и ad hominem, без позиции в стиле "я Д'Артаньян", без пассивной агрессии, троллинга, сортирного юмора и других хорошо знакомых всем штук. Я и сам частенько злоупотребляю этими техниками, а еще люблю специально писать комментарии, которые гарантированно соберут кучу лайков. Кучу лайков отлично собирает негатив приправленный юмором 🙂
Например, типичным первым ответом на вопрос "ноутбук для программиста, но не макбук?" будет "купи макбук, не мучайся )))". Проверено неоднократно, причем это вообще никак не зависит от тематики форума или поста.
На западных форумах такое можно встретить только на слабо модерируемых сабреддитах или 4чане, а у нас такая практика повсеместна.
Буквально вчера на HN был тред про трактора-комбайны с DRM и в комментах появился человек, который работал интерном в конторе-производителе тракторов. Он написал что DRM это вынужденная мера и привел какие-то аргументы. Ему ответил человек и вначале написал что-то вроде "от такого как ты удивительно было бы ожидать другого объяснения". Моментально прилетел модератор и попросил соблюдать community guidelines и быть вежливым. Где тонкая грань между свободой слова и цензурированием? Непонятно. Системы кармы типа хабровской плохо работают потому что люди минусуют не качество комментария, а точку зрения его автора.
Сама суть комментария предполагает короткое взаимодействие — и в нашем обществе это как правило выброс агрессии, бесполезный для адресата и для читателей. Те, кому действительно есть что сказать, придут в личку. Ко мне вот раз в 3 поста кто-то приходит и что-нибудь пишет.
Кроме того, обилие негативных комментариев создает иллюзию того, что ты делаешь плохо, хотя на самом деле, люди которым все понравилось, просто пройдут дальше (самые упоротые напишут "спасибо, классный пост"). Лучшим индикатором интересности поста будет количество просмотров/репостов.
Что с этим всем делать — не знаю 🙂 Надеюсь что со временем общество станет менее агрессивным.
О конференциях 1
Прошлые два дня посвятил посещению #DevOpsDaysKyiv. Идти решил совершенно спонтанно, увидел пост в канале https://xn--r1a.website/devopsengineer, там был скидос 20%. Хотя темы докладов на первый взгляд меня не зацепили (как я позже узнал, основной поток всегда идет о каких-то околокультурных вещах, не о технике), я подумал что неплохо будет узнать чем люди вообще занимаются сейчас и пообщаться с сообществом.
К своему стыду, за всю свою жизнь я был всего на одной технической конференции — JavaDay 2014. Той конференции мне хватило, чтобы зарядиться микросервисами и нетфликсом по самое немогу, а через полгода уволиться из энтерпрайза и пойти внедрять все, о чем рассказывали, но уже в стартап и с нуля. (К слову, четыре года прошло, а стартап в целом так и продолжает ехать на том, что было заложено мной в 2015). Ретроспективно я бы конечно всю эту микросервисную машинерию ни в коем случае не тащил, а вместо этого нанял бы пяток PHP-программистов, но это отдельная история.
Митап я тоже посещал единственный раз — чувак из lun.ua рассказывал, как они деплоят свои Python приложения. В 2016 тезис "мы собираем деб-пакеты и раскатываем их на bare-metal сервера с помощью SaltStack" звучало крайне странно. Ни тебе докеров шмокеров ни оркестраторов, короче полная дичь. Зато поел пиццы.
Участия в движухе я совершенно никакого не принимал, и, более того, даже не совсем понимал, зачем оно нужно. Практически всегда темы докладов были мне малоинтересны или не связаны с тем, с чем я работал. На JavaDay годами парят одни и те же вещи, да и слушать о новых фичах спринга за свои деньги как-то не очень. Некоторые, интересные мне доклады, я смотрел в записях на ютубе.
Однако, даже одного похода на JavaDay мне хватило, чтобы тогда, в 2014, сделать пару выводов:
- Ходить надо не на тему доклада, а на спикера. Так как все конфы они о публичных выступлениях, то гораздо большее значение имеет личность спикера, нежели то, о чём он рассказывает (конечно, если это релевантно тематике). Несмотря на хорошую тему, можно быстро пожухнуть, если человек тухло рассказывает, не держит контакт с аудиторией, не вставляет шутки-прибаутки, не набрасывает на вентилятор и не владеет прочими ораторскими приёмами. Если вы из java-мира, то вероятно знаете про Баруха, Борисова, Алименкова — это первоклассные спикеры которые даже полную ерунду вроде новых аннотаций в спринге расскажут захватывающе и интересно.
- Неважно, релевантны ли темы докладов тому, что ты делаешь. Технологии развиваются и устаревают с космической скоростью. Netflix стек который я внедрял в 2015 уже в 2017 стал наполовину deprecated а в 2019 вообще почти умер. HackerNews читать это хорошо, но конференция как-то больше расширяет кругозор, потому что живые люди рассказывают как и что они применяют, добавляют больше эмоциональности, и работает это лучше чем просто читать пресс-релизы о свежесделанных фреймворках или туториалы как за 5 минут раскатить 1000 контейнеров.
- Конфы здорово заряжают на какие-то свершения. Ты как-бы заглядываешь за высокий забор своей работы и видишь что делают другие люди, иногда это "вау, а что, так можно было?", иногда "ребята, вы тут все неправильно делаете", но и то и другое полезно для понимания что вообще происходит за пределами уютного мирка.
И вот, выводы сделал, а на конференции ходить не стал 🙂 Продолжение завтра.
Прошлые два дня посвятил посещению #DevOpsDaysKyiv. Идти решил совершенно спонтанно, увидел пост в канале https://xn--r1a.website/devopsengineer, там был скидос 20%. Хотя темы докладов на первый взгляд меня не зацепили (как я позже узнал, основной поток всегда идет о каких-то околокультурных вещах, не о технике), я подумал что неплохо будет узнать чем люди вообще занимаются сейчас и пообщаться с сообществом.
К своему стыду, за всю свою жизнь я был всего на одной технической конференции — JavaDay 2014. Той конференции мне хватило, чтобы зарядиться микросервисами и нетфликсом по самое немогу, а через полгода уволиться из энтерпрайза и пойти внедрять все, о чем рассказывали, но уже в стартап и с нуля. (К слову, четыре года прошло, а стартап в целом так и продолжает ехать на том, что было заложено мной в 2015). Ретроспективно я бы конечно всю эту микросервисную машинерию ни в коем случае не тащил, а вместо этого нанял бы пяток PHP-программистов, но это отдельная история.
Митап я тоже посещал единственный раз — чувак из lun.ua рассказывал, как они деплоят свои Python приложения. В 2016 тезис "мы собираем деб-пакеты и раскатываем их на bare-metal сервера с помощью SaltStack" звучало крайне странно. Ни тебе докеров шмокеров ни оркестраторов, короче полная дичь. Зато поел пиццы.
Участия в движухе я совершенно никакого не принимал, и, более того, даже не совсем понимал, зачем оно нужно. Практически всегда темы докладов были мне малоинтересны или не связаны с тем, с чем я работал. На JavaDay годами парят одни и те же вещи, да и слушать о новых фичах спринга за свои деньги как-то не очень. Некоторые, интересные мне доклады, я смотрел в записях на ютубе.
Однако, даже одного похода на JavaDay мне хватило, чтобы тогда, в 2014, сделать пару выводов:
- Ходить надо не на тему доклада, а на спикера. Так как все конфы они о публичных выступлениях, то гораздо большее значение имеет личность спикера, нежели то, о чём он рассказывает (конечно, если это релевантно тематике). Несмотря на хорошую тему, можно быстро пожухнуть, если человек тухло рассказывает, не держит контакт с аудиторией, не вставляет шутки-прибаутки, не набрасывает на вентилятор и не владеет прочими ораторскими приёмами. Если вы из java-мира, то вероятно знаете про Баруха, Борисова, Алименкова — это первоклассные спикеры которые даже полную ерунду вроде новых аннотаций в спринге расскажут захватывающе и интересно.
- Неважно, релевантны ли темы докладов тому, что ты делаешь. Технологии развиваются и устаревают с космической скоростью. Netflix стек который я внедрял в 2015 уже в 2017 стал наполовину deprecated а в 2019 вообще почти умер. HackerNews читать это хорошо, но конференция как-то больше расширяет кругозор, потому что живые люди рассказывают как и что они применяют, добавляют больше эмоциональности, и работает это лучше чем просто читать пресс-релизы о свежесделанных фреймворках или туториалы как за 5 минут раскатить 1000 контейнеров.
- Конфы здорово заряжают на какие-то свершения. Ты как-бы заглядываешь за высокий забор своей работы и видишь что делают другие люди, иногда это "вау, а что, так можно было?", иногда "ребята, вы тут все неправильно делаете", но и то и другое полезно для понимания что вообще происходит за пределами уютного мирка.
И вот, выводы сделал, а на конференции ходить не стал 🙂 Продолжение завтра.
О конференциях 2. Нетворкинг
Некоторое время назад попал на пост, уже не помню где, о конференциях да митапах, где автор говорит примерно что "ребята, доклады вообще никому не нужны, на конференции нужно ходить ради общения с себе подобными, в этом вся суть™".
Эта, вероятно, очевидная для многих мысль, по какой-то причине мне казалась крайней контринтуитивной, но с тех пор она в меня прочно засела и уже именно с этими намерениями я и собирался на #DevOpsDaysKyiv.
...
Ожидание: встречу кого-то знакомого. Смогу подойти к незнакомым людям и завести разговор.
Реальность: полный зал незнакомых людей, на перерывах стою сам за столиком, пью чай и стесняюсь подойти к живо что-то обсуждающим типам вокруг. Без проблем можно общаться только с рекрутерами на стендах, но толку от них, естественно, немного. Люди друг с другом кучкуются и такое ощущение что все всех знают а я чужой на этом празднике жизни. Pretty depressing.
Благо, все-таки столиков было чуть меньше нежели по одному на человека, поэтому рано или поздно к тебе кто-то присоединится просто потому, что нужно где-то стоять. Таким образом ко мне подошел паренек ну и тут я уже не обломался заговорить первым. Товарищ оказался одним из менеджеров школы 42 в Киеве, а я о них как раз довольно много знал, нашлись общие точки и уже завязался разговор.
Дальше к нам присоединился еще один молодой человек, который оказался автором популярного канала https://xn--r1a.website/devops_deflope. В очередной раз я убедился, насколько тесный мир, потому что он(автор) родом из Приднестровья (узкий "анклав" РФ между Молдовой и Украиной), а у меня там тоже полно родственников, и вообще весь апрель в этом году я протусил в славном городе-герое Тирасполе. Затерли за политоту 🙂
После этого лёд был сломан и стало уже как-то проще общаться с мимокроками. Еще лучше дело пошло после открытых дискуссий часть конференции которая предполагает общение участников на заданную тему. В таких вещах я вообще чувствую себя как рыба в воде и готов часами втирать дичь окружающим, соответственно, можно продолжать неформально общаться с другими активными участниками уже после этого.
Уже вечером, после завершения конференции я снова подошел к ребятам, часть из которых уже были знакомыми. Внезапно, несколько других человек узнали меня как меня как автора канала, где вы все это читаете, а дальше мы небольшой компанией пошли в пузатку (местный общепит) обсуждать все подряд.
В итоге я определил для себя такой алгоритм нетворкинга
1. Каким-то образом получить несколько первых коннекшенов. Пересилить себя и подойти к незнакомцу, присоединиться к группе людей, еще как-то.
2. Через них получить еще больше коннекшенов, потому то часто люди приходят не одни, или встречают своих знакомых.
3. На следующей конференции значительно повышается вероятность встретить знакомые лица и расширять сеть дальше.
4. ...
5. PROFIT!
Еще один вопрос, который мне задали был "а ты ходишь на митапы?". Сейчас у меня уже нет сомнений, почему это нужно делать, даже если тема не очень — на митапах нет такой формальной обстановки как на конференциях, меньше людей и проще создать связи. Дальше цепная реакция приводит к взрывному росту сети и вот ты уже не просто нонейм грустно жующий тортик за столом в одиночку, а один из стаи подобных себе. Ура!
Некоторое время назад попал на пост, уже не помню где, о конференциях да митапах, где автор говорит примерно что "ребята, доклады вообще никому не нужны, на конференции нужно ходить ради общения с себе подобными, в этом вся суть™".
Эта, вероятно, очевидная для многих мысль, по какой-то причине мне казалась крайней контринтуитивной, но с тех пор она в меня прочно засела и уже именно с этими намерениями я и собирался на #DevOpsDaysKyiv.
...
Ожидание: встречу кого-то знакомого. Смогу подойти к незнакомым людям и завести разговор.
Реальность: полный зал незнакомых людей, на перерывах стою сам за столиком, пью чай и стесняюсь подойти к живо что-то обсуждающим типам вокруг. Без проблем можно общаться только с рекрутерами на стендах, но толку от них, естественно, немного. Люди друг с другом кучкуются и такое ощущение что все всех знают а я чужой на этом празднике жизни. Pretty depressing.
Благо, все-таки столиков было чуть меньше нежели по одному на человека, поэтому рано или поздно к тебе кто-то присоединится просто потому, что нужно где-то стоять. Таким образом ко мне подошел паренек ну и тут я уже не обломался заговорить первым. Товарищ оказался одним из менеджеров школы 42 в Киеве, а я о них как раз довольно много знал, нашлись общие точки и уже завязался разговор.
Дальше к нам присоединился еще один молодой человек, который оказался автором популярного канала https://xn--r1a.website/devops_deflope. В очередной раз я убедился, насколько тесный мир, потому что он(автор) родом из Приднестровья (узкий "анклав" РФ между Молдовой и Украиной), а у меня там тоже полно родственников, и вообще весь апрель в этом году я протусил в славном городе-герое Тирасполе. Затерли за политоту 🙂
После этого лёд был сломан и стало уже как-то проще общаться с мимокроками. Еще лучше дело пошло после открытых дискуссий часть конференции которая предполагает общение участников на заданную тему. В таких вещах я вообще чувствую себя как рыба в воде и готов часами втирать дичь окружающим, соответственно, можно продолжать неформально общаться с другими активными участниками уже после этого.
Уже вечером, после завершения конференции я снова подошел к ребятам, часть из которых уже были знакомыми. Внезапно, несколько других человек узнали меня как меня как автора канала, где вы все это читаете, а дальше мы небольшой компанией пошли в пузатку (местный общепит) обсуждать все подряд.
В итоге я определил для себя такой алгоритм нетворкинга
1. Каким-то образом получить несколько первых коннекшенов. Пересилить себя и подойти к незнакомцу, присоединиться к группе людей, еще как-то.
2. Через них получить еще больше коннекшенов, потому то часто люди приходят не одни, или встречают своих знакомых.
3. На следующей конференции значительно повышается вероятность встретить знакомые лица и расширять сеть дальше.
4. ...
5. PROFIT!
Еще один вопрос, который мне задали был "а ты ходишь на митапы?". Сейчас у меня уже нет сомнений, почему это нужно делать, даже если тема не очень — на митапах нет такой формальной обстановки как на конференциях, меньше людей и проще создать связи. Дальше цепная реакция приводит к взрывному росту сети и вот ты уже не просто нонейм грустно жующий тортик за столом в одиночку, а один из стаи подобных себе. Ура!
Telegram
DevOps Deflope News
DevOps Deflope News — выборка новостей и тулинга от инженеров «Фланта». Берём весь информационный поток и пропускаем через фильтр здравого смысла. Ещё пишем подкаст.
Рекламу не размещаем. Для связи @dvpsdflpfdbkbot.
Рекламу не размещаем. Для связи @dvpsdflpfdbkbot.
О конференциях 3. Нытье
Всем конфы хороши, да не только. Немного поноем.
Если конфа околотехническая то скорее всего значимая часть докладчиков будет иностранцами и соответственно доклады будут на английском. Доклады на английском мне не очень нравятся, потому что мозг теряет часть информации во время конвертации. И если воспринимать речь/читать без перевода в голове я уже насобачился, то часть незнакомых оборотов или сжеванные произношением фразы (особенно если докладчик — нативный спікер) парсить получается не всегда и как ни крути невозможно получить так сказать full experience. Впрочем, пока у нас нет нужного количества достойных спикеров чтобы заполнять свои конференции, нужно пользоваться импортозамещением и учиться.
Доклады на английском от русскоговорящих докладчиков перед русскопонимающей аудиторией мне не нравятся вообще совсем. Я понимаю, почему их делают (потренироваться перед выступлением на зарубежной конференции, выложить видео для большей аудитории), но мне это очень не нравится. Словарный запас докладчика как правило значительно ниже нежели у нативных чуваков + добавляются традиционные ошибки + эффект волнения, в сумме это дает более низкую плотность информации как если бы вы смотрели видео с замедлением. Как только докладчик переходит на русский, скорость выплёвывания информации повышается в разы 🙂
Доклады на русском/украинском мне нравятся, даже если автор абьюзит зарубежный іт-жаргон и жонглирует всевозможными эстимейтами, юзер стори и кастомерами.
Теперь перейдем к вопросам.
Самое ужасное что случается во время секции вопросов-ответов это когда спрашивающий говорит "у меня два вопроса, первый это как делаете Х а второй это что вы думаете по поводу Y". Никогда, никогда не задавайте два вопроса подряд. Во-первых докладчик ответит на тот вопрос, который он запомнил (второй) или который показался ему более удобным, во-вторых, это занимает время. Иногда вопрошающий пускается в разглагольствования которые тоже как правило не очень уместны, называет свое имя (кому это интересно?) или компанию где работает, не знает что микрофон нужно держать очень близко (этим многие грешат, но это нужно просто знать), в общем треш и содомия во все поля. Особо упоротые набрасывают на вентилятор, что тоже вредно, потому что воруется время других людей и дискуссия неконструктивна.
Правильный вопрос должен быть так "пасибо за доклад, как вы делаете Х?" и предполагать короткий ответ.
Другая моя предъява касается того что на вопросы-ответы как правило дают 10 минут в конце. Для некоторых докладов, особенно спорных, набрасывающих, этого слишком мало и дискуссия получается однобокой. С другой стороны, неизвестно, сможет ли количество перейти в качество, но вот например Егор Бугаенко всегда половину времени доклада отводит на вопросы и получается довольно интересный формат. Не уверен, что все могут или хотят себе это позволить, но мне прямое взаимодействие с докладчиком очень нравится.
Слайды. Половина докладчиков не умеет делать хорошие слайды. Все или буллиты всовывают, или много текста. Щас пошел тренд гифки вставлять, это тоже очень плохо, потому что отвлекает от доклада (гифку можно вставить, но надо её быстро пролистнуть).
Многие спикеры так же любят поинтровертить и посмотреть в пол. Это конечно совсем тухло, даже если тема доклада интересная.
"Подымите руки кто Х!" — очень часто применяющийся прием, который многие копируют потому что карго-культ (так делают всякие мотивационные спикер) но если он не несет смысловой/функциональной нагрузки, например "подымите руки кто не знает что такое девопс!..отлично, все знают, значит мы можем пропустить эту часть" раздражает.
Профессионала видно издалека — у него мощный голос, он ходит по сцене, взаимодействует с аудиторией, грамотно набрасывает, подымает руки только по делу и не вставляет в презентацию буллиты. Профессионала приятно и интересно слушать, даже если тема так себе. У профессионала можно и нужно учиться.
Всем конфы хороши, да не только. Немного поноем.
Если конфа околотехническая то скорее всего значимая часть докладчиков будет иностранцами и соответственно доклады будут на английском. Доклады на английском мне не очень нравятся, потому что мозг теряет часть информации во время конвертации. И если воспринимать речь/читать без перевода в голове я уже насобачился, то часть незнакомых оборотов или сжеванные произношением фразы (особенно если докладчик — нативный спікер) парсить получается не всегда и как ни крути невозможно получить так сказать full experience. Впрочем, пока у нас нет нужного количества достойных спикеров чтобы заполнять свои конференции, нужно пользоваться импортозамещением и учиться.
Доклады на английском от русскоговорящих докладчиков перед русскопонимающей аудиторией мне не нравятся вообще совсем. Я понимаю, почему их делают (потренироваться перед выступлением на зарубежной конференции, выложить видео для большей аудитории), но мне это очень не нравится. Словарный запас докладчика как правило значительно ниже нежели у нативных чуваков + добавляются традиционные ошибки + эффект волнения, в сумме это дает более низкую плотность информации как если бы вы смотрели видео с замедлением. Как только докладчик переходит на русский, скорость выплёвывания информации повышается в разы 🙂
Доклады на русском/украинском мне нравятся, даже если автор абьюзит зарубежный іт-жаргон и жонглирует всевозможными эстимейтами, юзер стори и кастомерами.
Теперь перейдем к вопросам.
Самое ужасное что случается во время секции вопросов-ответов это когда спрашивающий говорит "у меня два вопроса, первый это как делаете Х а второй это что вы думаете по поводу Y". Никогда, никогда не задавайте два вопроса подряд. Во-первых докладчик ответит на тот вопрос, который он запомнил (второй) или который показался ему более удобным, во-вторых, это занимает время. Иногда вопрошающий пускается в разглагольствования которые тоже как правило не очень уместны, называет свое имя (кому это интересно?) или компанию где работает, не знает что микрофон нужно держать очень близко (этим многие грешат, но это нужно просто знать), в общем треш и содомия во все поля. Особо упоротые набрасывают на вентилятор, что тоже вредно, потому что воруется время других людей и дискуссия неконструктивна.
Правильный вопрос должен быть так "пасибо за доклад, как вы делаете Х?" и предполагать короткий ответ.
Другая моя предъява касается того что на вопросы-ответы как правило дают 10 минут в конце. Для некоторых докладов, особенно спорных, набрасывающих, этого слишком мало и дискуссия получается однобокой. С другой стороны, неизвестно, сможет ли количество перейти в качество, но вот например Егор Бугаенко всегда половину времени доклада отводит на вопросы и получается довольно интересный формат. Не уверен, что все могут или хотят себе это позволить, но мне прямое взаимодействие с докладчиком очень нравится.
Слайды. Половина докладчиков не умеет делать хорошие слайды. Все или буллиты всовывают, или много текста. Щас пошел тренд гифки вставлять, это тоже очень плохо, потому что отвлекает от доклада (гифку можно вставить, но надо её быстро пролистнуть).
Многие спикеры так же любят поинтровертить и посмотреть в пол. Это конечно совсем тухло, даже если тема доклада интересная.
"Подымите руки кто Х!" — очень часто применяющийся прием, который многие копируют потому что карго-культ (так делают всякие мотивационные спикер) но если он не несет смысловой/функциональной нагрузки, например "подымите руки кто не знает что такое девопс!..отлично, все знают, значит мы можем пропустить эту часть" раздражает.
Профессионала видно издалека — у него мощный голос, он ходит по сцене, взаимодействует с аудиторией, грамотно набрасывает, подымает руки только по делу и не вставляет в презентацию буллиты. Профессионала приятно и интересно слушать, даже если тема так себе. У профессионала можно и нужно учиться.
Об идеях 1
Наверняка вы видели в ванильных пабликах цитату "Великие умы обсуждают идеи, средние умы обсуждают события, мелкие умы обсуждают людей".
Если посмотреть на всяких блоггеров и генераторов контента в инфополе, то можно обратить внимание, что все их сообщения/посты/книги так или иначе сконцентрированы вокруг малого количества ключевых идей/концепций, и, если читать автора достаточно долго, то начинаешь замечать самоповторы.
Например, ребята из Basecamp (DHH и Jason Fried) пишут об спокойной работе и здоровом work/life balance, асинхронных коммуникациях, негативном влиянии венчурных капиталистов на бизенсы. Все их книги и посты в блоге, если их перечитать, в принципе об одном и том же.
Егор Бугаенко (yegor256) пишет о правильном ООП, оплате за результат, а не за время, и автоматизации управления программистами.
Нассим Талеб, по расхожему мнению, эксплуатирует идею "мы не берем во внимание то, чего мы не знаем" и льет воду об одном и том же во всех своих книгах (зарабатывая на них уж явно побольше денег, нежели те, кто его критикуют).
Все эти люди схожи тем, что толкают свои идеи, которые либо контр-интуитивны, либо сильно противоречат устоявшемуся мнению большинства, а дальше делают из этих идей продукты — книги, софт, консультации и так далее.
Такие штуки довольно сильно напоминают культ/религию/идеологию, что еще раз подтверждает фраза "Если вы хотите разбогатеть, надо основать религию", часто приписываемая известному писателю Рону Хаббарду.
Вместо "религии" можно подсунуть "качественное опенсорс решение" и вот вы уже выступаете на конференциях с докладами о том, как было все плохо, и тут вы решили придумать для решения этой проблемы продукт Х и теперь предлагаете использовать его всем. А за дополнительные плюшки вроде традиционных LDAP авторизаций или консультации по внедрению методологии извольте заплатить денег.
Наверняка вы видели в ванильных пабликах цитату "Великие умы обсуждают идеи, средние умы обсуждают события, мелкие умы обсуждают людей".
Если посмотреть на всяких блоггеров и генераторов контента в инфополе, то можно обратить внимание, что все их сообщения/посты/книги так или иначе сконцентрированы вокруг малого количества ключевых идей/концепций, и, если читать автора достаточно долго, то начинаешь замечать самоповторы.
Например, ребята из Basecamp (DHH и Jason Fried) пишут об спокойной работе и здоровом work/life balance, асинхронных коммуникациях, негативном влиянии венчурных капиталистов на бизенсы. Все их книги и посты в блоге, если их перечитать, в принципе об одном и том же.
Егор Бугаенко (yegor256) пишет о правильном ООП, оплате за результат, а не за время, и автоматизации управления программистами.
Нассим Талеб, по расхожему мнению, эксплуатирует идею "мы не берем во внимание то, чего мы не знаем" и льет воду об одном и том же во всех своих книгах (зарабатывая на них уж явно побольше денег, нежели те, кто его критикуют).
Все эти люди схожи тем, что толкают свои идеи, которые либо контр-интуитивны, либо сильно противоречат устоявшемуся мнению большинства, а дальше делают из этих идей продукты — книги, софт, консультации и так далее.
Такие штуки довольно сильно напоминают культ/религию/идеологию, что еще раз подтверждает фраза "Если вы хотите разбогатеть, надо основать религию", часто приписываемая известному писателю Рону Хаббарду.
Вместо "религии" можно подсунуть "качественное опенсорс решение" и вот вы уже выступаете на конференциях с докладами о том, как было все плохо, и тут вы решили придумать для решения этой проблемы продукт Х и теперь предлагаете использовать его всем. А за дополнительные плюшки вроде традиционных LDAP авторизаций или консультации по внедрению методологии извольте заплатить денег.
Мгновенная карма
Пару дней назад проходил собес на девопс-чего-то там позицию в лидер рынка. Надо поддерживать себя в форме, все дела.
Перед собесом рекрутер выдала мне ексель файл с сотней технологий по каждой из которых нужно было поставить себе оценку.
После этого интервьюер задавал мне вопросы по этому списочку и проставлял уже свою оценку. Такого типа собесы распространены в больших компаниях, где процесс найма пытаются сделать максимально формализованным, поэтому я не удивился и спокойно реагировал на вопросы вроде "настраивали ли вы DHCP", и "что такое BGP, vxlan?".
В том числе один из вопросов касался "Disaster recovery/disaster recovery plan". Я, естественно, по науке с этим дела никогда не имел, документов и планов не писал, но че-то попробовал рассказать вроде "надо приложуху деплоить в разных регионах/датацентрах и настраивать между ними репликацию, чтобы когда один дц умрет, то можно было бы перенаправить все запросы на второй". Не особо проканало, но хоть так, лучше чем ничего.
Буквально на следующий день утром заказчик одного из продуктов, который я разрабатываю и поддерживаю пишет "все упало". Смотрю в мониторинг — там действительно упало все, что находилось в основном ДЦ, где располагаются наши сервера. Пробую открыть панель управления серверами — не открывается, host not found, ssh-gateway тоже не работает. "Приехали", подумал я и моментально вспомнил вчерашний собес. Точно так же не резолвились вообще никакие наши хосты. Похоже на то, что у хостера пропали все записи в DNS, потому что сами сервера работали и исправно посылали логи в LogEntries (где была куча ошибок о невозможности зарезолвить эндпоинты SQS лол).
Резервирование серверов-то у меня было, только они находились в том же ДЦ, на том же аккаунте. Кросс-региональную репликацию я не делал, потому что не продал это заказчику. Утренний фулл бекап базы находился на S3 и по практике его разворачивание вместе с подъемом новой инфраструктуры заняло бы часа два. Саппорт хостера понятное дело ничего дельного не смог ответить. В общем я уже собрался делать костылик для того чтобы собирать запросы от клиентов (продукт — технологический b2b saas, клиенты шлют запросы по HTTP) и потом их обработать пачкой, но пока думал и гадал то DNS заработал и все заколосилось. Outage составил 40 минут.
Похожая ситуация уже случалась примерно год назад, но тогда я просто забил делать костыль (а делать там нечего, api gateway + λ + SQS + S3) потому что я ленивая задница и потому что были продуктовые задачи. Весь год я думал о том что надо бы сделать бекап АРІ, потому что случались и менее серьезные сбои, по 10 минут и тд, и весь год задвигал эту задачу подальше, накапливая технический долг.
Вот так вот рок меня настиг. Разберусь с продуктовыми задачами и засяду за грамотный disaster recovery, ахаха.
Пару дней назад проходил собес на девопс-чего-то там позицию в лидер рынка. Надо поддерживать себя в форме, все дела.
Перед собесом рекрутер выдала мне ексель файл с сотней технологий по каждой из которых нужно было поставить себе оценку.
После этого интервьюер задавал мне вопросы по этому списочку и проставлял уже свою оценку. Такого типа собесы распространены в больших компаниях, где процесс найма пытаются сделать максимально формализованным, поэтому я не удивился и спокойно реагировал на вопросы вроде "настраивали ли вы DHCP", и "что такое BGP, vxlan?".
В том числе один из вопросов касался "Disaster recovery/disaster recovery plan". Я, естественно, по науке с этим дела никогда не имел, документов и планов не писал, но че-то попробовал рассказать вроде "надо приложуху деплоить в разных регионах/датацентрах и настраивать между ними репликацию, чтобы когда один дц умрет, то можно было бы перенаправить все запросы на второй". Не особо проканало, но хоть так, лучше чем ничего.
Буквально на следующий день утром заказчик одного из продуктов, который я разрабатываю и поддерживаю пишет "все упало". Смотрю в мониторинг — там действительно упало все, что находилось в основном ДЦ, где располагаются наши сервера. Пробую открыть панель управления серверами — не открывается, host not found, ssh-gateway тоже не работает. "Приехали", подумал я и моментально вспомнил вчерашний собес. Точно так же не резолвились вообще никакие наши хосты. Похоже на то, что у хостера пропали все записи в DNS, потому что сами сервера работали и исправно посылали логи в LogEntries (где была куча ошибок о невозможности зарезолвить эндпоинты SQS лол).
Резервирование серверов-то у меня было, только они находились в том же ДЦ, на том же аккаунте. Кросс-региональную репликацию я не делал, потому что не продал это заказчику. Утренний фулл бекап базы находился на S3 и по практике его разворачивание вместе с подъемом новой инфраструктуры заняло бы часа два. Саппорт хостера понятное дело ничего дельного не смог ответить. В общем я уже собрался делать костылик для того чтобы собирать запросы от клиентов (продукт — технологический b2b saas, клиенты шлют запросы по HTTP) и потом их обработать пачкой, но пока думал и гадал то DNS заработал и все заколосилось. Outage составил 40 минут.
Похожая ситуация уже случалась примерно год назад, но тогда я просто забил делать костыль (а делать там нечего, api gateway + λ + SQS + S3) потому что я ленивая задница и потому что были продуктовые задачи. Весь год я думал о том что надо бы сделать бекап АРІ, потому что случались и менее серьезные сбои, по 10 минут и тд, и весь год задвигал эту задачу подальше, накапливая технический долг.
Вот так вот рок меня настиг. Разберусь с продуктовыми задачами и засяду за грамотный disaster recovery, ахаха.
Об идеях 2. Рынок решает все
Самый лучший способ донести свою идею людям — это убедить их, что на этом можно зарабатывать/экономить деньги.
Почему отлично заходят всякие опенсорс решения? Потому что авторы или developer advocates компаний убеждают всех вокруг, что их продукт сделает жизнь проще (== позволит заработать больше).
Уже многие годы я так или иначе соприкасаюсь с около-экологическо-зоозащитной темой. Почему, например, плохо распространяется вегетарианство и борьба с промышленным животноводством? По одной причине — сейчас выгодно производить мясо и продавать его. Пока это выгодно, поменять ситуацию лозунгами "это неэтично и загрязняет окружающую среду", на мой взгляд, невозможно. Но ситуация быстро изменится, как только на рынок выйдет качественный заменитель мяса, настоящий (ткань, идентичная натуральной, выращенная в колбе) или нет, и как только стоимость этого продукта станет ниже, нежели мяса настоящих животных.
После этого все животноводство слохпнется само собой, потому что заниматься этим станет просто невыгодно, и настоящий бифштекс станет уделом богачей, прямо как в фантастических книгах.
То же самое касается всевозможных сортировок мусора и сокращения производства пластика. Пока нет эквивалентной по стоимости альтернативы — дело будет идти туго, но как только появится технология, позволяющая экономить на этом, народ моментально проголосует долларом и пластиковые пакеты исчезнут как класс.
Другой способ — законодательный, ограничение выбросов и все такое, работает отлично для развитых стран, которые просто выносят весь мусор в страны третьего мира. Запретили меховые фермы в условных Нидерландах? Отлично, просто построим их в Украине. Пока немец тщательно сортирует свой мусор по разным контейнерам, украинец производит отходов и за себя, и за немца 🙂 Приняли закон о сокращении выбросов СО2 и прочем? Китай быстро поправит расклады 🙂
Почему, например, популярны продукты, которые не всегда уместно применять? Например тащить React для простого сайта, или целый Spring для круда а потом деплоить 1.5 контейнера кубером? Потому что эти технологии вам продали евангелисты, потому что они прекрасно документированы, снабжены огромным количеством примеров, имеют устойчивое сообщество и достаточное количество рабочей силы что в сумме дает кумулятивный эффект.
А бороться с негативными для экологии вещами надо не этично-законодательно-запретительными способами, а делая их экономически невыгодными. Что, конечно, практически доступно только компаниям с большими бюджетами на RnD.
Самый лучший способ донести свою идею людям — это убедить их, что на этом можно зарабатывать/экономить деньги.
Почему отлично заходят всякие опенсорс решения? Потому что авторы или developer advocates компаний убеждают всех вокруг, что их продукт сделает жизнь проще (== позволит заработать больше).
Уже многие годы я так или иначе соприкасаюсь с около-экологическо-зоозащитной темой. Почему, например, плохо распространяется вегетарианство и борьба с промышленным животноводством? По одной причине — сейчас выгодно производить мясо и продавать его. Пока это выгодно, поменять ситуацию лозунгами "это неэтично и загрязняет окружающую среду", на мой взгляд, невозможно. Но ситуация быстро изменится, как только на рынок выйдет качественный заменитель мяса, настоящий (ткань, идентичная натуральной, выращенная в колбе) или нет, и как только стоимость этого продукта станет ниже, нежели мяса настоящих животных.
После этого все животноводство слохпнется само собой, потому что заниматься этим станет просто невыгодно, и настоящий бифштекс станет уделом богачей, прямо как в фантастических книгах.
То же самое касается всевозможных сортировок мусора и сокращения производства пластика. Пока нет эквивалентной по стоимости альтернативы — дело будет идти туго, но как только появится технология, позволяющая экономить на этом, народ моментально проголосует долларом и пластиковые пакеты исчезнут как класс.
Другой способ — законодательный, ограничение выбросов и все такое, работает отлично для развитых стран, которые просто выносят весь мусор в страны третьего мира. Запретили меховые фермы в условных Нидерландах? Отлично, просто построим их в Украине. Пока немец тщательно сортирует свой мусор по разным контейнерам, украинец производит отходов и за себя, и за немца 🙂 Приняли закон о сокращении выбросов СО2 и прочем? Китай быстро поправит расклады 🙂
Почему, например, популярны продукты, которые не всегда уместно применять? Например тащить React для простого сайта, или целый Spring для круда а потом деплоить 1.5 контейнера кубером? Потому что эти технологии вам продали евангелисты, потому что они прекрасно документированы, снабжены огромным количеством примеров, имеют устойчивое сообщество и достаточное количество рабочей силы что в сумме дает кумулятивный эффект.
А бороться с негативными для экологии вещами надо не этично-законодательно-запретительными способами, а делая их экономически невыгодными. Что, конечно, практически доступно только компаниям с большими бюджетами на RnD.