HolyJs 2024

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

Если вы сегодня и завтра будете на Холли, то подходите, буду рад познакомиться, пообщаться, обсудить разработку)

Если у вас не получилось приехать на офлайн часть, но очень хочется заглянуть, то заходите на стрим к SeberiaCanCode. Ребята стримят прямо с конфы(доклады не стримят), задают вопросы спикерам и общаются с участниками о разработке.

Иллюстрация к посту выше

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

Здарова, работяги!

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

Начинал я, как и все, с роли слушателя. До сих пор помню свой первый митап. Позвал меня туда мой тимлид, что уже было для меня суперсобытием, ведь тогда я только-только устроился на свою первую позицию фронтендера. Что уж говорить о самом митапе, люди, которые там тогда выступали, казались мне просто космическими мудрецами, до которых мне еще расти и расти. Еще больше поражен я был, когда потом, после выступлений, все вместе(со спикерами!) отправились в бар и обсуждали сами доклады, смежные темы и разработку в целом. Да… Классная штука эти митапы, отличная возможность обменяться опытом, найти единомышленников, возможно, будущих коллег, да и просто повеселиться)

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

Недавно мне закинули два вот таких канала — «Митапочная» и «Хакатоночная». Как я понимаю, основная цель ребят — закрыть этот пробел, предоставить источник, который позволит нам узнавать о событиях своевременно. Если вы как и я любите такие мероприятия - велкам!

Всем продуктивной рабочей недели!

Хо-Хо-Хо, работяги! 🎅🎄

Этот год был очень продуктивным. Рад, что наконец начал стабильно писать посты в канал. В следующем году планирую продолжать это делать и не только...)

Со времен преподавания у меня накопилось много материалов, мыслей и незакрытых идей по теме реакта и архитектуры. В ближайших планах серия материалов(видео+статьи) по реакту и его экосистеме - базовая часть и продвинутая. Работу я уже начал. Постараюсь не затягивать)

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

А уже второго января мы с ребятами из пк holyJs уже запланировали стрим. Буду рад вас видеть)

Это естественно не все, но пока не буду раскрывать, сохраню интригу.

Поздравляю всех вас! Пусть вам хватает сил и здоровья на все, что вы запланируйте. Берегите себя и своих родных. Продуктивного 2025!!!🎄

Здарова, работяги!

Я к вам с интересным докладом, и нет, это не реклама. Стейт-менеджеры занимают достаточное важное место во фронтенде, сильно влияют на архитектуру приложений(зависит от использования, конечно, но по канону должны отвечать/организовывать отдельный слой). Интересно посмотреть, что Дима подготовил в своем докладе, как я знаю, времени он посвятил много. Давайте поддержим его)

Здарова, Работяги!

Спешу к вам с интересными новостями. Завтра будет целых два стрима с моим участием!
Первый - Тяжелое утро с HolyJS. Как обычно поболтаем с ребятами из ПК Холли о технологиях, новостях в мире JS и тд.
После вместе с Димой(SiberiaCanCode) поразгоняем про инженерную культуру, базу и куда стоит смотреть, чтобы не застрять на покраске кнопок.

Подключайтесь, задавайте вопросы, буду очень рад вас видеть.
Всем хороших выходных!

Стартуем стрим

Здарова, работяги!

В выходные было два стрима. Не часто я выхожу в таком формате, но мне понравился. Серьезно задумался о лайвкодинге в формате стримов. Выходной день, кофеек, чиловая музыка и пет-проект... Ммм... Красота! Что думаете, было бы вам интересно?

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

Еще перед зимними праздниками я писал о том, что решил пойти учиться тимлидству/менеджерству. Долго я выбирал, читал отзывы, сравнивал программы и спрашивал у своих знакомых, которые уже преисполнились в этой роли. После долгих выборов определился. Решил, что пойду на курс «Команда. Инструменты управления» от Стратоплана.

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

Расскажу немного про старт курса, если уж начинать, то с самого начала. В своей практике я касался различных курсов и как студент, и как автор. Привык к тому, что ты платишь денюжки и либо сразу, либо в день старта группы просто начинаешь учиться. У Стратоплана оказалось чуть иначе.

Перед стартом курса меня попросили пройти «вступительные». Состояло оно из решения кейса, эссе и теста «Управленческой зрелости». Хз, мб я еще маленький лид, но кейс оказался не самым простым. По итогам этих заданий проходило интервью, где мне задавали различные вопросы по моим решениям, и что самое главное, рассказали возможный вариант решения кейса с объяснениями. В итоге собеседующий определил мой уровень, что, как я понял, поможет лучше подобрать подходящую группу.

Процесс поступления мне понравился, но пока попридержу свои эмоции, т.к. само обучение только впереди.

Всем продуктивной недели!

Всем привет!

Как и обещал, возвращаюсь с рассказом про обучение. Пока прошел только первый модуль, но уже есть о чем рассказать.

Максимально кратко про темы, т. к. подробнее про них планирую отдельные посты. И да, полезно будет не только тимлидам или тем, кто планирует туда идти, но и просто разработчикам, т. к. помогает сильно лучше понимать, что происходит в компании, почему происходят те или иные вещи и т. д.

Темы:
- DISC
- Работа с ожиданиями
- Модель PAEI
- Жизненый цикл компании и его связь с PAEI
- Психологическая безопасность в команде
- Доверие и прозрачность
- BHAG
- Обратная связь

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

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

На курсе практика устроена так. Все студенты поделены на группы по 6-7 человек. В начале каждого занятия(1ч) в группе распределяются роли:
- модератор - управляет дискуссией
- гейт-кипер - следит, чтобы в обсуждении не ушли не в ту сторону
- тайм-кипер - следит за временем, чтобы группа успела выполнить задание
- писарь(я его так называю) - ведет лог встречи

Группа стабильна, люди всегда одни, а вот роли каждое занятие ротируются, что позволяет попробовать себя в разной роли.

На час времени дается кейс. Что такое кейс? Ближайший аналог — задачки с собесов только для тимлидов и других менеджеров. Выглядит как описание некой проблемной ситуации и набор вопросов к ней.

Пример: вы стали тимлидом команды, где все поругались, а еще план не выполняется. Сотрудники выглядят так-то и так-то. Какие ваши первые шаги? Почему? Что нужно сделать, чтобы решить конфликты? Как успеть план?

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

Как оказалось, все люди разные. Нет, очень разные. Один и тот же кейс, написанный одними словами, все понимают по-разному. Не лучше или хуже. По-разному. И это очень интересно, тк обсуждая решения друг друга ты учишься смотреть на ситуацию с разных ракурсов, копаешь глубже, учишься аргументировать и защищать свое решение. Очень круто. Мы с группой даже решили дополнительно собираться и решать кейсы, благо такая возможность есть - можно попросить доп кейсы).

Из практики сформировал такой совет. При решении подобных кейсов в реальной жизни старайтесь чаще задавать себе вопрос: "А как на эту ситуацию смотрит другой ее участник?". Это позволяет лучше понять ситуацию и принять более подходящее решение. Именно подходящее, а не верное.

Такая связка теории и практики в группах оказалась очень интересной. Сейчас проверяю отработанные идеи в реальной жизни. О каждой, как и писал выше, напишу отдельно, как будут какие-то результаты)

Всем привет!

Закончился мой трехнедельный отпуск, пора возвращаться к делам. Уже совсем скоро стартует ШРИ 2025. И, конечно же, там будут лекции по реакту. И, конечно же, мы снова внесли в них много изменений. Первая, как обычно, будет базовой, а вот вторая и третья будут посвящены архитектуре приложения, в котором используется реакт.

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

Пишите в комменты к сообщению, а я постараюсь разобрать в лекции эти вопросы.

С датами самой лекции вернусь попозже)

Итоги второго модуля.
Всем привет!

Пока я был в отпуске, закончился второй модуль обучения, о котором я подробнее говорил тут.

Модуль называется «Тимлид и бизнес». Я бы его немного переименовал, чтобы лучше раскрыть вам суть этого модуля: «Конструктивное взаимодействие с командой и рук-лем». Это упрощенная формулировка, которая позволит нам сконцентрироваться на основных идеях.

Для того чтобы лиду(да на самом деле кому угодно, для обычного разработчика это тоже очень важно) конструктивно взаимодействовать с командой, рук-лем и т.д., чтобы грамотно выполнять свою в целом, очень важно понимать, кто чем занимается. И нет, формулировка «разработчик пишет код, тимлид руководит разработчиками, рук-ль направления руководит лидами и т.д.» тут нам не подойдет. Почему? Просто знания иерархии не позволят нам как минимум доносить наши мысли на языке собеседника, не говоря уже про корректную работу. Нам очень важно понимать, на каком уровне абстракции находятся те или иные роли, чтобы мы могли понять их цели, подобрать понятные для этой роли аргументы. Уверен, что вашему СТО совершенно без разницы, какой стейт-менеджер вы выбрали, т.к. у него другой уровень абстракции, другой масштаб целей и решений. Давайте кратко опишу эти уровни:

Cовладельцы, СЕО — Стратегия

1. С помощью какой стратегии мы превратим инвестиции в прибыль?
2. Это на каком рынке и с помощью каких конкурентных преимуществ?
3. Как это позволит нам создать доходный и устойчивый в долгосроке бизнес?
4. Какие финансовые и другие показатели мы таким образом хотим достичь?

CTO, COO, CPO, СМО — С-level — Концепт. Верхнеуровнево.

1. Какой продукт/сервис мы для этого создадим и как будем доставлять
ценность-опыт клиенту? (верхнеуровнево)
2. Какая оргструктура, инфраструктура и специалисты нам для этого нужны?
3. Какие бизнес-процессы (верхнеуровнево) за какие деньги позволят нам
производить и доставлять клиенту ту ценность-опыт, которую мы хотим?

Рукли направления, рукля команд — Механика. Что именно и как мы делаем согласно концепта.

1. Как именно мы отстроим эти бизнес-процессы?
2. Как и что будут делать какие конкретно люди в какие моменты?
3. Какие планы найма сотрудников для этого?

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

Нужно ли это простому разработчику?

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

Если хотите еще глубже понять каждую роль, то советую вам почитать книгу «От разработчика до руководителя».

После того как мы разобрались с уровнями абстракции, давайте перейдем к конкретным практикам, которые вам помогут:

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

Принцип позитивного намерения. Супер принцип, понимание и применение которого позволяет вам не просто «собачиться» и «холиварить», а действительно конструктивно двигаться в разговоре. Ну и этот принцип отлично помогает экономить нервы. Я часто применяю его за рулем — а вдруг тот, кто вас подрезал, не злостный нарушитель, который хочет разбить вашу машину, а спешит в больницу? Может, не стоит на него злиться, а просто пропустить его, пусть спешит дальше.(без перегибов, конечно)

Принцип безоценочности. Это, пожалуй, самое сложное. Но стоит практиковаться.

Принцип аргументации через выгоды собеседника. Принцип до безумия прост, все про это знают, но в момент спора забывают.

Правило формирования устойчивой договоренности. В идеале по SMART.

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