Найти тему
Радио «Виктор»: пять плохих школьных уроков
Радио «Виктор»: пять плохих школьных уроков Сейчас снова стало модным, опираясь на теорию поколений, хвалить или ругать зумеров/миллениалов/бумеров. Я к этой концепции отношусь крайне скептически — ставлю её где-то между астрологией и питанием по группе крови. Не отрицаю, что могу ошибаться. Если принесёте в комментарии серьёзные исследования — с интересом почитаю. А вот система образования действительно, на мой взгляд, иногда учит не только хорошему, но и плохому. А потом это «плохое» в рабочем контексте выглядит как особенности поколения или просто как инфантилизм. Сегодня поделюсь наблюдениями:...
6 дней назад
Финансовая независимость: стать молодым пенсионером и жить в кайф
Финансовая независимость: стать молодым пенсионером и жить в кайф? Первый выпуск 8-го сезона начнём с темы, куда же деть все те огромные деньжища, которые мы, айтишники, зарабатываем в наносекунду, как многие считают 😏 Обсудим концепцию FIRE (с англ. Financial Independence, Retire Early) — финансовую независимость и раннюю пенсию. Базово определимся с понятием, попробуем в цифры — сколько нужно зарабатывать, откладывать и как жить. И затронем философский вопрос, как быть фаерщиком в российских реалиях...
1 неделю назад
Новый выпуск подкаста готов к публикации
Новый выпуск подкаста готов к публикации 🎙 Дорогие слушатели, рады сообщить: 8-й сезон подкаста «Кода кода» уже на старте. Мы готовы снова делиться с вами крутыми историями из жизни в IT. Цитируя классиков, пчела с новым выпуском на площадки к вам летит 🐝 Первый выпуск в эту среду! Вас ждут крутые гости, обсуждения актуальных тем, увлекательные истории и лайфхаки. Выходить будем традиционно по средам, раз в 2 недели...
1 неделю назад
Радио «Виктор»: преемник
Радио «Виктор»: преемник В комментариях к предыдущему посту был вопрос, на который отвечаю здесь. Немного контекста: в Озоне отдел — это несколько команд, а руководитель отдела — это тимлид тимлидов. Вопрос: Можешь рассказать, как ты искал преемника на своё место руководителя двух отделов? Не все управленческие задачи решаются «в лоб». Как только вы становитесь руководителем, один из первых (и самых незаметных) вопросов — а кто после меня? Преемник — это не всегда конкретный человек. В моем случае было два отдела, и у них почти не было общих проектов. Гораздо логичнее было найти и вырастить по одному кандидату в каждом...
1 неделю назад
Радио «Виктор»: Воля случая
Радио «Виктор»: Воля случая В продолжение темы профессионального развития хочется поговорить о карьерном росте. Сложно определить, что считать ростом, а что нет. Для одних главное мерило — сумма финансовой компенсации, для других — уровень управления или количество людей в подчинении. Меньшинство оценивает рост по запущенным проектам и степени влияния на мир. Проблема в том, что одно не всегда ведёт к другому. В моей карьере были моменты, когда мне давали больше команд, людей и проектов, но без повышения зарплаты. Или, наоборот, увеличивали доход, но зона влияния оставалась прежней. Поделитесь,...
2 недели назад
Радио «Виктор»: Не всё равно
Радио «Виктор»: Не всё равно В здоровой корпоративной культуре главный фактор профессионального развития — принцип «не всё равно». Под развитием я понимаю увеличение способностей продвигать проекты, выпускать продукты и выполнять задачи. Это настолько неочевидное качество, что для него даже нет отдельного слова — мы определяем его только через отрицание. Но на длинной дистанции это единственное, что действительно важно. Много лет назад, будучи джуном, я работал над сайтом интернет-магазина и занимался там ценообразованием. Логика формирования цены была сложной — алгоритм зависел от десятка вводных...
3 недели назад
Радио «Виктор»: Общая картина и детали Давно мечтал начать красить миниатюры. И вот, наконец, добрался попробовать. Открытием для меня стал ключевой принцип: гиперболизированно выделяй некоторые детали, потому что с «высоты» их только так и будет видно. Похожим образом гримируются актёры для большой сцены. Помните персонажа Пьеро из «Золотого ключика» — у него было белое лицо и одна большая слезинка. Вблизи это смотрелось смешно и нелепо, но на сцене, благодаря этому, его персонаж был понятен зрителю. При этом желание выделить все детали обречено на провал. Видели когда-нибудь китайские сайты 2010-х, где в каждом пикселе экрана мигает какой-то баннер? Всего настолько много, что ты не можешь сфокусироваться на чём-то одном. В детстве я так наряжал ёлку — пытался поместить на ней все-все игрушки, гирлянды, мишуру. Вблизи можно было рассмотреть каждую, и это было даже любопытно: от прабабушкиной Снегурочки до вчера подаренного шарика с переливающимися гранями. Но уже с расстояния в метр всё превращалось в кашу. Когда выделено всё — не выделено ничего. А что в работе? Ровно так же и в рабочих переговорах. Если вы обсуждаете крупный проект в широком составе, то плохо говорить о нём общими словами. Но так же плохо пытаться проговорить все детали. Правильный подход: выбрать заранее несколько важных ключевых деталей и их подсветить, оконтурить, выделить. А другие места обозначить и скрыть за общим фасадом. Таким образом, вы, с одной стороны, обозначите глубину проекта, подсветите какой-то ключевой риск или момент, который требует координации с рядом команд. С другой — не перегрузите собеседника подробностями. Выбор конкретных деталей сильно зависит от ситуации. Тем же принципом я руководствуюсь, когда хочу объяснить вклад человека в процессе перформанс-ревью. Некоторые мои коллеги пытаются рассказать максимум деталей: и о проектах, и об архитектуре, и о проблемах, которые были в реализации, и даже обосновать по дороге, зачем мы этим занимались. Это всегда выходит плохо — никто со стороны не готов воспринять такой объём информации по каждому коллеге. С другой стороны, слишком общие слова: «Вася — супер молодец» — тоже не дают достаточно, чтобы можно было принимать коллегиальные решения. А вот подход подчёркивания нескольких отдельных деталей позволяет обсудить и широту сделанного, и глубину.
1 месяц назад
Радио «Виктор»: Никаких неожиданностей Наверняка вы замечали, что новая полюбившаяся песня с каждым новым прослушиванием нравится нам всё больше и больше. Наш мозг обожает предсказывать и попадать в реальность. На этом принципе построена вся музыкальная гармония: как правило, нам подсовывают именно то, чего мы и так ждём. Но не в точности, иначе никакого предсказания бы не было. Это как теле-викторина — ее интересно смотреть, если ты можешь ответить на часть вопросов, но не на все. Идти по знакомой дороге быстрее и легче. Приятно читать книгу или смотреть фильм, построенный по знакомым канонам, но поданный по-новому. Если вам интересно разобраться в этих канонах, рекомендую книгу «Тысячеликий герой» Кэмпбелла и учебник гармонии Дубовского. Аналогичные принципы можно найти и в живописи, и, например, в кулинарии. Пробуя новое блюдо, вы опираетесь на весь свой предыдущий опыт и хотите, чтобы в нём было что-то знакомое. Но при этом и что-то новое тоже. UX и DX В UX работает точно так же. Мы знаем множество примеров, когда широкая аудитория не смогла принять слишком революционный продукт. Но зато легко влилась в него, когда была готова. Например, Яндексу пришлось даже откатить новый дизайн Кинопоиска под напором пользователей, хотя дизайн был крут и, в итоге, выкатился по частям. Отсюда, кстати, и ощущение в массовом сознании, что «раньше было лучше», ведь «разработчики всё время всё портят». Интереснее обстоит дело с DX (Developer Experience). С одной стороны, разработчики любят что-то новенькое. Ведь именно драйв от того, что ты в чём-то разобрался, — это то качество, которое многих привело в профессию. С другой стороны, многие новые вещи приходят не в дополнение к старому, а как его замена. И тут подключается боль от того, что старым, удобным, привычным и таким знакомым пользоваться больше нельзя. Или ещё хуже — нужно вложить кучу работы в обновление. И вся эта работа не принесёт нового драйва от запуска. При этом отсутствие изменений — тоже не знак качества. Даже лучшая компьютерная игра всех времен и народов «Герои меча и магии III» живет во многом благодаря команде энтузиастов, которые кое-что дорабатывают. Менеджмент Я очень стараюсь, чтобы на любой рабочей встрече была минимальная доля неожиданностей. Не стоит «держать что-то у себя», чтобы рассказать только в нужный момент. Встреча, на которой никто, кроме тебя, не знает, что произойдёт, точно окажется непродуктивной. Ещё хуже — пытаться сделать «приятный сюрприз для заказчика» или «придержать нашу главную фишку на потом». Это почти никогда не работает. Лучше с самого начала договариваться максимально подробно, а потом обсуждать необходимые изменения и дополнения так часто, как это возможно. Я представляю это как принцип часов: скорость стрелки всегда направлена по касательной, но движется она по дуге, потому что на неё действует ускорение. Оно действует постоянно и понемногу. Так, что стрелка, уверен, этого даже не замечает. Когда я был начинающим тимлидом, я нанял в команду разработчика, которым не был доволен с самого начала. У меня было к нему много претензий, но я всё думал про себя: «Вот-вот он войдёт в процесс, вот-вот станет попадать в сроки, вот-вот научится понимать, что я от него хочу». Стоит ли говорить, что когда я, наконец, выложил ему всё своё негодование, он был просто в шоке. Тогда вопрос: «А почему, Витя, ты мне раньше не говорил?» — поставил меня в тупик. Теперь я понимаю: нужно было давать обратную связь так часто, как я бы мог это сделать. И тогда, как и стрелки часов, мы вполне могли бы указывать вместе на нужную цифру в нужное время.
1 месяц назад
Радио «Виктор»: Иллюзия исключительности Мы часто считаем свою ситуацию исключительной. «Ну да, у других команд/проектов/компаний все решается по процессу, а у нас тут такой контекст, что эти процессы не подходят». Или: «Да, в учебниках пишут так, но в реальной жизни это не работает». Или даже: «Выше и ниже все решения, а у меня ничего». На самом деле, исключительными в чем-то являются абсолютно все люди, команды и проекты. Если по одному параметру вы попадаете в три сигмы нормального распределения, то вероятность того, что вы окажетесь в этом диапазоне по сотне параметров, стремится к нулю. Мы все уникальны, но это не значит, что к нам неприменимы общие подходы. Почему нужно вставать на общие рельсы? Да, у каждой команды могут быть свои особенности. Но единые подходы, инструменты и паттерны — это не о формальностях, а об эффективности. Это как с дорогами: можно ехать напрямик через поле, но шоссе с понятными правилами все равно быстрее и безопаснее. В одном из прошлых постов я уже писал, что стандартизация снижает риски. Каждый раз, когда мы делаем что-то «по-своему», мы создаем потенциальную проблему для будущих изменений. Когда исключение превращается в проблему Как-то я был свидетелем такой истории: аналитик строил дашборды для всех. Он имел доступ к базе данных и, когда нужно было что-то узнать, строил SQL-запрос, а не пользовался публичными дашбордами. В итоге, его дашборды были неудобными и безбожно тормозили, но он об этом не знал. Почему? Потому что он сам ими не пользовался. Такой «путь наименьшего сопротивления» привел к тому, что реальный продукт был бесполезным для других. Другая история (тоже выдуманная, конечно). Вся компания использовала общие пайплайны для деплоя. Но одна команда решила сделать свой, потому что их приложение было стейтфул и долго запускалось. В итоге при миграции в новый кубер-кластер всё пошло наперекосяк. Когда правила можно (и нужно) нарушать? Это не значит, что любые правила — это догма. Представьте, что вы можете ездить на красный свет, потому что у вас есть спецпропуск. Делать это в обычных условиях — социально безответственно. Но если за вами погоня или вы везете пострадавшего в больницу, то это оправдано. В других ситуациях вам стоит остановиться на красный. И даже заплатить штраф, если вы этого не сделали. Такой подход, кроме прочего, дает шанс на догфудинг — использование собственного продукта в реальных условиях. Если вы всегда обходите свои же процессы, вы теряете возможность их улучшить. Почему важно учитывать исключения? Каждое исключение — это потенциальная точка боли при любых изменениях. А изменения — это не вопрос «если», а вопрос «когда». Чем больше у вас собственных путей, тем сложнее будет миграция, настройка процессов или интеграция с другими системами. Вывод прост: исключительность — это не повод игнорировать общие правила. И если вам удаётся оставаться в рамках, не теряя при этом эффективности, то это не ограничение, а ваша настоящая суперсила.
1 месяц назад
Давайте станем ближе? Поделитесь, какую позицию вы занимаете и какой у вас уровень IT-шности. От вас — участие в опросе, от нас — полезный и захватывающий контент 🤝
1 месяц назад
Заглянем в бар? Вы помните, как мы, ваши бесценные ведущие Витя Корейша и Женя Антонов, пригласили Настю Абрашитову в бар? 🍸 Из экспериментального выпуска на ваших глазах вырос отдельный самостоятельный подкаст, в котором мы делимся управленческим опытом. Рассказываем истории, иногда спорим о том, как правильно поступить, иногда соглашаемся, но всегда учимся друг у друга и получаем удовольствие. В выпусках обсуждаем проблемы и вопросы, с которыми можно столкнуться на разных управленческих позициях в IT в разные периоды своей карьеры. Пока мы готовим новый сезон в «Кода кода», предлагаем послушать самый мёд из подкаста «Три тимлида заходят в бар». 1️⃣ Неприятные разговоры с сотрудниками — как проводить, чтобы не навредить? Про кондиционерные войны, гигиену, зависимости, громкие звуки, ссоры Ивана Ивановича и Ивана Никифоровича, противогаз, Чебурашку и многое другое. 2️⃣ Бесконечные встречи в календаре. Как не сойти с ума и успеть пообедать? База выживания в диких условиях — подготовка к встречам, модерация, фокус внимания, 2-3 встречи в один слот и то, как кукушечку держать при себе. 3️⃣ Тайм-менеджмент — как успевать срочное и не терять важное О борьбе с прокрастинацией, лайфхаках успеть всё (и не успеть тоже), навыке вести заметки во время встречи, дедлайнах своих и чужих. 4️⃣ Перфоманс ревью — объективная оценка или способ выжимания соков и формализм ради формализма? Субъективные оценки vs Объективные показатели, Польза vs Вред, Манипуляции vs Помощь своей команде. 5️⃣ Как тимлиду поменять работу и не сойти с ума Экзистенциальные вопросы — нужен ли ты кому-то, нужно ли делать карьерный шаг назад, что будет и как быть, если … Это не наш субъективный выбор, а аналитика и фидбэк слушателей. Наслаждайтесь и следите за новыми выпусками в телеграм-канале подкаста 👀
1 месяц назад
Радио «Виктор»: Собеседование — не допрос Договорённости о работе всегда предшествуют переговоры, и часть этих переговоров называется собеседованием. Наверняка вы видели мок-собеседования на YouTube, скорее всего, участвовали в найме со стороны собеседующей стороны и, конечно, проходили собеседования сами. И, вероятно, наблюдали или даже участвовали в таких собеседованиях, где одна сторона задаёт вопрос, получает на него ответ и... просто переходит к следующему вопросу. А потом мы читаем тысячи жалоб на то, что «спрашивали алгоритмы, а кому они нужны» или «меня полтора часа мучали кейсами, и я не знаю, хорошо ли я справился». При этом ничто не мешает собеседующему объяснить, почему он задаёт именно этот вопрос. Как ответ на него повлияет на работу в команде? Как кандидат относится к такому формату работы? Часто это может дать гораздо больше информации. А ведь в этом и цель — узнать максимум. К тому же, вы попутно выполните и вторую цель диалога — на конкретных примерах покажете, чем вы тут вообще занимаетесь. Техническое собеседование Часто, особенно в крупных компаниях, выделяют отдельную техническую секцию. Иногда даже не одну, а, например, делят на «секцию по алгоритмам» и «секцию дизайна систем». А ещё, чтобы каждый раз не изобретать велосипед, обычно существует фиксированный список или база вопросов. В помощь собеседующему там уже написан эталонный ответ или критерии, которым он должен соответствовать. Но это совершенно не значит, что эти вопросы существуют в вакууме и никак не относятся к конкретной позиции. Допустим, вы решаете спросить: «В чём отличие горутины от потока?» Обсудив ответ и углубившись в детали, вернитесь к вашей позиции. Почему для вас это важно? - Может быть, у вас был баг, который приводил к резкому росту числа горутин, и вы упирались в планировщик. - Может, у вас CPU-интенсивные приложения, и вам важно следить за утилизацией ядер. - Может, вы переносите бизнес-логику с Java на Go и стремитесь сохранить параллелизм. - Может, сочетание лимитов в кубере и установленных GOMAXPROCS ваших приложений уже приводило к троттлингу и падению бизнес-метрик, и вам важно, чтобы каждый член команды хорошо понимал, как и что стоит настраивать. А если вы сами не понимаете, зачем задаёте этот вопрос, то, может, он и не нужен? Soft skills интервью или менеджерская секция Вы просите человека рассказать про свой провальный проект. Обсуждаете это с ним, делаете выводы. Но почему бы не объяснить, что именно вам тут было важно? И почему бы не поделиться в ответ своим провальным проектом? Если моя цель не только понять, насколько кандидат соответствует нужной позиции по навыкам, но и определить его майндсет, то я ещё больше стараюсь превратить такой разговор в диалог. Мне ведь важно не только как кандидат поступал в прошлом или поступил бы в теоретических условиях, но и то, как он отреагирует на мои решения. Ему же не в вакууме управлять командой, а в моём направлении. А значит, обсуждать сложные кейсы со мной, в том числе. И так во всём В первом сезоне подкаста «Кода кода» меня почти не слышно. Я не только не озвучивал своего мнения, но даже вырезал свои вопросы там, где контекст склеивался. Позже мы с Женей стали активно делиться и своим мнением. А в последних сезонах — дополнять гостей и даже спорить с ними. Я уверен, что такой подход гораздо лучше раскрывает и тему, и гостя. Потому что в реальной жизни мы очень редко попадаем в изолированный контекст. А значит, и пользы от такой изоляции немного. Если вы заметили эти изменения в подкасте и вам это нравится — ставьте молнию.
1 месяц назад