Mercedes-Benz Panamera WRX
Что общего у Mercedes-Benz W124, Porsche Panamera и Subaru Impreza WRX? Во-первых, они все классные. А во-вторых, про них меня попросили рассказать подробнее в комментах к посту про мой автопуть
Mercedes-Benz W124. Легенда и живая классика. Эстетика 90-х, притягивающая взгляды ценителей и не только. Автомобиль с душой и характером, комфортный и благородный. В нем чувствуется какая-то внутренняя интеллигентность, а на ходу она больше напоминает небольшой дорогой катер. В конце концов, получаешь удовольствие от самого факта обладания ей. В ней качественные материалы, монументальная тяжесть и фишечки, которых не ожидаешь от 90-х (например, ИК-ключ или автоподача ремня).
Мой экземпляр был 1995 года, купе-хардтоп, в состоянии "булочка" (не "музей", но вид имеет). Притом я за ней ездил в Питер - именно там нашелся интересный вариант. Были сомнения, доеду ли я на ней до Москвы, поэтому в дорогу были запасены: все жидкости, набор инструментов, вэдэшка, скотч, стяжки, насос и многое другое. Однако, ничего не пригодилось. И в последствии машина показала себя надежным агрегатом, хотя внимания и требовала. Впрочем, как и другие мерседесы - сначала довозила до пункта назначения (в отличие, например, от Эскалейда, который меня трижды подвел в самые неподходящие моменты - если хотите эти кул-стори, пишите в комменты). Главное - избегайте моторов на каеджетронике.
Porsche Panamera. Тоже катер, даже более премиальный, но еще и быстроходный. Редкий компромисс между комфортом и драйвом. С одной стороны, это пятиметровая баржа на пневме с потрясным качеством салона и материалов. Реальный премиум, на голову выше большой немецкой тройки. С другой - это все-таки Порше, и 400-сильный V8 отлично сочетается с отточенным шасси. Машина управляется превосходно (по меркам двухтонного бегемотика) и дает много удовольствия за рулем.
Мой экземпляр 2012 года был куплен полтора года назад меньше, чем за 3 миллиона рублей - на мой взгяд, очень неплохое вложение. Даже на пробеге чуть за 100 тысяч, состояние прекрасное, машина имеет лютый запас прочности. Хотя обслуживание недешево - за год тысяч 200 она вполне может просить. Главное - не берите из-под горячих ребят, которые на них ураганят и плохо обслуживают. Лучше воспользоваться подбором и обязательно проверять движок с эндоскопом - они склонны к задирам.
Subaru Impreza WRX. Продолжая морские метафоры - это бешеная тайская лодка на джейзете, избыточно быстрая, шумная, неуправляемая, некомфортная. Но очень нравится. Харизма так и прет - начиная с фирменного бу-бу-бу от неравнодлинного коллектора оппозитника, и заканчивая фирменным же полным приводом, позволяющим грести на всех парах по любому покрытию. Старая японская школа - аскетизм в сочетании с диким кайфом от вождения. Зимой прямо едет редко, но ты удивительно быстро добираешься до пункта назначения.
Мой экземпляр был 2001 года - так называемый, "лупатый". Естественно, синий. Разумеется, на золотых дисках (правда, только летних). Первым делом поменял лавку на высокую от sti (да еще и с распорками в духе wrc). Вторым - сделал подсветку под днищем в духе форсажа и need for speed. Непременно поставил blow-off. Выря вполне хватает, сти - даже перебор. Увы, машина пала в неравной борбе с бетонной стеной развязки ТТК в условиях гололедицы, поворота, уклона, обратного бенкинга и хреновой липучки.
Что общего у Mercedes-Benz W124, Porsche Panamera и Subaru Impreza WRX? Во-первых, они все классные. А во-вторых, про них меня попросили рассказать подробнее в комментах к посту про мой автопуть
Mercedes-Benz W124. Легенда и живая классика. Эстетика 90-х, притягивающая взгляды ценителей и не только. Автомобиль с душой и характером, комфортный и благородный. В нем чувствуется какая-то внутренняя интеллигентность, а на ходу она больше напоминает небольшой дорогой катер. В конце концов, получаешь удовольствие от самого факта обладания ей. В ней качественные материалы, монументальная тяжесть и фишечки, которых не ожидаешь от 90-х (например, ИК-ключ или автоподача ремня).
Мой экземпляр был 1995 года, купе-хардтоп, в состоянии "булочка" (не "музей", но вид имеет). Притом я за ней ездил в Питер - именно там нашелся интересный вариант. Были сомнения, доеду ли я на ней до Москвы, поэтому в дорогу были запасены: все жидкости, набор инструментов, вэдэшка, скотч, стяжки, насос и многое другое. Однако, ничего не пригодилось. И в последствии машина показала себя надежным агрегатом, хотя внимания и требовала. Впрочем, как и другие мерседесы - сначала довозила до пункта назначения (в отличие, например, от Эскалейда, который меня трижды подвел в самые неподходящие моменты - если хотите эти кул-стори, пишите в комменты). Главное - избегайте моторов на каеджетронике.
Porsche Panamera. Тоже катер, даже более премиальный, но еще и быстроходный. Редкий компромисс между комфортом и драйвом. С одной стороны, это пятиметровая баржа на пневме с потрясным качеством салона и материалов. Реальный премиум, на голову выше большой немецкой тройки. С другой - это все-таки Порше, и 400-сильный V8 отлично сочетается с отточенным шасси. Машина управляется превосходно (по меркам двухтонного бегемотика) и дает много удовольствия за рулем.
Мой экземпляр 2012 года был куплен полтора года назад меньше, чем за 3 миллиона рублей - на мой взгяд, очень неплохое вложение. Даже на пробеге чуть за 100 тысяч, состояние прекрасное, машина имеет лютый запас прочности. Хотя обслуживание недешево - за год тысяч 200 она вполне может просить. Главное - не берите из-под горячих ребят, которые на них ураганят и плохо обслуживают. Лучше воспользоваться подбором и обязательно проверять движок с эндоскопом - они склонны к задирам.
Subaru Impreza WRX. Продолжая морские метафоры - это бешеная тайская лодка на джейзете, избыточно быстрая, шумная, неуправляемая, некомфортная. Но очень нравится. Харизма так и прет - начиная с фирменного бу-бу-бу от неравнодлинного коллектора оппозитника, и заканчивая фирменным же полным приводом, позволяющим грести на всех парах по любому покрытию. Старая японская школа - аскетизм в сочетании с диким кайфом от вождения. Зимой прямо едет редко, но ты удивительно быстро добираешься до пункта назначения.
Мой экземпляр был 2001 года - так называемый, "лупатый". Естественно, синий. Разумеется, на золотых дисках (правда, только летних). Первым делом поменял лавку на высокую от sti (да еще и с распорками в духе wrc). Вторым - сделал подсветку под днищем в духе форсажа и need for speed. Непременно поставил blow-off. Выря вполне хватает, сти - даже перебор. Увы, машина пала в неравной борбе с бетонной стеной развязки ТТК в условиях гололедицы, поворота, уклона, обратного бенкинга и хреновой липучки.
🔥7👍1
Надежность: качество релизов
Недавно писал сюда нашу стратегию надежности. Думаю, стоит раскрыть чуть подробней некоторые пункты - почему они важны и полезны. В этот раз - про качество релизов.
Пусть у вас в эксплуатации находится сложная и развестстая система сервисов, обеспечивающих функционирование вашего продукта. Даже если ее не трогать (вообще убрать руки с клавиатуры) она долго не протянет. Но мы же постоянно норовим нанести пользы и причинить добро. А потому катаем разного рода релизы по 50+ раз в неделю (это не преувеличение, это количество релизов только бекендов Еды за прошлую неделю).
Каждый релиз сопряжен с рисками возникновения инцидента. Можно ошибиться в коде, можно подтянуть бажную зависимость, можно неправильно рассчитать нагрузку, можно забыть проковырять сетевую дырку - возможных причин упасть больше, чем глаз, следящих за выкладками. Поэтому системно повышать стабильность релизов и автоматизировать это - благо.
Например, сделать в ci-пайплайне автоматическое нагрузочное тестирование микросервиса в изолированном load-окружении перед каждой выкладкой. Если ваш сервис поработает хотя бы 10-15 минут под полной нагрузкой, у вас будут шансы увидеть намного больше, чем при функциональном тестировании - обычные тесты не смогут спровоцировать корки (сегфолты), утечки или проезды по памяти. Вы сможете убедиться, что утилизация ресурсов и тайминги ответов не ухудшаются vs прошлый релиз. Что вы нигде не наворотили с алгоритмической сложностью, сделав вложенный цикл или выбрав неудачную структуру данных. Да, внедрение требует усилий. Да, нужно поддерживать патроны (запросы) в актуальном и релевантном состоянии. Да, отсутствие проблем в релизе это не гарантирует. Но это хорошая солома, которую лучше подстелить.
Также можно проверять капасити системы end-to-end нагрузочным тестированием в продакшне. Это поможет своевременно заметить нахватку запаса прочности по системе в целом, а иногда - заметить проблемный релиз, произошедший между регулярными стрельбами. Тестировать можно скриптом, можно танком - важно, что если у вас транзакционный сервис, должен проверяться цикл заказа (главное - не забудьте отметить в системе тестовые заказы тестовыми).
Разумеется, у вас есть тестирование. Но если оно по большей части ручное, вам не избежать ошибок из-за человеческого фактора. А если у вас в добавок очень много тесткейсов, вряд ли вы сможете при каждом релизе проверять их все. Скорее всего, вы придумаете какой-то подход с чередованием паков тестов от релиза к релизу. Но автоматизировав 75-80-90% тестов, вы получите и снижение пропусков, и возможность всегда гонять весь пак регресс-тестов. Без этого - никак.
Ну и понятная, но не очень простая в реализации вещь - кататься лучше маленькими кусочками. Чтобы не было принципа "одно лечим - другое калечим". Разбиение приложения на модули, уход от монолитов (не только на беке - с фронтами та же история), сокращение импакта изменений, изоляция блоков - залог более крепкого сна после выкладки. Различные bdui-подходы этому тоже помогают. Впрочем, тема bdui намного шире, про нее стоит как-нибудь поразгонять отдельно.
Недавно писал сюда нашу стратегию надежности. Думаю, стоит раскрыть чуть подробней некоторые пункты - почему они важны и полезны. В этот раз - про качество релизов.
Пусть у вас в эксплуатации находится сложная и развестстая система сервисов, обеспечивающих функционирование вашего продукта. Даже если ее не трогать (вообще убрать руки с клавиатуры) она долго не протянет. Но мы же постоянно норовим нанести пользы и причинить добро. А потому катаем разного рода релизы по 50+ раз в неделю (это не преувеличение, это количество релизов только бекендов Еды за прошлую неделю).
Каждый релиз сопряжен с рисками возникновения инцидента. Можно ошибиться в коде, можно подтянуть бажную зависимость, можно неправильно рассчитать нагрузку, можно забыть проковырять сетевую дырку - возможных причин упасть больше, чем глаз, следящих за выкладками. Поэтому системно повышать стабильность релизов и автоматизировать это - благо.
Например, сделать в ci-пайплайне автоматическое нагрузочное тестирование микросервиса в изолированном load-окружении перед каждой выкладкой. Если ваш сервис поработает хотя бы 10-15 минут под полной нагрузкой, у вас будут шансы увидеть намного больше, чем при функциональном тестировании - обычные тесты не смогут спровоцировать корки (сегфолты), утечки или проезды по памяти. Вы сможете убедиться, что утилизация ресурсов и тайминги ответов не ухудшаются vs прошлый релиз. Что вы нигде не наворотили с алгоритмической сложностью, сделав вложенный цикл или выбрав неудачную структуру данных. Да, внедрение требует усилий. Да, нужно поддерживать патроны (запросы) в актуальном и релевантном состоянии. Да, отсутствие проблем в релизе это не гарантирует. Но это хорошая солома, которую лучше подстелить.
Также можно проверять капасити системы end-to-end нагрузочным тестированием в продакшне. Это поможет своевременно заметить нахватку запаса прочности по системе в целом, а иногда - заметить проблемный релиз, произошедший между регулярными стрельбами. Тестировать можно скриптом, можно танком - важно, что если у вас транзакционный сервис, должен проверяться цикл заказа (главное - не забудьте отметить в системе тестовые заказы тестовыми).
Разумеется, у вас есть тестирование. Но если оно по большей части ручное, вам не избежать ошибок из-за человеческого фактора. А если у вас в добавок очень много тесткейсов, вряд ли вы сможете при каждом релизе проверять их все. Скорее всего, вы придумаете какой-то подход с чередованием паков тестов от релиза к релизу. Но автоматизировав 75-80-90% тестов, вы получите и снижение пропусков, и возможность всегда гонять весь пак регресс-тестов. Без этого - никак.
Ну и понятная, но не очень простая в реализации вещь - кататься лучше маленькими кусочками. Чтобы не было принципа "одно лечим - другое калечим". Разбиение приложения на модули, уход от монолитов (не только на беке - с фронтами та же история), сокращение импакта изменений, изоляция блоков - залог более крепкого сна после выкладки. Различные bdui-подходы этому тоже помогают. Впрочем, тема bdui намного шире, про нее стоит как-нибудь поразгонять отдельно.
Про BDUI
Не будем уходить далеко от темы backend-driven-UI и попробуем разобраться, хорошо это или плохо. Но сначала - краткий исторический экскурс в бдуй Яндекс Еды.
Когда я пришел в Еду в начале 2021 года, BDUI уже был. Но простенький такой, на минималках. Можно было через так называемый Layout Constructor задавать с бекенда вид некоторых экранов (в первую очередь - главной страницы с каталогом). Было понятие блоков/виджетов. Это было нужно для того, чтобы продакт мог сам немного поменять вид главной в поисках оптимального сетапа. Мог запустить эксперимент с альтернативной главной на сегмент аудитории без кода. Мог развести фичи по сегментам или географиям. Но вот незадача - админка была написана чужими для хищников, и пользоваться ей умело 2-3 человека.
Поэтому появилась вторая генерация - с Layout Configurator-ом и виджетами-без-кода. Тут уже все было по-людски, плюс реализация логики виджетов стала выезжать из LC, в котором можно было через админку задать правила обхода источников и формирования выдачи из их ответов. Хорошее проявление лоу-код/ноу-код подхода. Без всякого там богомерзкого ИИ.
Но вскоре подоспела третья генерация на основе решения "FLEX", зародившегося в Маркете. Тут уже совсем другие пироги - с бекенда можно задавать не только сетку виджетов, но и сами виджеты, включая верстку, экшны, навигацию. Клиент становится тоньше - по сути для отрисовки экрана достаточно SDK, а логика и верстка пишутся на бекенде на Котлине (впрочем, как я понимаю, от котлина там по сути только синтаксис, потому что все равно все примитивы там от фреймворка).
Чем это хорошо?
Во-первых, вы пишете фичу 1 раз на обе платформы (а будет вебная реализация - так вообще под все 3). Значит, команда сможет выдавать в полтора-два раза больше фичей в единицу времени тем же составом. Еще и поведение продукта будет консистентным между платформами.
Во-вторых, для доставки фичи до юзеров достаточно релиза бекенда. Никакого релизного цикла, никакого хвоста старых версий. Это ли не то, почему фронты всегда завидовали бекендерам? Фиксы, кстати, тоже доезжают сразу и до всех.
А минусы будут? Куда без них.
Во-первых, сокращается гибкость, особенно в вопросах сложных визуалов. Не может такой фреймворк уметь во все те фишечки, что заложены в натив вендором платформы. Всякие красивости-анимации, всякие глубоко-платформенные look&feel особенности (в большей степени характерные для ios) в таких SDK по большей части недоступны. Но не беда - всегда же можно оставить какие-то части, где это важно, нативными. Или допилить SDK.
Во-вторых, некоторые разработчики слишком сильно любят те самые нативные фишечки и не хотят уходить в бекендно-фреймворковую разработку. Типа это не то. Ну камон, если ты - в первую очередь, инженер, то ты должен понимать, что это более эффективный способ достигать целей. Это инструмент, который про make things done, про результат. Кому важнее процесс - такая работа тоже никуда не денется. Или пилить сам SDK.
Есть и другие плюсы-минусы, можете дополнять меня в комментариях. Но конъюнктура момента такова, что бизнесу нужен bdui, а мы тут как бы зарплату за это все получаем. Так что не ворчим и пилим фичи!
Не будем уходить далеко от темы backend-driven-UI и попробуем разобраться, хорошо это или плохо. Но сначала - краткий исторический экскурс в бдуй Яндекс Еды.
Когда я пришел в Еду в начале 2021 года, BDUI уже был. Но простенький такой, на минималках. Можно было через так называемый Layout Constructor задавать с бекенда вид некоторых экранов (в первую очередь - главной страницы с каталогом). Было понятие блоков/виджетов. Это было нужно для того, чтобы продакт мог сам немного поменять вид главной в поисках оптимального сетапа. Мог запустить эксперимент с альтернативной главной на сегмент аудитории без кода. Мог развести фичи по сегментам или географиям. Но вот незадача - админка была написана чужими для хищников, и пользоваться ей умело 2-3 человека.
Поэтому появилась вторая генерация - с Layout Configurator-ом и виджетами-без-кода. Тут уже все было по-людски, плюс реализация логики виджетов стала выезжать из LC, в котором можно было через админку задать правила обхода источников и формирования выдачи из их ответов. Хорошее проявление лоу-код/ноу-код подхода. Без всякого там богомерзкого ИИ.
Но вскоре подоспела третья генерация на основе решения "FLEX", зародившегося в Маркете. Тут уже совсем другие пироги - с бекенда можно задавать не только сетку виджетов, но и сами виджеты, включая верстку, экшны, навигацию. Клиент становится тоньше - по сути для отрисовки экрана достаточно SDK, а логика и верстка пишутся на бекенде на Котлине (впрочем, как я понимаю, от котлина там по сути только синтаксис, потому что все равно все примитивы там от фреймворка).
Чем это хорошо?
Во-первых, вы пишете фичу 1 раз на обе платформы (а будет вебная реализация - так вообще под все 3). Значит, команда сможет выдавать в полтора-два раза больше фичей в единицу времени тем же составом. Еще и поведение продукта будет консистентным между платформами.
Во-вторых, для доставки фичи до юзеров достаточно релиза бекенда. Никакого релизного цикла, никакого хвоста старых версий. Это ли не то, почему фронты всегда завидовали бекендерам? Фиксы, кстати, тоже доезжают сразу и до всех.
А минусы будут? Куда без них.
Во-первых, сокращается гибкость, особенно в вопросах сложных визуалов. Не может такой фреймворк уметь во все те фишечки, что заложены в натив вендором платформы. Всякие красивости-анимации, всякие глубоко-платформенные look&feel особенности (в большей степени характерные для ios) в таких SDK по большей части недоступны. Но не беда - всегда же можно оставить какие-то части, где это важно, нативными. Или допилить SDK.
Во-вторых, некоторые разработчики слишком сильно любят те самые нативные фишечки и не хотят уходить в бекендно-фреймворковую разработку. Типа это не то. Ну камон, если ты - в первую очередь, инженер, то ты должен понимать, что это более эффективный способ достигать целей. Это инструмент, который про make things done, про результат. Кому важнее процесс - такая работа тоже никуда не денется. Или пилить сам SDK.
Есть и другие плюсы-минусы, можете дополнять меня в комментариях. Но конъюнктура момента такова, что бизнесу нужен bdui, а мы тут как бы зарплату за это все получаем. Так что не ворчим и пилим фичи!
❤10🤡7🖕4
Trust issues
Для меня важно доверять своему автомобилю. Быть уверенным, что он довезет. Знать, что на ходу ничего критичного не отвалится. Я после покупки очередного авто не езжу быстро и агрессивно, пока тщательно не обслужу его (и пока не "вкачусь" в машину, чтобы хорошо ее знать и чувствовать, но это другая тема). Но это вопрос не только надежности машины "в лоб", но и ее характера.
У меня было много машин, которые частенько просили ремонта (с моей любовью к некрухам - немудрено). Но некоторые из них всегда сначала довозили, а потом просились в сервис (например, mercedes s-klasse w220). Некоторые сразу никуда не ехали, оставаясь у дома в духе "мам, мне ко второй паре" (например, bmw 325 e90). Но хуже всего - те, которые подводили меня в самые неподходящие моменты. Например, Cadillac Escalade GMT900. Как вы просили в комментах к прошлому авто-посту, пилю прохладные.
Но сначала обрисую персонажа. Что же из себя представляет эскалейд? Бешенный белый носорог, готовый с ревом броситься на любую газель. Слабоадекватное трехтонное жывотное, которое послушно следует за педалью газа примерно в направлении поворота руля. Мотор V8 6.2л, 409 л.с. прям тащит. Настоящее американское лакшери (но только в комплектации platinum), притягивает взгляды. Однако, на ходу она не такая плавная и мягкая, как ожидаешь (как минимум на 20-х тапочках). Очень просторный салон и огромный багажник. В целом-то, машина кайфовая. Но не лояльная, а я этого не прощаю.
Конец августа 2020, заканчивается дачный сезон. С дачи надо вывезти жену, ребенка, кошку, тёщу и несколько кубометров скарба. Даже в эскалейд все это за один раз не влезет. Принимаю решение сделать две ходки. В первый заход гружу тёщу и часть вещей, еду в город. Ливень, на дороге много воды. И вот этими потоками отрывает трубку маслообменника коробки. Заметить это сразу - трудно. Зато, когда через 80км коробка без масла сплавилась в один чугунок, проблема становится весьма заметна. Становится ясно, что не то что вернуться на дачу за второй партией - до сервиса то доехать затруднительно! А надо вывозить семью. Тачка - в сервис, я - за грузовым каршерингом.
Октябрьское воскресное утро. Через полчаса начнется трансляция финального этапа RDS GP в Сочи. Все настроено, чипари закуплены, я предвкушаю жирные заезды. Но тут вспоминаю, что в эскалейде бак почти пустой (с расходом 25л это довольно частое явление), а утром везти сына в садик, заправка не по пути. Ладно, еще же полчаса есть, заправка в 5 минутах, успею! Однако, с АЗС уехать уже не смог - не двигается рычаг КПП. Как позже выяснилось, сдохла лягушка под педалью тормоза, разблокирующая рычаг кпп, а режима принудительного перевода рычага у машины просто нет. Отдельный прикол - машина под навесом заправки, и эвакуатору-манипулятору не хватает высоты навеса, чтобы поднять авто. Поэтому он сначала меня зацепил за переднюю ось, приподнял и вытянул за заблокированных задних колесах из-под козырька, после чего уже грузил целиком. Половину этапа RDS пропустил.
Морозный январь 2021. Зачем-то поехал в командировку в Питер на машине. Приехал, оставил машину у отеля, пару дней поработал. В день отъезда планировал доехать на тачке от отеля до офиса, поработать, и вечером стартовать домой. Но у машины были другие планы - она не завелась. А мне в этот день как бы домой надо. Да и не планировал я в СПб задерживаться. Чужой город, эвакуатор, сервис. Хорошо хоть мастер к концу дня справился с проблемой, которая оказалась в растрескавшихся от мороза бронепроводах зажигания.
Спустя два дня машина была выставлена в продажу, ибо нефиг. Означает ли это, что Cadillac Escalade - сыпучая шляпа? Пожалуй, нет. Ну с кем не бывает - трубочка, датчик, провода - ерунда же, машине 10 лет. Но либо вы с машиной друг другу доверяете и уважаете друг друга, либо надо разбегаться.
Для меня важно доверять своему автомобилю. Быть уверенным, что он довезет. Знать, что на ходу ничего критичного не отвалится. Я после покупки очередного авто не езжу быстро и агрессивно, пока тщательно не обслужу его (и пока не "вкачусь" в машину, чтобы хорошо ее знать и чувствовать, но это другая тема). Но это вопрос не только надежности машины "в лоб", но и ее характера.
У меня было много машин, которые частенько просили ремонта (с моей любовью к некрухам - немудрено). Но некоторые из них всегда сначала довозили, а потом просились в сервис (например, mercedes s-klasse w220). Некоторые сразу никуда не ехали, оставаясь у дома в духе "мам, мне ко второй паре" (например, bmw 325 e90). Но хуже всего - те, которые подводили меня в самые неподходящие моменты. Например, Cadillac Escalade GMT900. Как вы просили в комментах к прошлому авто-посту, пилю прохладные.
Но сначала обрисую персонажа. Что же из себя представляет эскалейд? Бешенный белый носорог, готовый с ревом броситься на любую газель. Слабоадекватное трехтонное жывотное, которое послушно следует за педалью газа примерно в направлении поворота руля. Мотор V8 6.2л, 409 л.с. прям тащит. Настоящее американское лакшери (но только в комплектации platinum), притягивает взгляды. Однако, на ходу она не такая плавная и мягкая, как ожидаешь (как минимум на 20-х тапочках). Очень просторный салон и огромный багажник. В целом-то, машина кайфовая. Но не лояльная, а я этого не прощаю.
Конец августа 2020, заканчивается дачный сезон. С дачи надо вывезти жену, ребенка, кошку, тёщу и несколько кубометров скарба. Даже в эскалейд все это за один раз не влезет. Принимаю решение сделать две ходки. В первый заход гружу тёщу и часть вещей, еду в город. Ливень, на дороге много воды. И вот этими потоками отрывает трубку маслообменника коробки. Заметить это сразу - трудно. Зато, когда через 80км коробка без масла сплавилась в один чугунок, проблема становится весьма заметна. Становится ясно, что не то что вернуться на дачу за второй партией - до сервиса то доехать затруднительно! А надо вывозить семью. Тачка - в сервис, я - за грузовым каршерингом.
Октябрьское воскресное утро. Через полчаса начнется трансляция финального этапа RDS GP в Сочи. Все настроено, чипари закуплены, я предвкушаю жирные заезды. Но тут вспоминаю, что в эскалейде бак почти пустой (с расходом 25л это довольно частое явление), а утром везти сына в садик, заправка не по пути. Ладно, еще же полчаса есть, заправка в 5 минутах, успею! Однако, с АЗС уехать уже не смог - не двигается рычаг КПП. Как позже выяснилось, сдохла лягушка под педалью тормоза, разблокирующая рычаг кпп, а режима принудительного перевода рычага у машины просто нет. Отдельный прикол - машина под навесом заправки, и эвакуатору-манипулятору не хватает высоты навеса, чтобы поднять авто. Поэтому он сначала меня зацепил за переднюю ось, приподнял и вытянул за заблокированных задних колесах из-под козырька, после чего уже грузил целиком. Половину этапа RDS пропустил.
Морозный январь 2021. Зачем-то поехал в командировку в Питер на машине. Приехал, оставил машину у отеля, пару дней поработал. В день отъезда планировал доехать на тачке от отеля до офиса, поработать, и вечером стартовать домой. Но у машины были другие планы - она не завелась. А мне в этот день как бы домой надо. Да и не планировал я в СПб задерживаться. Чужой город, эвакуатор, сервис. Хорошо хоть мастер к концу дня справился с проблемой, которая оказалась в растрескавшихся от мороза бронепроводах зажигания.
Спустя два дня машина была выставлена в продажу, ибо нефиг. Означает ли это, что Cadillac Escalade - сыпучая шляпа? Пожалуй, нет. Ну с кем не бывает - трубочка, датчик, провода - ерунда же, машине 10 лет. Но либо вы с машиной друг другу доверяете и уважаете друг друга, либо надо разбегаться.
🫡8👍4🤡2
Командный дух
С коллегами мы проводим едва ли не больше времени, чем с семьей и друзьями. И если у вас сугубо профессиональные отношения, и не о чем поговорить помимо работы - это грустно. Очень важно, чтобы на работе у вас были единомышленники не только в профессиональном плане, но и близкие по духу друзья-приятели. А если у вас есть свои традиции и ритуалы - вообще огонь!
Если вы думаете, что ваши увлечения и хобби никто не разделяет - просто спросите ребят вокруг. Или "заразите" их сами своими увлечениями. Сформируйте кружок по интересам и кайфуйте вместе. Создавайте традиции, обрастайте горизонтальными связями. Это укрепляет командный дух.
Одна из уже сложившихся традиций у нас - раз в год ездить на какой-то не-московский этап RDS GP, притом заодно делать из уикенда какую-то запоминающуюся тусовку. Поначалу я знал лишь одного коллегу, кто тоже болеет за дрифт. Сейчас мы второй год ездим всемером. У нас в тусовке есть тимлид (и практикующий бекендер), три продакта, проджект (ex-qa), рукль разработки и CEO. Нужно завербовать еще хотя бы одного фронта и сможем за выходные под пиво запускать проекты! (Чрезмерное употребление алкоголя вредит вашему здоровью)
В прошлом году ездили на питерский этап. Сняли на Игора-драйв домик с сауной, пожарили шашлыки под корону (салют ми фамилия!), поиграли в коднеймс, посмотрели этап. Было офигенно! Заодно притащили в офис мерчовый ковер Forward racing, чтобы напоминал о поездке. И весь год ждали новый сезон.
В этом году нас принял Красноярск. А раз мы едем не только за гонками, но и за атмосферой, выезд было решено сделать гастрономическим. Красноярск в последние годы стал одной из российских столиц ресторанной индустрии, и было решительно необходимо это проверить на зуб.
Fresco - очень хорошо.
Тунгуска - невероятно хорошо. Настолько, что, пожалуй, это самый вкусный ресторан, где я был.
Hello wine - классные завтраки (со слов ребят, я пораньше уехал на кольцо).
Formagio - пойти туда на завтрак было ошибкой - это оказался шведский стол...
Brisket boys на фудкорте RDS - как обычно, ван лав. Верните похлебку!
Spaten в аэропорту - вполне неплохо по аэропортовым меркам.
Общественная баня №6 на речном - если вы ностальгируете по совку. Попариться можно, Нарзан имеется.
Сам этап выдался мокрым, но интересным. Суббота - квалификация и топ-32 - шли по сухо-мокро (нестабильное покрытие в пятнышку - ад дрифтера), что добавило много непредсказуемости. Было валидольно, но заезды не самые жирные. В воскресенье лил сильный дождь весь день. На трассе было столько воды, что организаторы рыли дренажные канавы, а пилоты снимали передние бампера, иначе их отрывало потоками воды. Но то, как в этих условиях показали себя пилоты - это просто восторг! Такого коммитмента по сухому-то редко увидишь.
Отдельно зацепила мудрость от комментаторов: "В первом повороте гонка не выигрывается, но очень легко проигрывается".
Это снова было незабываемо. Спасибо вам, дорогие! Люблю вас) В следующем году повторим.
С коллегами мы проводим едва ли не больше времени, чем с семьей и друзьями. И если у вас сугубо профессиональные отношения, и не о чем поговорить помимо работы - это грустно. Очень важно, чтобы на работе у вас были единомышленники не только в профессиональном плане, но и близкие по духу друзья-приятели. А если у вас есть свои традиции и ритуалы - вообще огонь!
Если вы думаете, что ваши увлечения и хобби никто не разделяет - просто спросите ребят вокруг. Или "заразите" их сами своими увлечениями. Сформируйте кружок по интересам и кайфуйте вместе. Создавайте традиции, обрастайте горизонтальными связями. Это укрепляет командный дух.
Одна из уже сложившихся традиций у нас - раз в год ездить на какой-то не-московский этап RDS GP, притом заодно делать из уикенда какую-то запоминающуюся тусовку. Поначалу я знал лишь одного коллегу, кто тоже болеет за дрифт. Сейчас мы второй год ездим всемером. У нас в тусовке есть тимлид (и практикующий бекендер), три продакта, проджект (ex-qa), рукль разработки и CEO. Нужно завербовать еще хотя бы одного фронта и сможем за выходные под пиво запускать проекты! (Чрезмерное употребление алкоголя вредит вашему здоровью)
В прошлом году ездили на питерский этап. Сняли на Игора-драйв домик с сауной, пожарили шашлыки под корону (салют ми фамилия!), поиграли в коднеймс, посмотрели этап. Было офигенно! Заодно притащили в офис мерчовый ковер Forward racing, чтобы напоминал о поездке. И весь год ждали новый сезон.
В этом году нас принял Красноярск. А раз мы едем не только за гонками, но и за атмосферой, выезд было решено сделать гастрономическим. Красноярск в последние годы стал одной из российских столиц ресторанной индустрии, и было решительно необходимо это проверить на зуб.
Fresco - очень хорошо.
Тунгуска - невероятно хорошо. Настолько, что, пожалуй, это самый вкусный ресторан, где я был.
Hello wine - классные завтраки (со слов ребят, я пораньше уехал на кольцо).
Formagio - пойти туда на завтрак было ошибкой - это оказался шведский стол...
Brisket boys на фудкорте RDS - как обычно, ван лав. Верните похлебку!
Spaten в аэропорту - вполне неплохо по аэропортовым меркам.
Общественная баня №6 на речном - если вы ностальгируете по совку. Попариться можно, Нарзан имеется.
Сам этап выдался мокрым, но интересным. Суббота - квалификация и топ-32 - шли по сухо-мокро (нестабильное покрытие в пятнышку - ад дрифтера), что добавило много непредсказуемости. Было валидольно, но заезды не самые жирные. В воскресенье лил сильный дождь весь день. На трассе было столько воды, что организаторы рыли дренажные канавы, а пилоты снимали передние бампера, иначе их отрывало потоками воды. Но то, как в этих условиях показали себя пилоты - это просто восторг! Такого коммитмента по сухому-то редко увидишь.
Отдельно зацепила мудрость от комментаторов: "В первом повороте гонка не выигрывается, но очень легко проигрывается".
Это снова было незабываемо. Спасибо вам, дорогие! Люблю вас) В следующем году повторим.
❤15🔥10💯3
Вредные советы для продактов, ставящих задачи разработке
Продакты - люди творческие, а в добавок, как правило, очень занятые. К счастью, они разбираются в техническом устройстве сервисов не хуже разработчиков, поэтому лучше знают, как решать ту или иную задачу. А обладая всем тем контекстом, который есть в голове у продакта, он может быть уверенным, что он все учел. Разработчики же, в свою очередь, должны просто делать то, что им говорят, а при необходимости - читать мысли продактов. Рассмотрим типовые примеры постановки задач из продукта к разработке.
Сабджект: Та фича, про которую я тебе говорил в коридоре
Описание: <отсутствует>
А на самом деле: и как это понимать? Когда ты что кому говорил? "Нет времени объяснять"? А ты уверен, что я тебя правильно услышал и запомнил? А когда я сделаю что-то по-другому, опять я буду виноват?
Сабджект: Новая фича
Описание: <скриншот макета из фигмы>
А на самом деле: А что именно из этого, простите, надо делать? А как оно сейчас выглядит с учетом вариативности экспериментов? Как оно должно работать? Кто это вообще рисовал??
Сабджект: Сделать ручку (endpoint - прим.ред.)
Описание: Нужна ручка, которая принимает id юзера и возвращает жсон со статусом и eta текущего заказа.
А на самом деле: А какую задачу ты решаешь? Можно хоть какой-то контекст и цель? Все же разделение труда придумали не просто так, оставь нам решать, как именно технически решить эту задачу и какой контракт будет у ручки, пожалуйста.
Сабджект: Вырастить GMV на 3%
Описание: Мы отстаем от бюджета 6+6, нужно догнать GMV. Поэтому нужно повысить конверсию с главной в заказ на 2% и средний чек на 6%.
А на самом деле: Спасибо, тут есть какой-то контекст "зачем". Но не хватает "как", а вот это уже, в продуктовом смысле - твоя вотчина.
Сабджект: Писать на трекинге "доставили раньше на Х минут".
Описание: Если заказ завершается раньше промиса, писать об этом на экране трекинга.
А на самом деле: А если раньше на 1 минуту, все равно писать? А если заказ отменился? А считать от прибытия курьера или от передачи заказа? Кто должен продумывать корнер-кейсы, ты или я?
Сабджект: Трансляция на трекинге, чтобы клиент не скучал
Описание: Если курьер опаздывает более, чем на 10 минут, клиент скучает и злится. Чтобы его развлечь, будем показывать на экране трансляцию с фронтальной камеры марсохода Curiosity с задежкой не более 3с - покорение космоса это круто. Срок - до пятницы хард, заказана реклама на ТВ.
А на самом деле: Ммм, а у нас нет sdk для потокового видео, нужно затаскивать. Еще с NASA надо договориться об API. Доступы проковырять. А задержка в 3с немножко невозможна - расстояние до Марса колеблется в диапазоне от 3 до 22 световых минут. Может, стоило обсудить техническую возможность до того, как ставить задачу и прибивать гвоздями сроки?
Сабджект: Пофиксить краш на корзине
Описание: BLOCKER ASAP (проявляется у Ромы!!!)
А на самом деле: По приборам этих крашей было 8. На двух униках. Три - у Ромы, 5 - у нашего qa. Это точно достаточно критичная задача, чтобы отложить ради нее все остальное? Давайте реже следовать методологии RDD (Roma-Driven-Development) и опираться на цифры и риски?
Как хорошо, что у нас продакты не такие. В Еде (и рядом) ребята из продукта самые адекватные, внимательные, грамотные, и вообще - лапочки. Люблю их.
Продакты - люди творческие, а в добавок, как правило, очень занятые. К счастью, они разбираются в техническом устройстве сервисов не хуже разработчиков, поэтому лучше знают, как решать ту или иную задачу. А обладая всем тем контекстом, который есть в голове у продакта, он может быть уверенным, что он все учел. Разработчики же, в свою очередь, должны просто делать то, что им говорят, а при необходимости - читать мысли продактов. Рассмотрим типовые примеры постановки задач из продукта к разработке.
Сабджект: Та фича, про которую я тебе говорил в коридоре
Описание: <отсутствует>
А на самом деле: и как это понимать? Когда ты что кому говорил? "Нет времени объяснять"? А ты уверен, что я тебя правильно услышал и запомнил? А когда я сделаю что-то по-другому, опять я буду виноват?
Сабджект: Новая фича
Описание: <скриншот макета из фигмы>
А на самом деле: А что именно из этого, простите, надо делать? А как оно сейчас выглядит с учетом вариативности экспериментов? Как оно должно работать? Кто это вообще рисовал??
Сабджект: Сделать ручку (endpoint - прим.ред.)
Описание: Нужна ручка, которая принимает id юзера и возвращает жсон со статусом и eta текущего заказа.
А на самом деле: А какую задачу ты решаешь? Можно хоть какой-то контекст и цель? Все же разделение труда придумали не просто так, оставь нам решать, как именно технически решить эту задачу и какой контракт будет у ручки, пожалуйста.
Сабджект: Вырастить GMV на 3%
Описание: Мы отстаем от бюджета 6+6, нужно догнать GMV. Поэтому нужно повысить конверсию с главной в заказ на 2% и средний чек на 6%.
А на самом деле: Спасибо, тут есть какой-то контекст "зачем". Но не хватает "как", а вот это уже, в продуктовом смысле - твоя вотчина.
Сабджект: Писать на трекинге "доставили раньше на Х минут".
Описание: Если заказ завершается раньше промиса, писать об этом на экране трекинга.
А на самом деле: А если раньше на 1 минуту, все равно писать? А если заказ отменился? А считать от прибытия курьера или от передачи заказа? Кто должен продумывать корнер-кейсы, ты или я?
Сабджект: Трансляция на трекинге, чтобы клиент не скучал
Описание: Если курьер опаздывает более, чем на 10 минут, клиент скучает и злится. Чтобы его развлечь, будем показывать на экране трансляцию с фронтальной камеры марсохода Curiosity с задежкой не более 3с - покорение космоса это круто. Срок - до пятницы хард, заказана реклама на ТВ.
А на самом деле: Ммм, а у нас нет sdk для потокового видео, нужно затаскивать. Еще с NASA надо договориться об API. Доступы проковырять. А задержка в 3с немножко невозможна - расстояние до Марса колеблется в диапазоне от 3 до 22 световых минут. Может, стоило обсудить техническую возможность до того, как ставить задачу и прибивать гвоздями сроки?
Сабджект: Пофиксить краш на корзине
Описание: BLOCKER ASAP (проявляется у Ромы!!!)
А на самом деле: По приборам этих крашей было 8. На двух униках. Три - у Ромы, 5 - у нашего qa. Это точно достаточно критичная задача, чтобы отложить ради нее все остальное? Давайте реже следовать методологии RDD (Roma-Driven-Development) и опираться на цифры и риски?
Как хорошо, что у нас продакты не такие. В Еде (и рядом) ребята из продукта самые адекватные, внимательные, грамотные, и вообще - лапочки. Люблю их.
🤣16💯5🤮4🤡4🗿3🤝1
Должен ли тимлид писать код?
Я считаю, что да. Хотя частенько слышу иное мнение.
Начну, пожалуй, с аргументации обратного. Мол, у руководителя есть множество других задач, а если ему приходится кодить, значит он не справляется со своими управленческими задачами. И лучше он выстроит идеальные процессы, вырастит самостоятельных ребят, потому что на долгосроке это даст больше буста, чем те тикеты, которые он сейчас закроет сам.
С этим спорить сложно, но моя позиция этой аргументации и не противоречит. Если лиду именно что приходится кодить, это тревожный знак, работать за других не надо. Если он не занимается в должной мере процессами и ростом людей - зря он так. Много кодить тоже совершенно не обязательно. Но совсем не практиковать - плохо. Просто кодить нужно не все подряд, мол, потому что иначе команда не попадет в планы, а что-то сверх этих планов. Планировать тикеты на лида под крышечку не стоит.
Во-первых, постоянная практика хоть в каком-то стат-значимом объеме позволит лиду не оторваться от реальности. Когда совсем перестаешь писать код, начинаешь хуже ревьювить, хуже оценивать задачи, хуже замечать проблемы в перформансе подопечных, не видеть проблемы в инфраструктуре, хуже проектировать архитектуру. Для этого можно брать небольшие задачки мимо спринта или подхватывать что-то несложное, просто чтобы не терять форму.
Во-вторых, играющий тренер может показывать пример на сложных или нетипичных задачах, и через это развивать своих людей. В том числе можно делать задачи в паре с кем-то из своих ребят. Или подстраховать супер-важный проект. Или подменить кого-то из команды (например, в случае отпуска или больничного), как завещано в книге "Дао Тойота".
В-третьих, перестав ожидать от тимлидов хоть какой-то код, мы скоро поддадимся соблазну начать нанимать тимлидов, которые заведомо не будут писать код. Либо тех, кто уже давно разучился и стал менеджером, либо тех, кто ранее писал на других языках/стеке и не планирует переучиваться. И такому руководителю будет кратно сложнее разобраться в том, чем же занимается его команда. Он не будет чувствовать их жизнь на кончиках пальцев, будет хуже понимать их проблемы, будет менее объективно их оценивать. Да и доверять команда ему будет меньше, авторитет проще заслужить, засучив рукава и поработав с парнями бок о бок.
Как же он успеет и лидить хорошо, и код писать - спросите вы. Если мы говорим о руководителе небольшой (5-7 человек) команды, то руководство ей не должно занимать фулл-тайм. А если занимает - это тоже звоночек. Возможно, лиду приходится с людьми нянчиться, и тогда нужно вложиться в их самостоятельность, укомплектоваться ребятами посильнее, делегировать что-то и высвободить себе время. Если команда большая (10-15 человек), то либо можно кодить поменьше (условно, 10% времени вместо 40), либо попилить команду на две, либо вырастить себе зама.
Но как быть в кроссфункциональной команде? Там ведь руководитель может принести пользу только в рамках своей исходной компетенции. Ну как минимум это уже намного лучше, чем ничего. К тому же, развитие T-shape-скиллов для руководителя даже ценнее, чем для линейного разработчика.
А если тимлиды начнут превращаться в чистых менеджеров, погребенных под бесконечными встречами и сомнительной пользы эксельками, мы растеряем нашу инженерную культуру. Станем работать только на циферки kpi. Утратим чувство прекрасного в коде. Скатимся в бездушный энтерпрайз. Поддадимся карго-культу. Забудем свою природу. Не надо так.
Я считаю, что да. Хотя частенько слышу иное мнение.
Начну, пожалуй, с аргументации обратного. Мол, у руководителя есть множество других задач, а если ему приходится кодить, значит он не справляется со своими управленческими задачами. И лучше он выстроит идеальные процессы, вырастит самостоятельных ребят, потому что на долгосроке это даст больше буста, чем те тикеты, которые он сейчас закроет сам.
С этим спорить сложно, но моя позиция этой аргументации и не противоречит. Если лиду именно что приходится кодить, это тревожный знак, работать за других не надо. Если он не занимается в должной мере процессами и ростом людей - зря он так. Много кодить тоже совершенно не обязательно. Но совсем не практиковать - плохо. Просто кодить нужно не все подряд, мол, потому что иначе команда не попадет в планы, а что-то сверх этих планов. Планировать тикеты на лида под крышечку не стоит.
Во-первых, постоянная практика хоть в каком-то стат-значимом объеме позволит лиду не оторваться от реальности. Когда совсем перестаешь писать код, начинаешь хуже ревьювить, хуже оценивать задачи, хуже замечать проблемы в перформансе подопечных, не видеть проблемы в инфраструктуре, хуже проектировать архитектуру. Для этого можно брать небольшие задачки мимо спринта или подхватывать что-то несложное, просто чтобы не терять форму.
Во-вторых, играющий тренер может показывать пример на сложных или нетипичных задачах, и через это развивать своих людей. В том числе можно делать задачи в паре с кем-то из своих ребят. Или подстраховать супер-важный проект. Или подменить кого-то из команды (например, в случае отпуска или больничного), как завещано в книге "Дао Тойота".
В-третьих, перестав ожидать от тимлидов хоть какой-то код, мы скоро поддадимся соблазну начать нанимать тимлидов, которые заведомо не будут писать код. Либо тех, кто уже давно разучился и стал менеджером, либо тех, кто ранее писал на других языках/стеке и не планирует переучиваться. И такому руководителю будет кратно сложнее разобраться в том, чем же занимается его команда. Он не будет чувствовать их жизнь на кончиках пальцев, будет хуже понимать их проблемы, будет менее объективно их оценивать. Да и доверять команда ему будет меньше, авторитет проще заслужить, засучив рукава и поработав с парнями бок о бок.
Как же он успеет и лидить хорошо, и код писать - спросите вы. Если мы говорим о руководителе небольшой (5-7 человек) команды, то руководство ей не должно занимать фулл-тайм. А если занимает - это тоже звоночек. Возможно, лиду приходится с людьми нянчиться, и тогда нужно вложиться в их самостоятельность, укомплектоваться ребятами посильнее, делегировать что-то и высвободить себе время. Если команда большая (10-15 человек), то либо можно кодить поменьше (условно, 10% времени вместо 40), либо попилить команду на две, либо вырастить себе зама.
Но как быть в кроссфункциональной команде? Там ведь руководитель может принести пользу только в рамках своей исходной компетенции. Ну как минимум это уже намного лучше, чем ничего. К тому же, развитие T-shape-скиллов для руководителя даже ценнее, чем для линейного разработчика.
А если тимлиды начнут превращаться в чистых менеджеров, погребенных под бесконечными встречами и сомнительной пользы эксельками, мы растеряем нашу инженерную культуру. Станем работать только на циферки kpi. Утратим чувство прекрасного в коде. Скатимся в бездушный энтерпрайз. Поддадимся карго-культу. Забудем свою природу. Не надо так.
❤11🔥9
Обратная связь
Нет ничего важнее умения работать с обратной связью. Что в случае с сервисом/бизнесом, что с личным фидбеком. Любую обратную связь нужно уметь отработать - вынести из нее уроки, запланировать улучшения, пойти навстречу фидбекодателю. Худшее, что можно сделать - встать в защитную стойку и начать прикрываться оправданиями.
Однако, не все это умеют. Даже крупные компании, занимающие лидирующие позиции на рынке, грешат слепотой к своим ошибкам. Или как раз теряют фокус на качестве, единожды заработав имя. Но репутация - штука такая, гигроскопичная. В смысле легко подмочить. Пока все идет хорошо - держать лицо не трудно. Но истинная сущность сервиса проявляется только в отработке проблемных кейсов.
Вот, например, возьмем одну из крупнейших компаний по подбору автомобилей с пробегом - "Авто-подбор" Ильдара. Опыта много, основатель медийный, клиентов - стало быть - тоже много. Ну не будут же они няньчиться с каждым недовольным. Так система и разваливается изнутри. Хотя, казалось бы, процессы выстроены, рекламации оформляются, дефект-рейт невысокий (наверное).
Со стороны пользователя все выглядит чуть иначе. Услуга оказана некачественно. Диагностика авто после покупки выявила существенные недостатки, которые эксперт-диагност не заметил. Впрочем, не очень-то и старался, судя по косвенным признакам, включающим записи видеонаблюдения у продавца. Что ж, бывает, донесу обратную связь.
Но и обратную связь компания принимать не захотела. Ошибки не признали, отмазки придумали, урегулировать не захотели. Жаль, был лучшего мнения о них. Не хочется больше с такими компаниями взаимодействовать. И вам не советую.
Нет ничего важнее умения работать с обратной связью. Что в случае с сервисом/бизнесом, что с личным фидбеком. Любую обратную связь нужно уметь отработать - вынести из нее уроки, запланировать улучшения, пойти навстречу фидбекодателю. Худшее, что можно сделать - встать в защитную стойку и начать прикрываться оправданиями.
Однако, не все это умеют. Даже крупные компании, занимающие лидирующие позиции на рынке, грешат слепотой к своим ошибкам. Или как раз теряют фокус на качестве, единожды заработав имя. Но репутация - штука такая, гигроскопичная. В смысле легко подмочить. Пока все идет хорошо - держать лицо не трудно. Но истинная сущность сервиса проявляется только в отработке проблемных кейсов.
Вот, например, возьмем одну из крупнейших компаний по подбору автомобилей с пробегом - "Авто-подбор" Ильдара. Опыта много, основатель медийный, клиентов - стало быть - тоже много. Ну не будут же они няньчиться с каждым недовольным. Так система и разваливается изнутри. Хотя, казалось бы, процессы выстроены, рекламации оформляются, дефект-рейт невысокий (наверное).
Со стороны пользователя все выглядит чуть иначе. Услуга оказана некачественно. Диагностика авто после покупки выявила существенные недостатки, которые эксперт-диагност не заметил. Впрочем, не очень-то и старался, судя по косвенным признакам, включающим записи видеонаблюдения у продавца. Что ж, бывает, донесу обратную связь.
Но и обратную связь компания принимать не захотела. Ошибки не признали, отмазки придумали, урегулировать не захотели. Жаль, был лучшего мнения о них. Не хочется больше с такими компаниями взаимодействовать. И вам не советую.
👍6
Автор колонки уходит в отпуск до сентября, не теряйте.
Но на случай, если вы что-то пропустили, вот дайджест прошлых постов:
Важный дисклеймер (есть в закрепе)
Рабочее, серьезное:
И снова про алгоритмы
Стратегия надежности 1 2 3
Надежность: качество релизов
Про BDUI
Вредные советы для продактов, ставящих задачи разработке
Должен ли тимлид писать код?
Околорабочее, несерьезное:
О дипломированных специалистах
Зирвак как платформа надежности
Доверьте работу профессионалам
Трудности перевода
Командный дух
Про тачки:
Автопуть
Mercedes-Benz Panamera WRX
Trust issues
Обратная связь
В порядке бреда:
О пользе караоке
Бизнес-план
Распределенный бог
Предыдущий дайджест
А если вам нравятся мои тексты, поделитесь ими по-братски с друзьями/коллегами. Только так канал будет расти и развиваться, а я ценю релевантную и читающую аудиторию (потому не прибегаю ко всяким мутным схемам накрутки подписчиков). Спасибо)
Но на случай, если вы что-то пропустили, вот дайджест прошлых постов:
Важный дисклеймер (есть в закрепе)
Рабочее, серьезное:
И снова про алгоритмы
Стратегия надежности 1 2 3
Надежность: качество релизов
Про BDUI
Вредные советы для продактов, ставящих задачи разработке
Должен ли тимлид писать код?
Околорабочее, несерьезное:
О дипломированных специалистах
Зирвак как платформа надежности
Доверьте работу профессионалам
Трудности перевода
Командный дух
Про тачки:
Автопуть
Mercedes-Benz Panamera WRX
Trust issues
Обратная связь
В порядке бреда:
О пользе караоке
Бизнес-план
Распределенный бог
Предыдущий дайджест
А если вам нравятся мои тексты, поделитесь ими по-братски с друзьями/коллегами. Только так канал будет расти и развиваться, а я ценю релевантную и читающую аудиторию (потому не прибегаю ко всяким мутным схемам накрутки подписчиков). Спасибо)
Telegram
Ворчливый IT-дед
И на всякий случай давайте договоримся - не воспринимайте написанное в этой колонке буквально и близко к сердцу. Автор не претендует на истину в последней инстанции и не преследует цели кого-то задеть или оскорбить. Некоторые идеи могут быть в иллюстративных…
❤14
Энциклопедические знания
Раз уж сегодня день знаний, поздравлю вас с ним следующей аллюзией.
Из недавнего разговора с коллегами:
- А от Тунгусского метеорита кто вымер - динозавры или мамонты?
- Можно глянуть в Википедии
- Не, спрошу у чат-гпт
Вот раньше как говорили - "человек с энциклопедическими знаниями". Значит, у него широкий кругозор, много фактов в памяти, человек начитанный и образованный. Логично - читая энциклопедии, можно обогатить свои познания множеством фактов - никогда не знаешь, в какой момент они пригодятся. Я люблю дум-скроллить википедию. Искал одно, а там - ссылка за ссылкой - и вот ты уже упоенно читаешь биографию Черчилля.
А теперь что - "человек с чат-гпт-шными знаниями"? Это значит, вообще без оных? Нет, удобно, конечно - задал конкретный вопрос, получил какой-то ответ (хотя я бы дабл-чекнул). Но это убивает романтику получения знаний. Полученные таким образом сведения менее ценны и быстрее забудутся. Да еще и контекста не будет.
Сила - в знаниях. Читайте энциклопедии.
Раз уж сегодня день знаний, поздравлю вас с ним следующей аллюзией.
Из недавнего разговора с коллегами:
- А от Тунгусского метеорита кто вымер - динозавры или мамонты?
- Можно глянуть в Википедии
- Не, спрошу у чат-гпт
Вот раньше как говорили - "человек с энциклопедическими знаниями". Значит, у него широкий кругозор, много фактов в памяти, человек начитанный и образованный. Логично - читая энциклопедии, можно обогатить свои познания множеством фактов - никогда не знаешь, в какой момент они пригодятся. Я люблю дум-скроллить википедию. Искал одно, а там - ссылка за ссылкой - и вот ты уже упоенно читаешь биографию Черчилля.
А теперь что - "человек с чат-гпт-шными знаниями"? Это значит, вообще без оных? Нет, удобно, конечно - задал конкретный вопрос, получил какой-то ответ (хотя я бы дабл-чекнул). Но это убивает романтику получения знаний. Полученные таким образом сведения менее ценны и быстрее забудутся. Да еще и контекста не будет.
Сила - в знаниях. Читайте энциклопедии.
💯19👍5
ArchReview.pdf
30.1 KB
Архитектурное ревью
Сегодня в нашем официальном канале Yandex for Backend вышел мой пост про архревью.
Как я там и обещал, выкладываю артефакт к одному из пунктов - шаблон-опросник.
Это список из ~30 вопросов, на которые должен ответить автор изменений, чтобы убедиться, что он не забыл подумать про важные аспекты проектирования. Какую задачу решает сервис? Почему нельзя обойтись имеющимися? Альтернативы. Сиквенс-диаграмма взаимодействия. Отказоустойчивость, масштабируемость, точки отказа, фолбеки, план внедрения, хранилище, схема данных, периодики, ожидаемая нагрузка - вот лишь часть аспектов, которые нужно осветить в rfc. Потому что если про что-то из этого не подумать, с большой вероятностью случится "ой".
Если хотите послушать про архревью подробнее, приходите на ArchDays или HighLoad++ этой осенью в Москве - мы там будем про это рассказывать.
На ArchDays мой коллега Рома Юрасов расскажет про выстраивание процессов, историю и развитие архревью в Еде, нашу гильдию архитектуры, технологическую культуру.
На Highload++ я в своем докладе больше сделаю упор на выбор технологий под нагрузку, работу с рисками, автоматизацию процедуры, метрики.
В обоих докладах будет про проблематику, технологическую стратегию, а также - разбор шаблона-опросника.
Сегодня в нашем официальном канале Yandex for Backend вышел мой пост про архревью.
Как я там и обещал, выкладываю артефакт к одному из пунктов - шаблон-опросник.
Это список из ~30 вопросов, на которые должен ответить автор изменений, чтобы убедиться, что он не забыл подумать про важные аспекты проектирования. Какую задачу решает сервис? Почему нельзя обойтись имеющимися? Альтернативы. Сиквенс-диаграмма взаимодействия. Отказоустойчивость, масштабируемость, точки отказа, фолбеки, план внедрения, хранилище, схема данных, периодики, ожидаемая нагрузка - вот лишь часть аспектов, которые нужно осветить в rfc. Потому что если про что-то из этого не подумать, с большой вероятностью случится "ой".
Если хотите послушать про архревью подробнее, приходите на ArchDays или HighLoad++ этой осенью в Москве - мы там будем про это рассказывать.
На ArchDays мой коллега Рома Юрасов расскажет про выстраивание процессов, историю и развитие архревью в Еде, нашу гильдию архитектуры, технологическую культуру.
На Highload++ я в своем докладе больше сделаю упор на выбор технологий под нагрузку, работу с рисками, автоматизацию процедуры, метрики.
В обоих докладах будет про проблематику, технологическую стратегию, а также - разбор шаблона-опросника.
Надежность: предотвращение инцидентов из-за потенциально известных проблем
Вернемся к более детальному разбору стратегии надежности, которую я публиковал ранее.
Ранее подробно описал мысли про надежность релизов.
Сегодня поговорим о кейсах, когда мы знали (или могли знать), что шлёпнемся так-то, но почему-то не сделали достаточно, чтобы этого избежать.
Инциденты неизбежно случаются. Но нет ничего хуже, чем наступить на те же грабли. Поэтому каждый инцидент проходит процедуру разбора и выявления экшн-айтемов. Но их еще надо сделать. И чем раньше - тем меньше вероятность рецидива. Поэтому мы постепенно сокращаем SLA на выполнение экшн-айтемов. Тут важно не пережестить - не нужно вешать SLA на всевозможные nice-to-have идеи по мотивам. Только на задачи, "в лоб" предотвращающие повторное падение, или драматически снижающие импакт от оного.
А еще иногда бывают первые звоночки перед инцидентом. Точечная жалоба пользователя, попавшего в эксперимент. Багрепорт уровня блокер из релиза, который только начал раскатку в сторах. Обращение коллеги, который открывает приложение каждые 10 минут. Если на них не обращать внимание, можно упустить ситуацию. Поэтому соблюдение SLA на обработку обращений тоже в ряде случаев помогает заметить инцидент на ранней стадии и купировать эффект.
Очень важно регулярно проводить разного рода учения. Например, по имитации потери одного из дата-центров. Это поможет в условиях сохранения контроля найти те проблемы, которые нас похоронят в случае реальной потери ДЦ. И речь не только о запасе прочности - само изменение топологии может вызвать "бум" - от автофейловера БД до metastable failure.
У вас бывало такое, что вроде бы железа под сервисом было достаточно, а в пятницу вечером оно почему-то начало стремительно заканчиваться? Ну было же. А что, если бы была некая автоматика, которая это заметит быстрее вас и сама докинет ресурсов? А когда ресурсы простаивают, сама перекинет их, например, на аналитические вычисления. Круто же? Надо делать.
Вернемся к более детальному разбору стратегии надежности, которую я публиковал ранее.
Ранее подробно описал мысли про надежность релизов.
Сегодня поговорим о кейсах, когда мы знали (или могли знать), что шлёпнемся так-то, но почему-то не сделали достаточно, чтобы этого избежать.
Инциденты неизбежно случаются. Но нет ничего хуже, чем наступить на те же грабли. Поэтому каждый инцидент проходит процедуру разбора и выявления экшн-айтемов. Но их еще надо сделать. И чем раньше - тем меньше вероятность рецидива. Поэтому мы постепенно сокращаем SLA на выполнение экшн-айтемов. Тут важно не пережестить - не нужно вешать SLA на всевозможные nice-to-have идеи по мотивам. Только на задачи, "в лоб" предотвращающие повторное падение, или драматически снижающие импакт от оного.
А еще иногда бывают первые звоночки перед инцидентом. Точечная жалоба пользователя, попавшего в эксперимент. Багрепорт уровня блокер из релиза, который только начал раскатку в сторах. Обращение коллеги, который открывает приложение каждые 10 минут. Если на них не обращать внимание, можно упустить ситуацию. Поэтому соблюдение SLA на обработку обращений тоже в ряде случаев помогает заметить инцидент на ранней стадии и купировать эффект.
Очень важно регулярно проводить разного рода учения. Например, по имитации потери одного из дата-центров. Это поможет в условиях сохранения контроля найти те проблемы, которые нас похоронят в случае реальной потери ДЦ. И речь не только о запасе прочности - само изменение топологии может вызвать "бум" - от автофейловера БД до metastable failure.
У вас бывало такое, что вроде бы железа под сервисом было достаточно, а в пятницу вечером оно почему-то начало стремительно заканчиваться? Ну было же. А что, если бы была некая автоматика, которая это заметит быстрее вас и сама докинет ресурсов? А когда ресурсы простаивают, сама перекинет их, например, на аналитические вычисления. Круто же? Надо делать.
👍12
Зато на гарантии
Один мой друг недавно приобрел себе автомобиль одного из труднопроизносимых китайских брендов. Мотивация простая (и единственно верная) - "нравится". Новый, дилерский, с гарантией! Но вот незадача - за 3 недели владения гарантией пришлось воспользоваться ... 3 раза.
Во-первых, дилер выдал авто с неработающим кондиционером. Была течь фреоновой магистрали. Залили подкрашенный фреон, покатался, течь нашли и устранили. Ура!
Во-вторых, оказалось, что бампер на заводе был собран неправильно. Пересобрали по гарантии - ура!
В-третьих, обнаружился брак расширителя колесной арки - там просто не было выштамповки под клипсу. Нужно ждать новый фендер, заказали - ура!
И самый кек. Я, как известный душнила, проинструктировал друга, что нужно проверять во время приемки (15 пунктов контроля), включая толщину лако-красочного покрытия. Известны случаи, когда авто при логистике повреждали, покоцанную деталь красили, и выдавали новый авто со вторичным окрасом. Одолжил ему свой толщиномер. Друг вернулся в замешательстве - вся машина покрашена нормально (120-150 мкм), а одно крыло - под 300! Налицо вторичный окрас. Пошел он с продавцом по парковке смотреть другие экземпляры. И вы не поверите - у всех машин этой модели переднее левое крыло бьется в 300 микрон. Это вообще как? Науке сие пока неизвестно. Китайские нано-технологии, не иначе.
Мораль. Гарантия - хорошо. Повод ей воспользоваться - уже не очень хорошо. Китайский автопром - совсем плохо.
Один мой друг недавно приобрел себе автомобиль одного из труднопроизносимых китайских брендов. Мотивация простая (и единственно верная) - "нравится". Новый, дилерский, с гарантией! Но вот незадача - за 3 недели владения гарантией пришлось воспользоваться ... 3 раза.
Во-первых, дилер выдал авто с неработающим кондиционером. Была течь фреоновой магистрали. Залили подкрашенный фреон, покатался, течь нашли и устранили. Ура!
Во-вторых, оказалось, что бампер на заводе был собран неправильно. Пересобрали по гарантии - ура!
В-третьих, обнаружился брак расширителя колесной арки - там просто не было выштамповки под клипсу. Нужно ждать новый фендер, заказали - ура!
И самый кек. Я, как известный душнила, проинструктировал друга, что нужно проверять во время приемки (15 пунктов контроля), включая толщину лако-красочного покрытия. Известны случаи, когда авто при логистике повреждали, покоцанную деталь красили, и выдавали новый авто со вторичным окрасом. Одолжил ему свой толщиномер. Друг вернулся в замешательстве - вся машина покрашена нормально (120-150 мкм), а одно крыло - под 300! Налицо вторичный окрас. Пошел он с продавцом по парковке смотреть другие экземпляры. И вы не поверите - у всех машин этой модели переднее левое крыло бьется в 300 микрон. Это вообще как? Науке сие пока неизвестно. Китайские нано-технологии, не иначе.
Мораль. Гарантия - хорошо. Повод ей воспользоваться - уже не очень хорошо. Китайский автопром - совсем плохо.
💯11❤4
55.973146, 37.414863: Как починить "перебрасывание" геопозиции в iOS без регистрации и смс
Жители крупных городов России в последнее время частенько страдают от "перебрасывания" геопозиции в различных приложениях. Например, в Шереметьево. Это сильно мешает - навигатор бессилен, погоду ты видишь в Химках, даже еду заказать сложнее.
Сегодня я вам на примере iOS расскажу, как сделать так, чтобы ваша геопозиция отображалась абсолютно корректно. Для этого даже не потребуется jailbreak и сторонние приложения.
Достаточно лишь
.
.
.
поехать в Шереметьево. (фьюить-ха!)
И, вуаля, телефон начинает корректно показывать ваше местоположение.
Ну как с теми остановившимися часами, которые продолжают дважды в сутки показывать абсолютно точное время.
(Навеяно фразой жены на пути в отпуск - "о, зато навигатор не врет" по прибытии в Шарик)
А если знаете другие способы - прошу в комменты.
Жители крупных городов России в последнее время частенько страдают от "перебрасывания" геопозиции в различных приложениях. Например, в Шереметьево. Это сильно мешает - навигатор бессилен, погоду ты видишь в Химках, даже еду заказать сложнее.
Сегодня я вам на примере iOS расскажу, как сделать так, чтобы ваша геопозиция отображалась абсолютно корректно. Для этого даже не потребуется jailbreak и сторонние приложения.
Достаточно лишь
.
.
.
поехать в Шереметьево. (фьюить-ха!)
И, вуаля, телефон начинает корректно показывать ваше местоположение.
Ну как с теми остановившимися часами, которые продолжают дважды в сутки показывать абсолютно точное время.
(Навеяно фразой жены на пути в отпуск - "о, зато навигатор не врет" по прибытии в Шарик)
А если знаете другие способы - прошу в комменты.
🤣9
Надежность: реагирование
Продолжаем разбор стратегии надежности .
Ранее уже писал про
повышение надежности релизов и про
предотвращение инцидентов из-за потенциально известных проблем.
Сегодня - про реагирование на инциденты. Бывает такое - катишь взрывоопасный релиз и чувствуешь - вот-вот бахнет. Палец уже на кнопке отката, один глаз смотрит на деплой, другой - на дашборд. Тут вроде все понятно. Поэтому смотрим на все остальные ситуации.
У вас точно есть алерты. Много разных - на все случаи жизни. И сервисов тоже много, мы же делаем сложную распределенную систему. А там еще базы и балансеры - у них тоже ведро алертов. Само собой, при таком многообразии сигналов какой-то из них вот-вот да и вспыхнет. Но вы-то не первый день тут, вы пуганный. Ну загорелся какой-то алерт, делов. Вы наметанным глазом понимаете, что это не крит. А соседний алерт горит уже неделю, там известная проблема, не аффектящая пользователей, так что не страшно. Третий - уже давно замьючен, потому что фолсил. Так и живем.
А не надо так. Привычное игнорирование некритичных алертов приводит к слепоте - вы не отличите крит от не-крита. Уже горящий алерт ярче не загорится, если системе станет реально хуже. Замьюченный - тем более. Вы летите без приборов и узнаете об инциденте из газет. Поэтому нужно держать высокий alerts uptime (доля времени, когда не горит ни один алерт, должна приближаться к желаемому аптайму системы в целом - 99.??). А еще полезно визуализировать это в виде полотна с плитками, где каждый не-зеленый кусочек должен вас искренне триггерить. Некритичные алерты нужно перенаправить куда-то в отдельный диагностический канал, а реально критичные - настроить так, чтобы их невозможно было не заметить.
Аналогия из автомобильного мира - лампочка check-engine (она же джеки-чан, она же мясорубка). Не понимаю людей, которые ездят с ней годами. Даже если зажглась она из-за ерунды, вы пропустите индикацию реально важной поломки. А заклеивают чек только перекупы. Я же на некоторых авто каждое утро начинал с подключения обд-сканера (elm) и сброса некритичных ошибок.
А что еще можно сделать, чтобы критичный алерт невозможно было бы не заметить? Во-первых, настроить хорошо эскалацию. В том числе телефонную. Чтобы если дежурный проспал, робот точно дозвонился бы до запасных персонажей вплоть до CTO. Во-вторых, автоматика должна инициировать протокол - создать чат, призвать дежурных, задать нужные вопросы. А если дежурный не пришел в протокольный чат - повысить северити инцидента и снова его эскалировать, включая уведомление в общие каналы коммуникаций, потому что что-то уже явно идет не так.
И про клиенты. У вас было такое, что по сигналам бекенда все хорошо, а фича не работает? Либо бек отдает 200 OK с пустым телом, либо схема ответа не соответствует контракту, причин масса. А приложению что-то не нравится. Тут главное - чтобы на клиенте это была не одна ошибка вида "ой, что-то пошло не так", а что-то осмысленное, с отправкой метрик и алертингом на них. Также стоит следить не только за синтаксическими, но и за семантическими ошибками. Например, синтаксически корректная, но пустая выдача - тоже сигнал.
Здоровья вашим сервисам, а если что-то все же бомбанет - не проморгайте. И не слепните.
Продолжаем разбор стратегии надежности .
Ранее уже писал про
повышение надежности релизов и про
предотвращение инцидентов из-за потенциально известных проблем.
Сегодня - про реагирование на инциденты. Бывает такое - катишь взрывоопасный релиз и чувствуешь - вот-вот бахнет. Палец уже на кнопке отката, один глаз смотрит на деплой, другой - на дашборд. Тут вроде все понятно. Поэтому смотрим на все остальные ситуации.
У вас точно есть алерты. Много разных - на все случаи жизни. И сервисов тоже много, мы же делаем сложную распределенную систему. А там еще базы и балансеры - у них тоже ведро алертов. Само собой, при таком многообразии сигналов какой-то из них вот-вот да и вспыхнет. Но вы-то не первый день тут, вы пуганный. Ну загорелся какой-то алерт, делов. Вы наметанным глазом понимаете, что это не крит. А соседний алерт горит уже неделю, там известная проблема, не аффектящая пользователей, так что не страшно. Третий - уже давно замьючен, потому что фолсил. Так и живем.
А не надо так. Привычное игнорирование некритичных алертов приводит к слепоте - вы не отличите крит от не-крита. Уже горящий алерт ярче не загорится, если системе станет реально хуже. Замьюченный - тем более. Вы летите без приборов и узнаете об инциденте из газет. Поэтому нужно держать высокий alerts uptime (доля времени, когда не горит ни один алерт, должна приближаться к желаемому аптайму системы в целом - 99.??). А еще полезно визуализировать это в виде полотна с плитками, где каждый не-зеленый кусочек должен вас искренне триггерить. Некритичные алерты нужно перенаправить куда-то в отдельный диагностический канал, а реально критичные - настроить так, чтобы их невозможно было не заметить.
Аналогия из автомобильного мира - лампочка check-engine (она же джеки-чан, она же мясорубка). Не понимаю людей, которые ездят с ней годами. Даже если зажглась она из-за ерунды, вы пропустите индикацию реально важной поломки. А заклеивают чек только перекупы. Я же на некоторых авто каждое утро начинал с подключения обд-сканера (elm) и сброса некритичных ошибок.
А что еще можно сделать, чтобы критичный алерт невозможно было бы не заметить? Во-первых, настроить хорошо эскалацию. В том числе телефонную. Чтобы если дежурный проспал, робот точно дозвонился бы до запасных персонажей вплоть до CTO. Во-вторых, автоматика должна инициировать протокол - создать чат, призвать дежурных, задать нужные вопросы. А если дежурный не пришел в протокольный чат - повысить северити инцидента и снова его эскалировать, включая уведомление в общие каналы коммуникаций, потому что что-то уже явно идет не так.
И про клиенты. У вас было такое, что по сигналам бекенда все хорошо, а фича не работает? Либо бек отдает 200 OK с пустым телом, либо схема ответа не соответствует контракту, причин масса. А приложению что-то не нравится. Тут главное - чтобы на клиенте это была не одна ошибка вида "ой, что-то пошло не так", а что-то осмысленное, с отправкой метрик и алертингом на них. Также стоит следить не только за синтаксическими, но и за семантическими ошибками. Например, синтаксически корректная, но пустая выдача - тоже сигнал.
Здоровья вашим сервисам, а если что-то все же бомбанет - не проморгайте. И не слепните.
Игра с ненулевой суммой
Каждый день мы принимаем решения. Почти в каждом решении есть риск. У решения возможен положительный или отрицательный исход. И даже если исходы равновероятны, а выгода при положительном исходе больше потерь при отрицательном, мы интуитивно стремимся избежать принятия решения или принимаем решение по умолчанию.
Простой пример: вам предлагают подбросить монетку. Орел - вам дают 2000 рублей. Решка - у вас забирают 1000. Вроде бы, статистически, надо играть. Но перспектива расстаться с тысячей рублей как-то не радует, и вы, скорее всего, откажетесь. Дело в неприятии потерь - мы склонны интуитивно увеличивать вес потерь относительно выгоды.
Однако, если предложить вам 20 раз подряд сыграть в эту игру, вы наверняка согласитесь. Потому что вероятность остаться в минусе сокращается до морально-приемлемых ~13%, что перекрывается средним ожидаемым выигрышем в 10 000 рублей. Хотя броски монетки независимы, и каждая итерация игры осталась та же. Но вы расширили рамки и оперируете рисками в более широких рамках.
Так же и с инвестициями в ценные бумаги - если заглядывать в котировки каждый день, вы будете расстраиваться от мелких просадок, а умеренному росту будете радоваться меньше. И будет больше зуда перетряхнуть свой портфель. А если открывать брокера пореже - колебания сгладятся и вы будете видеть более объективную картину.
В работе, на самом деле, та же история. Если перед вами стоит рискованный выбор (технический, финансовый, управленческий), вам будет тяжело на него пойти, даже если вероятность успеха высока. Потому что в случае провала вам будет больно. Но в масштабе компании, если каждая из 20 команд пойдет на этот риск, компания в сумме выиграет.
Смотрите не только на обстоятельства конкретной ситуации, но и на статистику результатов схожих ситуаций. Сторонний взгляд и политика рисков - средства больбы с искажениями, влияющими на многие решения: чрезмерным оптимизмом ошибки планирования и излишней осторожностью непринятия риска. Эти два искажения противостоят друг другу. Чрезмерный оптимизм уберегает нас от парализующего воздействия неприятия потерь, которое, в свою очередь, защищает от последствий неуемного оптимизма.
Не нужно обдумывать каждое решение как единственное - расширяйте рамки и оперируйте портфелем в целом и на дистанции.
(Не является инвестиционной рекомендацией. Автор не поощряет азартные игры. Мотивационный питч, направленный на построение аналогий с принятием профессиональных или бытовых решений. Инспирировано книгой Даниэля Канемана.)
Каждый день мы принимаем решения. Почти в каждом решении есть риск. У решения возможен положительный или отрицательный исход. И даже если исходы равновероятны, а выгода при положительном исходе больше потерь при отрицательном, мы интуитивно стремимся избежать принятия решения или принимаем решение по умолчанию.
Простой пример: вам предлагают подбросить монетку. Орел - вам дают 2000 рублей. Решка - у вас забирают 1000. Вроде бы, статистически, надо играть. Но перспектива расстаться с тысячей рублей как-то не радует, и вы, скорее всего, откажетесь. Дело в неприятии потерь - мы склонны интуитивно увеличивать вес потерь относительно выгоды.
Однако, если предложить вам 20 раз подряд сыграть в эту игру, вы наверняка согласитесь. Потому что вероятность остаться в минусе сокращается до морально-приемлемых ~13%, что перекрывается средним ожидаемым выигрышем в 10 000 рублей. Хотя броски монетки независимы, и каждая итерация игры осталась та же. Но вы расширили рамки и оперируете рисками в более широких рамках.
Так же и с инвестициями в ценные бумаги - если заглядывать в котировки каждый день, вы будете расстраиваться от мелких просадок, а умеренному росту будете радоваться меньше. И будет больше зуда перетряхнуть свой портфель. А если открывать брокера пореже - колебания сгладятся и вы будете видеть более объективную картину.
В работе, на самом деле, та же история. Если перед вами стоит рискованный выбор (технический, финансовый, управленческий), вам будет тяжело на него пойти, даже если вероятность успеха высока. Потому что в случае провала вам будет больно. Но в масштабе компании, если каждая из 20 команд пойдет на этот риск, компания в сумме выиграет.
Смотрите не только на обстоятельства конкретной ситуации, но и на статистику результатов схожих ситуаций. Сторонний взгляд и политика рисков - средства больбы с искажениями, влияющими на многие решения: чрезмерным оптимизмом ошибки планирования и излишней осторожностью непринятия риска. Эти два искажения противостоят друг другу. Чрезмерный оптимизм уберегает нас от парализующего воздействия неприятия потерь, которое, в свою очередь, защищает от последствий неуемного оптимизма.
Не нужно обдумывать каждое решение как единственное - расширяйте рамки и оперируйте портфелем в целом и на дистанции.
(Не является инвестиционной рекомендацией. Автор не поощряет азартные игры. Мотивационный питч, направленный на построение аналогий с принятием профессиональных или бытовых решений. Инспирировано книгой Даниэля Канемана.)
👍11😁1
Буткемп, или как не толкаться локтями при найме
Предположим, есть 5 смежных команд. И в каждой есть вакансия C++-разработчика (или ios/android/web/qa - не суть, лишь бы одинаковые). Команды в целом схожи, просто за разные части системы отвечают. А значит, требования к кандидатам у них тоже плюс-минус одинаковые - стек, опыт, профиль.
Если каждая команда (в лице нанимающего менеджера (далее - НМ), то есть, чаще всего, тимлида) будет активно нанимать себе человека сама, будет бардак. НМ будут толкаться локтями, конкурируя за одних и тех же кандидатов. У кандидатов будет слишком широкий выбор, который сложно сделать, не владея исчерпывающей информацией об этих командах, и чем они отличаются.
На помощь приходит подход под названием буткемп. Сама идея не нова, но почему-то мало кто в это идет. А мы пошли. И, кажется, получается хорошо. Вместо того, чтобы наперебой впятером продавать свои команды, НМ объединяются в процесс, где вся структура выступает единым фронтом. Мы предлагаем кандидату не 5 команд на выбор, а одну позицию - в буткемп Яндекс Еды.
Найм ведет какой-то один НМ (достаточно опытный и взрослый) при содействии лидеров соответствующих компетенций (о том, что это за зверь - расскажу отдельно). Мы предлагаем кандидату просто прийти в Еду, и за первые пару месяцев поработать по паре недель в нескольких командах (3-4, команды в графике ротируются для равномерности получения буткемперов). За это время новичок точно сможет понять, в какой команде ему больше понравилось. А команды смогут понять, где у кандидата лучше пошел процесс. Где больше фит.
В итоге, смотрим, какие команды "зашли" буткемперу. В каких командах "зашел" буткемпер. Пересекаем множества - там он и останется. Иногда для этого даже не обязательно проходить все 4 команды - по согласованию можно остановить перебор раньше (но хотя бы 2 команды точно нужно пройти).
Что мы с этого получаем?
- Проще "продавать" кандидатам компанию в целом, чем конкретную команду
- Меньше финальных секций - экономия времени и для НМ, и для кандидата
- Более осознанный выбор с обеих сторон, двухнедельный "тест-драйв" точно информативней, чем часовая встреча.
- Простите мне мой цинизм, но это тоже важно: отказаться от буткемпера морально проще, чем уволить человека с испыталки. А если новичок действительно не заходит / не тянет, то для компании вредно продолжать тянуть его из малодушия.
В этом году у нас через буткемп прошло примерно два десятка новичков. Почти все смогли найти "свою" команду (кажется, лишь один человек не получил фит ни от одной команды). Отзывы участников процесса - сугубо положительные. Штука-то рабочая!
Можете сделать так же у себя. А можете попробовать у нас - https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)
Предположим, есть 5 смежных команд. И в каждой есть вакансия C++-разработчика (или ios/android/web/qa - не суть, лишь бы одинаковые). Команды в целом схожи, просто за разные части системы отвечают. А значит, требования к кандидатам у них тоже плюс-минус одинаковые - стек, опыт, профиль.
Если каждая команда (в лице нанимающего менеджера (далее - НМ), то есть, чаще всего, тимлида) будет активно нанимать себе человека сама, будет бардак. НМ будут толкаться локтями, конкурируя за одних и тех же кандидатов. У кандидатов будет слишком широкий выбор, который сложно сделать, не владея исчерпывающей информацией об этих командах, и чем они отличаются.
На помощь приходит подход под названием буткемп. Сама идея не нова, но почему-то мало кто в это идет. А мы пошли. И, кажется, получается хорошо. Вместо того, чтобы наперебой впятером продавать свои команды, НМ объединяются в процесс, где вся структура выступает единым фронтом. Мы предлагаем кандидату не 5 команд на выбор, а одну позицию - в буткемп Яндекс Еды.
Найм ведет какой-то один НМ (достаточно опытный и взрослый) при содействии лидеров соответствующих компетенций (о том, что это за зверь - расскажу отдельно). Мы предлагаем кандидату просто прийти в Еду, и за первые пару месяцев поработать по паре недель в нескольких командах (3-4, команды в графике ротируются для равномерности получения буткемперов). За это время новичок точно сможет понять, в какой команде ему больше понравилось. А команды смогут понять, где у кандидата лучше пошел процесс. Где больше фит.
В итоге, смотрим, какие команды "зашли" буткемперу. В каких командах "зашел" буткемпер. Пересекаем множества - там он и останется. Иногда для этого даже не обязательно проходить все 4 команды - по согласованию можно остановить перебор раньше (но хотя бы 2 команды точно нужно пройти).
Что мы с этого получаем?
- Проще "продавать" кандидатам компанию в целом, чем конкретную команду
- Меньше финальных секций - экономия времени и для НМ, и для кандидата
- Более осознанный выбор с обеих сторон, двухнедельный "тест-драйв" точно информативней, чем часовая встреча.
- Простите мне мой цинизм, но это тоже важно: отказаться от буткемпера морально проще, чем уволить человека с испыталки. А если новичок действительно не заходит / не тянет, то для компании вредно продолжать тянуть его из малодушия.
В этом году у нас через буткемп прошло примерно два десятка новичков. Почти все смогли найти "свою" команду (кажется, лишь один человек не получил фит ни от одной команды). Отзывы участников процесса - сугубо положительные. Штука-то рабочая!
Можете сделать так же у себя. А можете попробовать у нас - https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)
Лидеры компетенций
Пару лет назад мы перешли от функциональных команд к кроссфункциональным. Не самый простой переход, скажу я вам, и про одну из проблем и ее решение хочется рассказать. Тем более, что, кажется, прошло-то хорошо.
В классической функциональной команде (например, команде ios-разработки), все понятно - все делают примерно одно и то же (в плане специализации), и есть руководитель, который, скорее всего, сам вырос из той же профессии. Значит, он один из самых опытных и скиллованных разработчиков. И это ему, как руководителю, позволяет быть для своей команды не только пипл-менеджером, но и техническим наставником.
Далее мы трансформируем команды. Теперь в каждой группе есть, например, 2 бекендера, 1 ios-разработчик, 1 андроид, 1 веб, 1 куа. И тимлид. Предположим, тимлид в прошлом - бекендер. Возникает вопрос - а как он может быть техническим наставникам тем четверым, чьих профессий у него в анамнезе нет? Кто будет технически развивать этих ребят? Как он будет оценивать их работу? Кто поревьювит самый сложный пулл-реквест?
Так у нас появился институт лидеров компетенций (competence lead). CL - это роль, подразумевающая технологическое лидерство и наставничество в пределах той или иной профессии над некоторым числом разработчиков из нескольких команд. Многие из них прежде были как раз руководителями функциональных команд в тех же профессиях. Как правило, это не фулл-тайм занятость - большинство CL это сеньоры и тимлиды кроссфункциональных команд, совмещающие свои структурные обязанности с ролью CL. Прямого струкрурного влияния на подопечных у них нет, но есть технический авторитет и признание.
Что же именно делают лидеры компетенций?
- работают с подопечными 1 на 1 и помогают им расти и развиваться профессионально
- участвуют в найме и оценке сотрудников на перформанс-ревью
- ставят и ведут техноцели, распределяют их на подопечных, развивают архитектуру, внедряют новое
- реализуют принципы technical excellence в своей зоне ответственности
- обеспечивают обмен знаниями по платформе и продукту
и многое другое.
Для пущей структурности и организованности есть также некоторая иерархия - существуют шеф-лиды компетенций (chief competence lead, CSL), по одному на каждую функцию. Они консолидируют экспертизу и ведут комплексные, сквозные проекты. Координируют лидеров компетенций разных частей компании. Формируют повестку и направляют стратегию технологического развития своей функции. В общем, главные по своим областям.
Итого, проблема технического наставничества решена, технопроекты существуют и выполняются, инженерная культура не страдает, а кроссфункциональные команды эффективней классических. Вроде, получилось хорошо.
Пару лет назад мы перешли от функциональных команд к кроссфункциональным. Не самый простой переход, скажу я вам, и про одну из проблем и ее решение хочется рассказать. Тем более, что, кажется, прошло-то хорошо.
В классической функциональной команде (например, команде ios-разработки), все понятно - все делают примерно одно и то же (в плане специализации), и есть руководитель, который, скорее всего, сам вырос из той же профессии. Значит, он один из самых опытных и скиллованных разработчиков. И это ему, как руководителю, позволяет быть для своей команды не только пипл-менеджером, но и техническим наставником.
Далее мы трансформируем команды. Теперь в каждой группе есть, например, 2 бекендера, 1 ios-разработчик, 1 андроид, 1 веб, 1 куа. И тимлид. Предположим, тимлид в прошлом - бекендер. Возникает вопрос - а как он может быть техническим наставникам тем четверым, чьих профессий у него в анамнезе нет? Кто будет технически развивать этих ребят? Как он будет оценивать их работу? Кто поревьювит самый сложный пулл-реквест?
Так у нас появился институт лидеров компетенций (competence lead). CL - это роль, подразумевающая технологическое лидерство и наставничество в пределах той или иной профессии над некоторым числом разработчиков из нескольких команд. Многие из них прежде были как раз руководителями функциональных команд в тех же профессиях. Как правило, это не фулл-тайм занятость - большинство CL это сеньоры и тимлиды кроссфункциональных команд, совмещающие свои структурные обязанности с ролью CL. Прямого струкрурного влияния на подопечных у них нет, но есть технический авторитет и признание.
Что же именно делают лидеры компетенций?
- работают с подопечными 1 на 1 и помогают им расти и развиваться профессионально
- участвуют в найме и оценке сотрудников на перформанс-ревью
- ставят и ведут техноцели, распределяют их на подопечных, развивают архитектуру, внедряют новое
- реализуют принципы technical excellence в своей зоне ответственности
- обеспечивают обмен знаниями по платформе и продукту
и многое другое.
Для пущей структурности и организованности есть также некоторая иерархия - существуют шеф-лиды компетенций (chief competence lead, CSL), по одному на каждую функцию. Они консолидируют экспертизу и ведут комплексные, сквозные проекты. Координируют лидеров компетенций разных частей компании. Формируют повестку и направляют стратегию технологического развития своей функции. В общем, главные по своим областям.
Итого, проблема технического наставничества решена, технопроекты существуют и выполняются, инженерная культура не страдает, а кроссфункциональные команды эффективней классических. Вроде, получилось хорошо.
👍16
big tech night
Кстати, сегодня конфа big tech night. Программа довольно интересная.
Там и онлайн будет https://bigtechnight.ru/online/ - если не попали на оффлайн. Если еще не решили, чем занять вечер пятницы - вариант.
Кто будет в Красной Розе - при желании можем увидеться, я буду там нетворкаться где-то в районе стенда Городских Сервисов Яндекса.
Кстати, сегодня конфа big tech night. Программа довольно интересная.
Там и онлайн будет https://bigtechnight.ru/online/ - если не попали на оффлайн. Если еще не решили, чем занять вечер пятницы - вариант.
Кто будет в Красной Розе - при желании можем увидеться, я буду там нетворкаться где-то в районе стенда Городских Сервисов Яндекса.
🔥11❤1
Надежность: импакт
Завершу цикл постов с разбором стратегии надежности несколькими мыслями про минимизацию ущерба.
В предыдущих сериях:
- повышение надежности релизов
- предотвращение инцидентов из-за потенциально известных проблем
- реагирование
Ущерб от инцидента можно снизить двумя способами - быстрее купировать проблему, либо переключиться в режим деградации.
Так как существенная доля инцидентов является прямым следствием какого-то релиза, проще всего просто как можно быстрее откатить этот релиз. Однако, при всей кажущейся очевидности и простоте этого правила, ему хронически не следуют. Вы не представляете, сколько раз на разборах инцидентов я повторял команде мантру "Сначала откатывай, потом думай". Один коллега даже набил себе татуировку с этим текстои на руке. Помогло ли? Нет. Вывод - единственный надежный способ - автоматизировать этот процесс. Посмотрим, спасут ли автооткаты.
Вообще действия лиц, принимающих участие в починке какого-то конкретного инцидента, зачастую нелогичы, неорганизованны, несвоевременны. Иногда из-за нехватки опыта, иногда из-за несобранности или волнения. Надо им с этим помогать. Например, проводить учения по восстановлению сервиса, чтобы типовые действия были знакомы, или даже доведены до автоматизма. Тем же способом можно развивать фантазию - один участник как-то неочевидно ломает сервис (лучше в тестинге), другой - ищет проблему. Ну и также полезно иметь быстродоступные, короткие и очень понятные инструкции на случай типовых поломок каждого компонента - фолбеки, рубильники, кейсы.
У вас было такое, что очень понятно, как чинить, но оно происходит настолько долго, что вы можете лишь со слезами на глазах наблюдать агонию сервиса и тщетные попытки пользователей что-то от него получить? Даже если вы молниеносно среагировали на четко сработавший алерт и, не мешкая, прожали откат, иногда вы будете следующие пару часов биться в бессильной злобе, потому что сервис стартует очень долго. Например, потому что насасывает инмемори-кеши, без которых не может работать в рантайме. А еще может запрос-убийца пройтись по всем подам, свалив их в корку, а подниматься они будут дольше, чем стоило бы. Даже простая операция докидывания подов под внезапный рост нагрузки превращается в гонки со смертью. Старайтесь оптимизировать старт своих сервисов.
Ну и, наконец, упомяну всевозможные "тыквы" - режимы продуктовой или технической деградации, которые активируются в случае проблем, и позволяют сохранить хотя бы какую-то работоспособность (или даже видимость работоспособности) сервиса. Грубо говоря, если в выдаче Еды будут не все сотни/тысячи ресторанов, которые штатно могут привезти вам покушать, а хотя бы 50 более-менее высоко-ранжируемых, почти никто ничего не заметит. А половина аудитории останется сыта и довольна, если хотя бы показать мак и тануки. Какие именно режимы деградации реализовать, зависит исключительно от вашей фантазии (и одобрения от продукта и бизнеса). Но чаще всего лучше работать как-то, чем никак.
Вывод - купируйтесь и деградируйте. Хотя странно звучит, забейте.
Завершу цикл постов с разбором стратегии надежности несколькими мыслями про минимизацию ущерба.
В предыдущих сериях:
- повышение надежности релизов
- предотвращение инцидентов из-за потенциально известных проблем
- реагирование
Ущерб от инцидента можно снизить двумя способами - быстрее купировать проблему, либо переключиться в режим деградации.
Так как существенная доля инцидентов является прямым следствием какого-то релиза, проще всего просто как можно быстрее откатить этот релиз. Однако, при всей кажущейся очевидности и простоте этого правила, ему хронически не следуют. Вы не представляете, сколько раз на разборах инцидентов я повторял команде мантру "Сначала откатывай, потом думай". Один коллега даже набил себе татуировку с этим текстои на руке. Помогло ли? Нет. Вывод - единственный надежный способ - автоматизировать этот процесс. Посмотрим, спасут ли автооткаты.
Вообще действия лиц, принимающих участие в починке какого-то конкретного инцидента, зачастую нелогичы, неорганизованны, несвоевременны. Иногда из-за нехватки опыта, иногда из-за несобранности или волнения. Надо им с этим помогать. Например, проводить учения по восстановлению сервиса, чтобы типовые действия были знакомы, или даже доведены до автоматизма. Тем же способом можно развивать фантазию - один участник как-то неочевидно ломает сервис (лучше в тестинге), другой - ищет проблему. Ну и также полезно иметь быстродоступные, короткие и очень понятные инструкции на случай типовых поломок каждого компонента - фолбеки, рубильники, кейсы.
У вас было такое, что очень понятно, как чинить, но оно происходит настолько долго, что вы можете лишь со слезами на глазах наблюдать агонию сервиса и тщетные попытки пользователей что-то от него получить? Даже если вы молниеносно среагировали на четко сработавший алерт и, не мешкая, прожали откат, иногда вы будете следующие пару часов биться в бессильной злобе, потому что сервис стартует очень долго. Например, потому что насасывает инмемори-кеши, без которых не может работать в рантайме. А еще может запрос-убийца пройтись по всем подам, свалив их в корку, а подниматься они будут дольше, чем стоило бы. Даже простая операция докидывания подов под внезапный рост нагрузки превращается в гонки со смертью. Старайтесь оптимизировать старт своих сервисов.
Ну и, наконец, упомяну всевозможные "тыквы" - режимы продуктовой или технической деградации, которые активируются в случае проблем, и позволяют сохранить хотя бы какую-то работоспособность (или даже видимость работоспособности) сервиса. Грубо говоря, если в выдаче Еды будут не все сотни/тысячи ресторанов, которые штатно могут привезти вам покушать, а хотя бы 50 более-менее высоко-ранжируемых, почти никто ничего не заметит. А половина аудитории останется сыта и довольна, если хотя бы показать мак и тануки. Какие именно режимы деградации реализовать, зависит исключительно от вашей фантазии (и одобрения от продукта и бизнеса). Но чаще всего лучше работать как-то, чем никак.
Вывод - купируйтесь и деградируйте. Хотя странно звучит, забейте.
👍14❤2🔥1
Найм зумеров в эпоху вайб-кодинга
Разгоняли тут с Женей Кадомец про трудности найма в наше неспокойное время перегретого рынка, необоснованных зарплатных ожиданий и злоупотребления ИИшкой.
(https://t.me/jeny_ka - подпишитесь! Там про рекрутмент, карьеру, тренды и котиков)
Женя была рекрутером моей команды уже почти 10 лет назад (страшно подумать), а сейчас она руководит рекрутментом в Финтехе Яндекса.
Решили тут с ней посмотреть с разных сторон на один вопрос.
Я - со стороны нанимающего менеджера, Женя - со стороны рекрутмента.
Моя точка зрения, конечно, важнее ;) Ей-то надо лишь найти человека, а мне с ним еще годами работать.
А вопрос в том, как нынче нанимать толковых ребят, если каждый первый третьекурсник величает себя сеньором и хочет зарплату в 300 тысяч в секунду, притом некоторые компании готовы им такие деньги предложить (видимо, потому что иначе к ним никто не пойдет - больше им брать нечем). Каждый второй хочет вайбкодить, а каждый третий и вовсе пытается заабьюзить технические секции с помощью гпт.
Все меньше молодых ребят готовы учиться и вкладываться в свой профессиональный уровень - все хотят "как проще", а не "как надо". Возможно, если посмотреть на верх воронки, окажется, что и раньше 90% кандидатов были очень слабые. А остальные 10% мотивированных и способных ребят так и остались. Просто раньше их было проще отделить (10 лет назад предварительную секцию с кодом заваливало больше половины кандидатов, сейчас - меньше половины), потому что современные технологии помогают обмануть систему хотя бы на ранних этапах.
Раньше, без гпт, да к тому же на очных собесах с написанием кода на листочке, было сразу понятно, что человек может. Но я не хочу нанимать того, кто без гпт ничего не может. И пусть он потом в работе этот гпт использует в хвост и в гриву (лишь бы не в ущерб качеству), но важно, чтобы он и без гпт мог все то же самое.
Если разработчик может в чистом поле, без всяких ассистентов, хорошо алгоритмически мыслить и решать задачи, то он сможет и искусственный интеллект применять с умом, как инструмент повышения своей эффективности, а не как компенсацию нехватки естественного интеллекта.
Я считаю, что искать нужно в первую очередь мотивированных инженеров. Тех, для кого программирование - не только способ заработка, но и страсть. Тех, кто получает удовольствие от процесса, а не только по 5-м и 20-м. Кто любит технологии и готов много учиться. Кому интересно развивать инструменты, а не просто использовать их.
И такие ребята точно есть. Нужно только их найти. И один из рабочих способов - это растить их со стажеров. Этим тоже усиленно занимаемся. Кстати, недавно смотрели скорость роста до мидл+ - у бывших стажеров она значимо выше.
Женя, в свою очередь, имеет куда больше понимания рынка найма и верхней части воронки разработчиков. Она считает, что зумеров-вайбкодеров нужно просто научиться "правильно готовить". Но об этом - в ее посте.
Разгоняли тут с Женей Кадомец про трудности найма в наше неспокойное время перегретого рынка, необоснованных зарплатных ожиданий и злоупотребления ИИшкой.
(https://t.me/jeny_ka - подпишитесь! Там про рекрутмент, карьеру, тренды и котиков)
Женя была рекрутером моей команды уже почти 10 лет назад (страшно подумать), а сейчас она руководит рекрутментом в Финтехе Яндекса.
Решили тут с ней посмотреть с разных сторон на один вопрос.
Я - со стороны нанимающего менеджера, Женя - со стороны рекрутмента.
Моя точка зрения, конечно, важнее ;) Ей-то надо лишь найти человека, а мне с ним еще годами работать.
А вопрос в том, как нынче нанимать толковых ребят, если каждый первый третьекурсник величает себя сеньором и хочет зарплату в 300 тысяч в секунду, притом некоторые компании готовы им такие деньги предложить (видимо, потому что иначе к ним никто не пойдет - больше им брать нечем). Каждый второй хочет вайбкодить, а каждый третий и вовсе пытается заабьюзить технические секции с помощью гпт.
Все меньше молодых ребят готовы учиться и вкладываться в свой профессиональный уровень - все хотят "как проще", а не "как надо". Возможно, если посмотреть на верх воронки, окажется, что и раньше 90% кандидатов были очень слабые. А остальные 10% мотивированных и способных ребят так и остались. Просто раньше их было проще отделить (10 лет назад предварительную секцию с кодом заваливало больше половины кандидатов, сейчас - меньше половины), потому что современные технологии помогают обмануть систему хотя бы на ранних этапах.
Раньше, без гпт, да к тому же на очных собесах с написанием кода на листочке, было сразу понятно, что человек может. Но я не хочу нанимать того, кто без гпт ничего не может. И пусть он потом в работе этот гпт использует в хвост и в гриву (лишь бы не в ущерб качеству), но важно, чтобы он и без гпт мог все то же самое.
Если разработчик может в чистом поле, без всяких ассистентов, хорошо алгоритмически мыслить и решать задачи, то он сможет и искусственный интеллект применять с умом, как инструмент повышения своей эффективности, а не как компенсацию нехватки естественного интеллекта.
Я считаю, что искать нужно в первую очередь мотивированных инженеров. Тех, для кого программирование - не только способ заработка, но и страсть. Тех, кто получает удовольствие от процесса, а не только по 5-м и 20-м. Кто любит технологии и готов много учиться. Кому интересно развивать инструменты, а не просто использовать их.
И такие ребята точно есть. Нужно только их найти. И один из рабочих способов - это растить их со стажеров. Этим тоже усиленно занимаемся. Кстати, недавно смотрели скорость роста до мидл+ - у бывших стажеров она значимо выше.
Женя, в свою очередь, имеет куда больше понимания рынка найма и верхней части воронки разработчиков. Она считает, что зумеров-вайбкодеров нужно просто научиться "правильно готовить". Но об этом - в ее посте.
❤26👍17💯5