Про руководство разработкой и продуктом | Олег Мохов
3.48K subscribers
168 photos
3 videos
2 files
183 links
Привет, я Олег. Software engineering manager в Контуре, в прошлом руководитель отдела в бигтехе. Пишу про свой опыт управления продуктом и разработкой.

Для связи: @olegmokhov
Download Telegram
Ресурсы и инструменты для развития тимлида: приоритеты, баланс, «помощь зала» / Наталья Борисенко

Это доклад-рефлексия на тему того как тимлиду развиваться и прокачивать себя.

Наташа начинает с того, что поднимает проблему нехватки денег для поездок на конференции и приводит это в качестве примера причины, по которой она начала выступать. Не универсальный совет, конечно, так как на конференции 1000+ участников, а докладчиков меньше 100, но кому-то зайдет. Я лично по той же причине пошел в ПК.

Далее приводятся 5 инструментов роста руководителя:
— конференции
— люди (эксперты/менторы/менти)
— книги, исследования, статьи
— курсы
— подкасты.

В целом на этом можно сказать всё тема доклада раскрыта 😃, но далее идёт рефлексия на тему как и с чем лучше работать.

Ограниченные ресурсы — это реальность, поэтому любые каналы, курсы и книги стоит фильтровать. Наташа предлагает формулу:
много источников + строгий фильтр = качественные знания.

Наташа даёт совет: если материал не зацепил за 10 минут — лучше не мучиться дальше. Это единственный момент, с которым я категорически не согласен. Лично у меня были случаи, когда «невкусный» на первый взгляд материал оказывался ценным, а книгу, которую я мог мучать месяцами в конце оказывалась бриллиантом. Даже этот доклад я досмотрел только со второй попытки — в первый раз был слишком перегружен, и информация не легла.

Затем Наташа делится личным опытом поиска менторов. Сначала — интересный автор, потом этап «конфетно-букетного периода», когда вы просто читаете его материалы. Если откликается — можно попробовать выйти на контакт. В частности, она рассказывает историю знакомства с Торри Подмажерски и про свой запрос: как найти баланс между ролями IC и Team Lead, как не наломать дров в росте и где искать поддержку.

В докладе также упоминается модель Gain – Grind – Grow:
— Gain — выделение времени на получение знаний
— Grind — практика и применение
— Grow — превращаем навыки в достижения целей (подробнее например здесь)

В конце Наташа немного рассказывает про пользу нетворкинга и проф.сообществ на примере сообщества техписов. А так же делает ремарку на тему того, что все иногда могут перегореть и важно следить не только за интенсивностью работы, но и за своими личными ощущениями.

Неплохой доклад, особенно если вы недавно стали тимлидом и не знаете с чего начать. Я же лично в очередной раз рекомендую книгу Джеймса Стэньера, даже если вы не SEM многое из описанного в ней вам будет полезно.

Все обзоры по тегу #докладобзор@teamleading
👍64🤔1
Глобальный Undo

Один из самых странно решённых и невероятно долгоживущих сценариев на мобильных устройствах — это Undo, а точнее его отсутствие.

На десктопах всё давно просто и понятно: Ctrl+Z работает почти везде. А на мобилках? Когда только появился iPhone, Стив Джобс придумал, что для отмены действия можно… потрясти телефон. Да-да. Потрясти. Телефон. В ответ появится модалка: «Отменить ввод текста?». Но, как можно догадаться, это (потрясти + подтвердить) не прижилось. В смысле оно работает, но проще переписать. Да и работает только в текстовых полях. На этом всё и закончилось.

На первый взгляд, вроде и проблемы-то нет. Даже исследования говорят, что пользователи редко вспоминают про Undo на мобильных интерфейсах (например, вот статья из ACM Digital Library). Но только до тех пор, пока сам не промажешь пальцем — и не потеряешь точку невозврата.

Продакты, внимание! Дарю вам фичу.

Вы смотрите видео. Концентрируетесь. И тут — случайный тап по экрану: попали пальцем не туда и видео перескочило на 20 минут вперёд. Или свайпнули чуть не так, и всё улетело на начало. Всё — нужный момент потерян. И даже не знаешь, где был до этого. Возвращаться приходится наугад. Иногда — просто бросаешь смотреть. Бесит!

Добавить Undo — это может быть пара строчек. А пользователь сэкономит время, и (что намного важнее) нервы.

Один из главных признаков, когда вам стоит предусмотреть путь назад: если у вас в интерфейсе есть действие, после которого пользователь может сказать «ой».
1👍26🔥54
FrontendConf — мы почти готовы. А вы?

В прошлом году я вошел в программный комитет FrontendConf, и когда в ноябре я пришёл на первый созвон ПК, то подумал: «Зачем так рано? Впереди же почти год». А потом кааааак понял...

Осенью прошлого года я был на FrontendConf. Это стало возможно благодаря Никите Дубко (на фото и кстати, у него теперь есть канал, где он делится опытом перехода в продакт-менеджмент). Я просто ходил, смотрел, а потом половину вечера рассказывал одному из членов ПК, что бы я сделал иначе. Так я оказался в программном комитете.

С тех пор — больше полугода еженедельных созвонов. Интервью с претендентами, обсуждения внутри ПК, просмотры чужих интервью. Споры, обсуждения, критика, Глеб Михеев 😃. И вот вчера мы зафиналили спикеров.

Я смотрю и горжусь тем, что у нас получилось. Программа будет живой: актуальная, интересная, в меру хардкорная, в меру софтовая. Мы почти расставили доклады по сетке — и честно признаюсь, мне будет сложно выбрать куда пойти в некоторых слотах.

Да, я понимаю, что FrontendConf стоит недёшево. Но помимо докладов, которые вы сможете послушать вживую, будет море нетворкинга. А ещё останется доступ ко всем записям. Поэтому мой совет вам такой — пройдитесь по программе, отметьте доклады, которые хочется услышать. Если получилось больше десяти — идите к своему руководителю и упрашивайте купить билет.

От себя внесу небольшую лепту для моих читателей, вот вам промик на небольшую скидку в 5% — fc25_teamleading.

И надеюсь увидеться на FrontendConf 2025.
1🔥115👍5
К сожалению, сейчас мы не готовы пригласить вас на следующий этап.

Это фраза, которая будто создана, чтобы раздражать.

Сегодня будет аж три поста про найм. С недавних пор я снова в поиске работы и хочу поделиться несколькими наблюдениями.

Во-первых, давайте уже перестанем говорить:
«С твоим опытом ты легко найдёшь работу!»

Нет, не легко. Это миф.

Я ушёл из Яндекса почти год назад. С тех пор у меня была череда откликов, собеседований и «смотрели, но не выбрали». За это время я понял вот что: если кто-то и находит работу быстро, то это точно не я. И я общаюсь со многими друзьями по несчастью и у них та же ситуация.

Возможно легко находят работу мидлы. На рынке много вакансий, понятные требования, стандартные процессы, вилки ± одинаковые. Там всё довольно прозрачно. Может там «легко»?

Но вот по данным Time / LinkedIn Economic Graph, в 2023 году медиана закрытия вакансий была 44 дня. Не ну это было давно и не у нас, а у нас что? А в России показатели закрытия вакансий тоже растут. А значит мы снова вернулись к тому, что найм — это рынок работодателя.

Сеньорам, руководителям, C-level’ам объективно сложнее искать работу. Таких позиций меньше, ожидания размытые, критерии успеха меняются от компании к компании. Да и чаще тебя ищут, чем ты находишь.

В остальное время ты просто ждёшь, что хотя бы один отклик не закончится шаблоном:

«Спасибо за интерес, но мы пока не готовы двигаться дальше…»


И в ХХ эта аналитика на виду: просмотр в 16:10 — отказ в 16:10. Отказали быстрее минуты, получается

Я не прошу развёрнутый фидбек на полстраницы. Хочется просто одного предложения:
– Где не совпали?
– Что показалось слабым?
– Почему решили не звать?

Чтобы не совсем уехать кукухой я спрашиваю у ChatGPT — что не так? Он не уходит в глухую оборону, не прячется за HR-бренд и может помочь понять, где можно подкрутить. Почему компании не могут сделать так же? Где пресловутая AI-трансформация рекрутмента?

Но, честно, хочется, чтобы и компании чуть взрослее относились к процессу.

«Вы нам подходите, но нам кажется, что вы немного overqualified? Вам ок такое?» Или «Сейчас мы общаемся с другими кандидатами, но если вакансия не закроется в ближайшие пару недель, мы вернёмся к вам. Если вы готовы подождать — дайте знать».

Это уважительно.

Если вы сейчас тоже в поиске — держитесь.
Это тяжёлый, иногда очень выматывающий процесс, особенно если не вписываешься в «типовую» позицию. Но вы не одни.

Если нужно — скидывайте свои резюме, с удовольствием посмотрю и дам обратную связь. Сейчас у меня есть на это время.
33💔23💯10
А ещё хочу поделиться полезной рекомендацией для тех, кто сейчас готовится к собеседованиям.

Мой друг (и, по несчастью, коллега по рынку труда) Серёжа собрал отличную борду для подготовки к интервью на позиции проджектов и продактов. Там структурировано, чётко и по делу — без воды, с примерами и разбором типовых вопросов.

Серёжа умеет раскладывать сложное на простое и писать внятно. Поэтому рекомендую не только борду, но и его Telegram-канал — он пишет полезно и без лишнего шума.

https://xn--r1a.website/seryozha_typing/365
👍14🔥52
И ещё давайте посмотрим на найм с другой стороны.

Сергей Озеранский недавно написал у себя в канале о своём опыте собеседований с инженерами.

Найм давно стал шаблонным. За каждым собеседованием — одно и то же: опросники, задачи. В лучшем случае архитектурная секция. Благодаря благотелям вырос целый слой «хакающих систему» джунов, которые натаскиваются на такие интервью. И сениоров, которые не проходят дальше первой секции, потому что у них нет времени готовиться и зубрить учебники.

При этом то, что предлагает Сергей, требует высокой подготовки. Он пишет о навыке вести живой разговор, быть в моменте, уметь задавать вопросы по ходу — не по бумажке, а по голове. К слову, в Яндексе у нас тоже были такие секции: когда ты общался не по скрипту, а по сути. Но, справедливости ради, это требует опыта, внутренней уверенности в знаниях, а так же умения слушать и импровизировать. К такому виду собеседований надо быть готовым.

Я лично поддерживаю этот подход. Он медленнее, сложнее и менее «масштабируем», но он гораздо точнее. Потому что люди не равны задачкам на доске. И хорошее интервью — это разговор. Не тест.
👍26💯13🔥2
Это доклад о том, как увольнять людей и расставаться с ними максимально эффективно.

В докладе рассмотрены три темы.

Какие есть риски увольнения. Тут Татьяна выделяет следующие риски: долгий и дорогой поиск замены, утечка знаний и информации, переживание и деморализация команды, перетягивание команды и суды.

Я много раз наблюдал даже громкие увольнения — и «деморализация» сходила на нет через пару недель. А «перетягивание команды» — это не столько риск, сколько индикатор: что происходит в компании, если люди готовы уйти за одним человеком?

Когда увольнения можно избежать и когда нельзя:
Можно: если проблемы с Hard-Skills или есть проблемы взаимодействия с контрагентами.
Нельзя: завершение проекта / закрытие направления, токсичные проявления в команде, открытый саботаж.

▫️ Семь шагов при увольнении

1. Дать второй шанс: обозначить проблему, дать конкретный срок на исправление.

2. Оценить срок подбора замены

3. Прямо поговорить с человеком.

4. Проработать увольнение с теми кто может быть против.
Этот пункт на мой взгляд самый не очевидный и потому полезный. Принимая решение об увольнении нужно понимать что конкретно и с кем делал человек? Татьяна, зачем-то, говорит про кумовство, хотя я бы говорил про элементарную защиту цепочки поставки. Когда вероятно могут быть люди, плотно взаимодействующие с человеком и удовлетворенные результатом работы.

5. Уточнить правовой аспект (например, не относится ли увольняемый к защищенным ТК РФ категориям)

6. Саморефлекция

7. Скоммуницировать команде.

Несмотря на неплохие тезисы доклад оставил у меня двоякое впечатление. Есть хорошие тезисы, например, что уволить человека, даже когда он откровенно просаживает задачи и это подтверждено цифрами — сложно. Но тут же Татьяна себе противоречит, ведь если так, то как уволить за открытый саботаж?

Татьяна не погружается глубоко в вопрос «почему людей иногда нужно увольнять». Из доклада складывается ощущение что увольнять надо тех с кем не удобно работать. Татьяна, например, приводит кейс с аналитиком, который на каждом дейли говорил что у них ничего не получится. Но совсем не раскрывает вопрос: а при этом делал ли он свою работу? Может это была его защитная реакция — завести себя в состояние цейтнота, чтобы делать работу на максималках? Может команду это так же подстёгивало? Хочется больше контекста.

Расскажу пример из своей практики, был у меня разработчик, допустим Иван Иваныч. И вот он был редкостный... человек. Мат-перемат и уши в трубочку заворачивались от каждого диалога. Он доставлял кучу проблем, мог не приходить на работу, коллеги от него стрелялись, и были даже инциденты закончившиеся больницей. И я тоже хотел бы его уволить, но.... Иваныч был просто гениальным фронтендером. Я дал ему отдельный проект с небольшой командой и возможность проявлять себя в нём, и оказалось что помимо офигенных скиллов во фронтенде он обладает ещё и очень неплохими навыками motion-дизайна. Его интерфейсы были очень вкусными и привлекательными. И так мы прожили достаточно долго, а потом Иваныч сам ушел из компании, но при этом у меня остались тёплые (и веселые) воспоминания о нём.

Если вы смотрели сериал «Доктор Хаус», то понимаете что я получил такого же доктора Хауса. Если вы нанимаете команду винтиков, то нужно следовать рекомендациям Татьяны (посмотрите доклад), если вы хотите собрать сильную и смелую команду, то доклад надо посмотреть критически и задавать себе вопросы: а точно ли это так? а согласен ли я с этим? Вот именно в такой компоновке я готов порекомендовать этот доклад.

А увольнять надо тех, кто не работает.

Все обзоры докладов по тегу #докладобзор@teamleading
Please open Telegram to view this post
VIEW IN TELEGRAM
👍233
Кстати, уже завтра будет Saint TeamLead Conf и я там тоже буду. Подходите знакомиться и обниматься 😊
17🥰2🔥1
Идеология одиночек

Макс Ульянов написал пару постов про «волков» — первый, второй. Глеб Михеев подхватил. Не могу не откликнуться и не высказать своё имхо — но сначала лучше прочитать их.

Волки — это не герои-одиночки. Это читеры, для которых важнее пройти, чем понять. И, увы, такая установка встречается всё чаще — во многом потому, что сама система это поощряет. Современные собеседования всё чаще напоминают не экзамен на знания, а экзамен на знание формата. Кто умеет угадывать или знает вопросы или может нагуглить правильные ответы, побеждает.

Я это видел давно. В универе у нас был курс по сетям Cisco — обязательный и скучный. Преподавание слабое, интереса ноль, но каждую неделю — тест. И всё свелось к гонке шпаргалок. Интернет? Отрубили. Флешки? Запретили. CD-диски, дискеты? Поставили мониторинг экранов. Я дошёл до того, что печатал шифрованные шпоры на бумажках размером с ладонь. Иногда это работало, иногда нет — но в итоге ничему полезному меня этот курс не научил. Потому что никто не объяснил, зачем всё это, и не создал условий для настоящего понимания.

Собеседования — не просто фильтр. Это предиктор будущей работы. Человек потом с этими знаниями будет писать код, общаться с командой, принимать решения. Если он проходит «по шпоре» — то что будет потом?

Мышление «просочиться» — токсично. И если собеседования сейчас устроены так, что выгодно именно оно, — значит, надо менять формат. Практические интервью, приближённые к реальной работе, лучше вскрывают суть: кто умеет решать — решит. Кто зубрил — сдуется. Проблема в том, что такие собеседования дорогие (я об этом писал).

Нет, я не идеалист. Я понимаю, почему бигтех (а за ним и другие компании) выбирает формат экзамена. Он масштабируемый. Это позволяет работать с сотнями кандидатов, не тратя по 4 часа на каждого. Но это не делает формат хорошим — только удобным.

Есть классический треугольник: дёшево, быстро, качественно — выбери любые два. Сейчас рынок требует дешево и быстро. Поэтому у нас — собеседования-экзамены. Возможно, пока это наилучшее из плохого. Но точно не то, чем стоит гордиться.

И вот тут возвращаемся к «волкам». Если бы они только сливали собесы и выкладывали разборы — это было бы похоже на форму протеста. Не идеальную, но понятную.

Идеология волков звучит так: «Работать нужно только за деньги, а не за спасибо». Это не позиция профессионала — это логика читера. Того, кто делает только то, за что платят прямо сейчас. Как таксист, который ради 50 рублей проезжает на красный. На короткой дистанции это может сработать. Но ни одна команда, ни один продукт на этом далеко не уедет.

Нет ничего страшного, если вы воспользовались IDDQD, чтобы посмотреть как надо было и что же там дальше. Плохо, когда вы живете исключительно на IDDQD. Именно поэтому идеология волков — не про справедливость, а про халяву. Не про улучшение системы, а про то как её обходить. Это читерство и оно всегда вскрывается. Иногда — через месяц. Иногда — через 35 лет. Но вскроется обязательно.
14🔥2616😁8🕊2💯2❤‍🔥1😢1🙏1🐳1
Вау! 3 тысячи, спасибо каждому кто читает этот канал, пишет в комментарии и репостит. Так как здесь много новых людей, то настало время сделать навигационный пост, чтобы не пропустить самое интересное.
15👍9❤‍🔥6🥰1
Привет, меня зовут Олег.

Я почти 20 лет работаю в ИТ, из них 15 работал в российском бигтехе и вырос из верстальщика до руководителя отдела (C-level).

Здесь я пишу свои мысли на разные темы. Вот некоторые важные посты, разбитые на тематики.

Мой манифест работе — понедельник начинается в субботу.

Подходы к управлению
Ситуационное лидерство
Всегда действовать в интересах команды
Минимальный жизнеспособный сотрудник и правила работы со мной
— Про одну из ролей продактов и закон Йеркеса-Додсона
— Про нагрузку на команду и формулу Кингмана

Командные встречи и 1х1
Как часть нужно общаться командой?
Как давать корректирующий фидбек (Алгоритм Хорстмана)
Метод 5П для встреч один на один
Метод ORID
Обратные ретроспективы

Саморазвитие
Сколько часов надо работать в неделю?
Учиться — быть самоучкой?
Мыслетопливо и как я его сохраняю

Про найм и увольнения
Факторы сениорности
Как нанимать лучших
— Почему я люблю вопрос «Какое у тебя хобби» и почему он про выгорание.
Как увольнять, сохраняя достоинство
Что делать если вас уволили?
Про то почему волки — читеры
Сломан ли найм и как его начать чинить

Про Performance Review
— Как давать фидбек друг на друга. В трёх частях: первая, вторая и третья.
Как калибровать людей
— Зачем калибровать людей. Часть один и два.
— Про слепые калибровки

А также просто мысли о разном.
Как я начал читать и мой рейтинг книг, прочитанных в 2024 году.
— Про икигай и смысл жизни
Как я научился Power Nap'ам.

А ещё я делаю обзоры на книги и доклады. Их можно найти по тегам — #книгобзор@teamleading и #докладобзор@teamleading.
130👍18👏4🥰1🙏1🕊1
Про руководство разработкой и продуктом | Олег Мохов pinned «Привет, меня зовут Олег. Я почти 20 лет работаю в ИТ, из них 15 работал в российском бигтехе и вырос из верстальщика до руководителя отдела (C-level). Здесь я пишу свои мысли на разные темы. Вот некоторые важные посты, разбитые на тематики. Мой манифест…»
Полезняхи про встречи и оплату за рубежом

Никита Дубко недавно написал про одну галочку в Zoom, которая может сэкономить минуты, а я вам сегодня расскажу про своё недавнее открытие.

«Кстати, а кто Action Items у нас записывает?» — знакомо? Если у вас есть такая же проблема как у меня, а именно вы активно вовлекаетесь во встречу, а после не помните что обсуждали и до чего договорились, то у меня есть для вас решение.

Сервис Bluedot. О нём мне рассказал Лёша Симоненко — он первым начал приносить созвоны со спикерами на встречи ПК FrontendConf. И я офигел от того, насколько там крутая расшифровка и суммаризация. И вдвойне клёво, что он легко встраивается в Google Meet. Как и в любой другой созвон в браузере.

Специально для этого поста мы с Лёшей записали пробный созвон, в котором обсуждаем прошедший Saint TeamLead Conf. Признаёмся, были всего на нескольких докладах, но даже несмотря на это, Bluedot выделил один AI:
Олег:
• Пересмотреть доклад «Когнитивные ловушки Тимлида, инструкция по выживанию» от 27 июня.


Удивительно, как даже в постановочной встрече можно получить полезное напоминание.

Параллельно Зар Захаров рассказал мне про Pyypl — способ платить за Bluedot (и Netflix, и ChatGPT) без всяких банковских сложностей и выездов за границу.

В общем делюсь с вами рефералками на Bluedot и Pyypl.

Оба сервиса проверены — можно пользоваться.
1🔥126👍3👏1😁1
Сколько часов в неделю нужно работать?

Эту неделю я хочу посвятить книге «Идеальный программист» Роберта Мартина. Что я сам понимаю в разработке — у меня всего-то 20 лет коммерческого опыта. Поэтому давайте попробуем довериться человеку с 55-летним стажем. Ниже — цитата из книги (с моими пометками курсивом):

«Вы обязаны (по трудовому договору именно обязаны) своему работодателю некоторым количеством времени и усилий. Для примера возьмём стандартную для США (и для России) 40-часовую рабочую неделю. Эти 40 часов должны быть проведены за решением проблем вашего работодателя, а не ваших личных проблем

Запланируйте 60 рабочих часов в неделю. Первые 40 вы работаете на своего работодателя, а остальные 20 на себя. В эти 20 часов вы читаете книги, практикуетесь, учитесь и иным образом развиваете свою карьеру.

Наверняка вы подумали: «А как же моя семья? Моя личная жизнь? Я должен пожертвовать всем ради своего работодателя?»

Я не говорю обо всем вашем личном времени. Я говорю о 20 дополнительных часоах в неделю. Если вы будете использовать обеденные перерыв для чтения и прослушивания подкастов и ещё 90 минут в день на изучение нового языка (программирования) — это решит все проблемы.

Давайте немного посчитаем. В неделе 168 часов. 40 достается вашему работодателю, ещё 20 — вашей карьере. Остаётся 108. 56 тратится на сон, на всё остальное остается 62. Возможно, вы не хотите брать на себя подобные обязательства. И это вполне нормально, но тогда не считайте себя профессионалом. Профессионалы не жалеют времени на совершенствование в своей профессии.

[...]

Иногда эти два направления совпадают. Иногда работа, выполняемая для работодателя, оказывается исключительно полезной для вашей карьеры. В таком случае потратить на неё некоторые из этих 20 часов будет вполне разумно. Но помните: эти 20 часов предназначены для вас. Они используются для того, чтобы повысить вашу профессиональную ценность.

Может показаться, что мой путь ведет к «выгоранию» на работе. Напротив, он помогает избежать этой печальной участи. Вероятно вы стали разработчиком из-за своего энтузиазма к программированию, а ваше желание стать профессионалом обусловлено этим энтузиазмом. За эти 20 часов вы будете заниматься тем, что подкрепит ваш энтузиазм. Эти 20 часов должны быть интересными!»

©
Роберт Мартин «Идеальный программист», издательство Питер

Мне очень нравится мысль о том что саморазвитие — это работа на себя и свою карьеру. Сложно написать лучше чем сделал это Роберт. Но всё же хочется чуть поспорить с категоричностью: «если не тратишь 20 часов на себя — ты не профессионал».

Эта фраза немного задевает. Что же получается — если я не работаю дополнительно 20 часов, то всё, баста? Нет. Я всё ещё специалист. Junior, Middle, иногда даже Senior. Просто без системного саморазвития я перестаю расти. А рост — это то, что отличает профессионала от просто опытного исполнителя.

Отдельно хочется отметить мысль «обязаны посвящать 40 часов работодателю». Возникает вопрос: «А что если я делаю работу быстрее?» В такие моменты я искренне восхищаюсь и при этом удивляюсь: если есть время — почему бы не сделать ещё лучше? Попробовать порефакторить, применить новые знания, поэкспериментировать. Мы ведь часто жалуемся, что у нас «нет времени на улучшения». А тут оно есть — и сам бог велел им воспользоваться.
14🔥158🤔6😁3💯3❤‍🔥2
Учиться — значит быть самоучкой?

Продолжаю разбирать «Идеального программиста» Роберта Мартина. Сегодняшняя тема это рост профессионала за счёт среды, в которую он себя помещает.

«Профессионал задаёт вопросы. Профессионал просит ревью. Профессионал обсуждает архитектуру. Профессионал вникает в чужой код и позволяет другим вникать в свой.»


Мы часто воспринимаем развитие как нечто индивидуальное. «Хочу вырасти — пойду на курс». «Надо подтянуть алгоритмы — буду ботать литкод». «Хочу стать senior'ом — буду по вечерам делать pet-проект». Всё это правильно. Но...

Самые быстрые скачки в карьере происходят у тех, кто много взаимодействует. И не просто говорит, а спорит на ревью. Кто получает неудобные вопросы на архитектурных обсуждениях. Кто не боится узнать, почему его идея сломала API, хотя на бумаге всё казалось отличным.

Парадокс в том, что это некомфортно. Но именно это работает.

✳️ Саморазвитие ≠ изоляция

Многие олды пришли в разработку самоучками. Через курсы, туториалы, книги. Это формирует привычку: «если хочешь расти — иди и сам разбирайся».

Они боятся выглядеть глупыми. И, например, признать, что не знают, что такое «каппа в Kafka» или не до конца поняли async/await. И в итоге человек годами читает статьи — но боится задать вопрос в общем чате. Боится попросить объяснить.

А потом оказывается, что он застрял в развитии. Он умный, опытный, но не растёт. Потому что варится в собственном соку.

🛠 Вот что я сам считаю наиболее мощными способами коллаборативного развития:

— Code review — не просто как валидация, а как площадка для обучения. Один детальный комментарий от старшего коллеги может заменить десяток статей.

Для больших Merge Request'ов мы даже практиковали очное ревью. Когда два человека садятся рядом (или созваниваются) и один рассказывает что бы улучшил в коде другого. Эффективнее почти любого асинхронного ревью.

— Писать постмортемы, RFC, ADR, C4 и документацию самостоятельно — они требуют формулировать мысли. А значит — самому её осознавать.

— Архитектурные ревью — даже просто послушать обсуждение чужих решений уже полезно. А уж получить мощную критику (а на архи преимущественно только она) на свой код от гуру разработки — бесценно.

— Спрашивать «а почему вы сделали так?» у авторов кода — даже если MR уже вмержен. Это помогает не только понять решение, но и тренирует навык продуктового мышления.

— Менторство (в обе стороны) — объясняя, сам начинаешь лучше понимать.

— Парное программирование, mob-программирование, shadowing и прочие практики учиться у других в интерактивном формате (Про это будет отдельный пост).

— Ну и банальные small talk'и в офисе — именно поэтому я рекомендую хотя бы пару раз в неделю собираться всей команде в офисе, если есть такая возможность.

Я намеренно не стал здесь писать про ChatGPT и прочие AI-тулы. Да, ИИ-инструменты помогают. Но у них пока есть один минус — они не придут к тебе сами. Если ты не знаешь, чего не знаешь — то ты не задашь нужный промпт.

📊 И немного статистики

В исследовании от DORA (Accelerate State of DevOps), одной из ключевых практик высокоэффективных команд названы collaborative review practices — обсуждение архитектуры и процессов, не только кода.

В Stack Overflow Developer Survey 2024 «спросить у коллеги» второй по популярности способ поиска ответов на технические вопросы.

📌 К чему всё это?

Если вкладывать 20 часов в неделю в развитие (как предлагает Мартин) — то это не обязательно должен быть solopreneur-режим, когда ты тихо ночами проходишь курсы по Rust или в метро ботаешь «Грокаем алгоритмы». Иногда полезнее — обсудить код с мидлом из соседней команды. Или попросить дизайнера рассказать, как они думают про UX. Или предложить следующую задачку закодить парно.
1💯17👍8🔥7❤‍🔥21
Самая честная лекция про построение карьеры / Леся Набока и Люда Шведова

Сегодня весь день занимался работой по оптимизации своих расходов (говоря простыми словами съезжал с дорогого склада, на менее дорогой, если что могу поделиться контактами обоих) и практически проглотил в фоне этот доклад.

Это, конечно, разрыв. Настоящее пошаговое руководство по работе над собой для продактов, которым уже... ну, в общем, вы поняли. С Лесей я, волей случая, знаком лично, и могу сказать — она и в жизни говорит так же напролом, как в этом докладе. Без реверансов, без лукавства, по делу. И это кайф: все тезисы в докладе — ровно такие. С Людой, к сожалению и надеюсь пока, не знаком.

Мне не стыдно признавать, какие ошибки со мной до сих пор, а какие я победил, пусть это будет затравкой к контенту доклада, и если вас заинтересовало, то доклад стоит посмотреть целиком.

Ошибка 1 — Карьера с тобой случается
Лет 5 назад такое точно было, но в последние годы я уже чуть лучше понимаю куда хочу и что нужно делать.

Ошибка 2 — У тебя нет советника по карьере
И нет до сих пор :(
Уже есть! :)

Ошибка 3 — Ссышь и самозванствуешь
О, дааа.

Ошибка 4 — Ждешь, что работа будет только по любви
Вот здесь я все же считаю, что выбирать надо работу, в которой хотя бы граммулечка любви присутствует

👎 Ошибка 5 — Ты уверен, что ты продакт
Никогда не был уверен

👎 Ошибка 6 — Ты уверен, что ты хороший продакт
Тоже нет, причем если посмотреть на критерии хорошего продакта в докладе, то у меня 100% мэтч и даже после этого не считаю себя хорошим продактом. И да, мне не стыдно теперь признаться, что я слабо умею в юнит-экономику.

👎 Ошибка 7 — Ты якобы всеприменимый продакт
Я точно таким себя не считаю, но несколько раз успешно менял домены и выполнял кучу разного не продуктового.

Ошибка 8 — Ты плохо упакован
Йеп

/👎 Ошибка 9 — Не умеешь искать возможности
Вот тут я всегда действовал сам и искал сам, но чего я не делаю — не ищу возможности рядом. Очень сильно замыкаюсь внутри своего домена.

👎 Ошибка 10 — Не строишь нетворк
Очень строю, даже этим постом :)

👎 Ошибка 11 — Ведешься на золото
Точно нет

👎 Ошибка 12 — Не знаешь свое профессиональное либидо
Я хорошо знаю в чём я силен и в чём нет. Причем я это всегда проговариваю на собеседованиях, чтобы не было ложных ожиданий.

👎 Ошибка 13 — Ты убегаешь из отношений
Точно нет, всегда честно говорю о том чего хочу и как, прежде чем начать движение на сторону (да и было-то такое пару раз всего)

👎 Ошибка 14 — Продаешься без мыслей о дальнейшей капитализации
Скорее наоборот очень даже думаю

👎 Ошибка 15 — Сидишь в болоте
Никогда не любил болото и максимально избегал его

При этом я много раз видел, как хорошие ребята топтались на месте, потому что раз за разом совершали какую-то из ошибок. Они не могли её победить (и часто даже не осознавали), а я формализовать.

Делитесь (если готовы) какие ошибки совершали вы? Так же рекомендую каналы Леси и Люды.

Все мои обзоры докладов по тегу #докладобзор@teamleading.
16👍6🔥4💯3🤯1
Три истории читерства

Я преподаю в ВУЗе. Делаю это больше 10 лет и недавно в одном молодёжном канале мне припомнили историю, что я когда-то не принял домашку у студента, потому что в задании на перевёрстку Яндекс.Почты он использовал переменные huyandex и govnopochta. Я назвал это неуважением к авторам курса, но не исключил студента, а просто отказался принимать конкретно ту задачу, даже на один балл.

Так вот, это воспоминание напомнило мне несколько историй читерства, о которых я хочу рассказать.

Лет 10 назад на одном из наших первых потоков по фронтенду, когда мы (команда из 8 человек) принимали задачи вручную без автопроверок и у нас не было антиплагиата один студент решил списать наивно, то есть просто заменив названия переменных. Рассчет был на то, что раз у кого он списывает был другой ментор, то это не вскроется. Был один нюанс — студент забыл скопировать часть кода. В буквальном смысле выглядело это так: он вызывал функцию, которой не существует. Так и спалился.


Несколько лет спустя меня позвали в комиссию по приёму дипломных работ. Обычно я там для того чтобы провалидировать пару-тройку работ по вебу, но так как остальное время ничего не делать скучно, то я слушал все работы. И вот выходит один парень и рассказывает про распознавание маркеров дополненной реальности с помощью обычной веб-камеры. Маркер это, например, листочек с черным квадратом на нём. Он буквально рассказывает следующее: «Я делаю снимок с камеры, а потом перевожу в ч/б. Пришлось долго подбирать коэффициенты чтобы картинки в ч/б было достаточно для распознавания маркера». После выступления я задаю вопрос: а как вы подбирали эти коэффициенты? На что получаю странный ответ: просто подбирал.

Этот ответ меня смутил и я почему-то решил полезть в поиск... знаете что я там нашел? Статью на хабре от 2012 года, где 1 в 1 рассказывается диплом студента. Ну и коэффициенты там точно такие же...


В этом году на экзамене по JS многие студенты активно пользовались GPT при решении практики, из-за этого мне активно пришлось давать дополнительные задания, которые GPT не всегда уже мог обработать. И вот один студент бьётся и не может решить задачу. Я несколько раз прошу его не пользоваться LLM и включить голову, но не получается, студент говорит мне что не пользуется. В конце концов, я сам ввожу в GPT то что вводит студент, и GPT выдаёт мне ровно его решение, которое не верное. Я это показываю студенту и приглашаю на пересдачу.

Справедливости ради, студент сдал на пересдаче сам, а потом ещё и извинился за тот раз.


Эти три истории показывают каким я считаю правильный путь. Я всегда даже когда вижу читерство, даю людям шанс и не терплю исключительную наглость. В одном из сообществ в описании курса была такая фраза (не дословно): руководит курсом Олег Мохов, товарищ достаточно жесткий, но при этом не спрашивающий ничего чего бы не было в курсе.

Возвращаясь к истории в начале: а вы бы как поступили? Ну и рассказывайте ваши истории, если такие есть.
👍29
Попахивает вселенским совиным заговором, у волков появился конкурент 😄 (ну а если вы пропустили)
😁19❤‍🔥1😱1
Как ищется работа в 2025?

Так как с завтрашнего дня я официально работаю, то надо подвести итоги. Серёжа написал отличный пост со своими личными итогами, я абсолютно согласен с написанным и не буду дублировать его выводы.

Я был в поиске 35 дней. При этом официально безработным 27 дней.

Я откликался на разных площадках, суммарно около 70 откликов.

Вот такие итоги, не считая офферов (проценты для удобства я округлял)
1. Отказы — 85%.

К отказам я отношу всё что в том или ином виде завершает общение со стороны работадателя. Чуть точнее в цифрах:
— 43% прислали сухой автоматизированный отказ
— 20% никак не отвечают, то есть спустя месяц я либо до сих пор значусь в системе «на рассмотрении», либо вакансия тихо отправляется в архив. Этим грешит и бигтех.
— 8% отвечают что закрыли вакансию или что есть финалисты. Иногда при этом вакансию продолжают держать как активную.
— 6% отказали после скрининга или технички.
— 6% — это на мой взгляд самые странные, они отвечают дополнительными вопросами (например спрашивают ожидаемый доход, или готов ли я ездит в офис каждый день) и пропадают после моего ответа.


2. Холд или пропали после первых собеседований — 12%

Когда процесс в компании не прозрачен, заранее не оговорен, или у компании есть уже какие-то финалисты, то тебя ставят на холд (в лучшем случае) или просто перестают отвечать.


3. Я сам отказался после скрининга — 3%

Бывает что в процессе общения я сам понимаю что не готов продолжать и говорю что не буду.


Мне отказывали автоматически на вакансиях где был 100% мэтч и по резюме и по описанию. Самый смешной отказ был когда автоматически мне отказали, а параллельно рекрутер написала в личку со словами что нашла моё резюме и оно выглядит очень интересным.


Выводы которые можно сделать.

1. Рассчитывать исключительно на отклики не стоит. Это лотерея. С вами всё нормально, просто отказывают 8 из 10.

2. Нетворкинг решает. Пишите знакомым (в идеале рекрутерам) это позволяет скипнуть кучу этапов рассмотрения резюме и перейти к активной фазе. Даже если в итоге вы не получите оффер (например потому что релевантной вакансии пока нет), вы останетесь в правильной базе, и сможете вернуться к рассмотрению.

3. Не бойтесь активно писать что вы ищете работу. Мой честный пост полугодовой давности до сих пор приводит ко мне интересные контакты.


Ещё я могу лишь повторить свой пост про планирование финансов, когда вас уволили, там тоже есть полезные рекомендации, которые применимы плюс-минус всегда в условиях неопределённости.

А куда я пошёл расскажу в следующих постах.
👍36🔥1611😁2🤔1🙏1🐳1
Новости FrontendConf

Мы начали прогоны докладчиков. Да-да. До конференции три месяца, а у нас уже во всю прогоны. Я лично сегодня установил телемост с Владивостоком и целый час слушал доклад Ромы Ахмадуллина про новые способы позиционирования элементов. Мне, как верстальщику в прошлом, было интересно как теперь по-новому можно решать эту задачу.

Вообще, программа конференции полностью утверждена, но есть одно но...
Нам нужна ваша помощь с выбором докладов в Главный зал! 🤍 💙

Во-первых, этот зал самый большой, и собрав итак шикарную программу сложно теперь выбрать из неё те доклады, которые будут в нём. Главный зал это место, где мы обсуждаем самые острые проблемы, самые волнующие вопросы и самые крутые решения. Но что именно является самым-самым-самым решать только вам.

Сделать это очень просто — проголосуйте, пожалуйста, за доклады, которые интересны лично вам. Те, на которые вы бы действительно хотели пойти.

🔥 В благодарность за участие в голосовании вас ждут ссылки на наш архив из 467+ видео и промокод на покупку билета. Но не забывайте всё ещё и про мой промокод — fc25_teamleading, он кстати действует и при оплате от организации. 😊

📝 Проголосовать можно здесь до 31 июля.
7🔥1
Как правильно проектировать UX?

Есть одна книга, которую я рекомендую всем своим студентам на курсе по фронтенду в ИТМО. Перечитывая эту книгу в очередной раз я подумал, что ЦА этой книги гораздо шире и она в том числе подойдёт и продактам, и аналитикам, и конечно дизайнерам. Это книга «Разработка интерфейсов. Паттерны проектирования» авторства Дженифер Тидвелл, Чарли Брюэра и Эйнн Валенсии.

На мой взгляд, одна из причин, по которой книга незаслуженно обделена вниманием — это неудачный перевод названия "Designing Interfaces: Patterns for Effective Interaction Design". Я бы перевёл название так «Дизайн интерфейсов. Паттерны эффективного UX-дизайна». Это тот случай, когда продакт гуляя по книжному даже не возьмёт книгу в руки, потому что подумает что книга про разработку, а слово паттерны только усиливает ощущение того что книга для программистов. Из названия на русском не понятно что книга, на самом деле, про дизайн и UX.

По сути, книга является сборником проверенных решений и рекомендаций, с пояснением — когда, почему и как стоит применять тот или иной приём. Читать книгу в наскок, возможно, будет достаточно сложно, но один раз, на мой взгляд, нужно для того чтобы заякорить хотя бы какие-то базовые вещи. И затем возвращаться, когда вы уже сталкиваетесь с какой-то ситуацией непосредственно в работе.

Вот несколько цитат, которые я выделил при последнем прочтении:
Что ещё более важно, если ваше приложение будет использоваться в ситуациях с высокой нагрузкой, например для управления тяжелой техникой, удалите всё лишнее, что может отвлечь от работы. В этом случае когнитивные задачи гораздо важнее эстетики.

Про то что иногда нужно упрощать интерфейсы, а не усложнять. Тут я вспомнил доклад с прошлого FrontendConf про дизайн интерфейсов на заводе.

Когда выделение красным или зеленым цветом указывает на важное различие, не забудьте также изменить форму элемента или добавить текст. Это связано с тем, что некоторые люди не различают эти цвета. По статистике, 10% мужчин и около 1% женщины страдают дальтонизмом в той или иной форме.

Эту цитату я выделил как пример того, что не только «безопасными» цветами можно и нужно проектировать цветовую палитру в дизайне. Можно предусмотреть такое взаимодействие, которое будет отзывчивым, даже если цвета и их изменение не воспринимаются человеком из-за его ограничений.

Это значит, что в интерфейсе должен быть доступен множественный выбор: щёлкая на элементах при нажатой клавише Shift, устанавливая флажки или захватывая несколько элементов при зажатой левой кнопке мыши.

Когда я работал в Яндекс Почте, то этот паттерн там был реализован в списке писем. Если вы зажмете Shift и кликните два раза, то выделите весь диапазон писем. Увы, но многие современные интерфейсы в вебе, напрочь игнорируют такой паттерн взаимодействия.


Книга полна примеров хорошего, обоснованного дизайна. Она не про вкусовщину, а про принципы, поведение и выбор в пользу удоства пользователя. И если вы когда-нибудь спорили с дизайнером или заказчиком о том, «как лучше» — эта книга даст вам конкретику и аргументы, основанные на реальных кейсах. А не «мне кажется так лучше».

Другие обзоры книг по тегу #книгобзор@teamleading
12👍5🔥4