📅 Дайджест за Январь 2024

Начал новую практику для себя: собираю интересный контент за месяц и публикую в виде некоего дайджеста.
Формат и наполнение будут меняться.

https://drugoi.dev/digests/2024-01/

@drugoi_dev

⚡️ AlmatyJS Light #4 — Call For Papers

Всем привет!

Мы готовим новый AlmatyJS Light и хотим видеть вас в числе наших спикеров. Будет здорово, если вы расскажете о теме, которая вас заинтересовала, или поделились своей последней болью в разработке. Ждем ваших идей!

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

→ Заполняйте форму и делитесь знаниями с сообществом: https://forms.gle/NrYUHRcBSRGrbfNPA

→ Ограничение по времени доклада: 10 минут + 10 минут на вопросы;

→ Дедлайн подачи заявок: 01.03.2024 (1 марта 2024);

#анонсы

@almaty_js

Поддержите этот канал 💫

Нравится контент? Поддержите автора донатом! Спасибо за поддержку! 🙏

Я снова тестирую ботов для AlmatyJS, донат не обязателен 🌚


Напомню свою точку зрения насчет донатов — https://t.me/drugoi_dev/37

🎯 Сообщества Frontend KZ достигли нескольких мини-рекордов в этом году

Сообщество Dart / Flutter KZ достигло 1000 человек, основной чат Frontend KZ добрался до 4000 человек, а его младший брат чат для начинающих фронтендщиков подбирается к 1000 участников.

Сообщество зародилось в 2014 году, как чат в Skype, который затем переехал в Slack и, в итоге, был смёржен с сообществом AST Frontend в Telegram.

Уже 10 лет сообщество помогает развиваться молодым разработчикам, повышает прозрачность рынка и генерирует мемы.

Да, много над чем надо поработать, улучшить как процессы, так и контентную часть, но хочется сказать спасибо:

Спасибо бывшим и текущим администраторам сообществ за поддержку и модерацию.
И спасибо всем участникам сообщества за ваше участие в жизни сообщества!

📣 Про подготовку к конференциям

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

Во время подготовки своего доклада на BeeTech Conf 2024, где я выступаю на следующей неделе, я каждую итерацию обновления доклада узнаю что-то новое. А с учётом, что моя тема на хайпе — каждый день выходят какие-то обновления или новости. Часть вещей пришлось даже вырезать, т.к. вышли опровержения эффективности тех или иных инструментов.

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

Заполните форму по ссылке — https://forms.gle/47jn1n5yNJZTMFGR7
Форма принимает ответы сегодня до 23:00.

Завтра (18.04.2024) в 13:00 я проведу розыгрыш через Random.org.

Условия участия
1. Быть подписанным на канал @drugoi_dev.
2. Заполнить форму, где нужно указать своё ФИ и свой никнейм в телеграме.

P.S. Если у вас уже есть билет, то вы не можете участвовать, так как билет будет именным и передачи не подлежит.

Результаты розыгрыша

Рандом распорядился вот так.

Спасибо за участие, ребята!

Победитель @codev0, напиши мне в личные сообщения.

Увидимся на BeeTech Conf 2024.

При подготовке к BeeTech Максим нам отправлял эту памятку и она очень помогла правильно построить презентацию, рекомендую!

Как подготовить публичное выступление

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

Спешу поделиться и с вами

📹 Выступление на BeeTech 2024

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

Ну, а пока, вот вам видео с моим выступлением с конференции BeeTech 2024 с темой «AI ваш друг: улучшаем DX голыми руками»

https://www.youtube.com/watch?v=4QYl1VCt7XQ

📈 Быть сеньором — это не про код

Все мы когда-то были сеньорами или когда-нибудь ими станем.

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

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

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

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

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

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

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

На этом карьерном этапе для вас важнее всего стабильность или даже то, что на английском называется sustainability (слово «устойчивость» как будто несёт немного другой смысл).

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

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

@drugoi_dev

📣 Билеты на AlmatyJS #4 уже доступны

Финальное расписание докладов будет доступно на следующей неделе, а сейчас мы с радостью хотим объявить список спикеров на предстоящий AlmatyJS #4:

«Рынок никогда не ошибается?» — Андрей Васильев
«Biz+Dev=❤️» — Сергей Андреев
«Продуктовая аналитика или как понять насколько хорош ваш продукт?» — Уалихан Оразбаев

«Улучшаем UX с помощью streaming» — Павел Гасанов
«Рецепты MobX. Продвинутые практики для больших проектов» — Максим Титов
«Срочно выпускай это в прод» — Максим Горбатюк

«Назад в будущее: автостопом по трендам веб-разработки» — Атай Кебеков
«No-console: юзай devtools по назначению» — Адыл Жоро

Билеты доступны для покупки на Sxodim 🔥
Ждём вас 21 сентября в 12:00 на AlmatyJS #4.

Спасибо нашим партнёрам из MOST IT Hub за помощь в организации митапа.

@almaty_js

🚢 Д — декомпозиция

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

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

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

1. Понятно ли мне, что от меня хотят? (самый главный вопрос)
2. Понятно ли мне, как выглядит задача в статусе «готово» (DOD)?
3. Могу ли я описать все шаги, которые необходимо пройти для завершения задачи? Например, могу ли я составить список подзадач и будет ли он полным?
4. Есть ли у меня все пререквизиты для начала работы над задачей, и нет ли каких-то зависимостей или заранее известных блокеров?

Если вы не можете ответить однозначно «да» на все эти вопросы, то это значит, что задача недостаточно декомпозирована, и необходимо продолжить процесс её детализации, пока не будет получен утвердительный ответ на каждый из вопросов.

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

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

@drugoi_dev

📆 Главные уроки первого года в менеджменте

Прошёл уже год (и даже больше) с тех пор, как я занял позицию Head of Web & Mobile Development в Bereke Bank.

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

Не мгновенные результаты

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

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

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

Думаю, этот навык мне ещё предстоит улучшать, поэтому в следующем году я сделаю акцент на стратегическом планировании изменений.

Самое интересное, что меня об этом предупреждали (Саша К. и Паша К., привет 👋), но всё же это стало самым серьёзным изменением в моей работе за последние 12 лет.

Люди — это не код

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

Когда ты менеджер, твоё основное взаимодействие происходит с людьми (и с экселем 🤡). В самые пиковые дни только количество активных персональных чатов достигает 40 штук, не говоря уже о взаимодействии с людьми в офисе.

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

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

Без приоритетов никуда

Если посмотреть на бэклог того, что нужно и хочется сделать, может показаться, что я в ближайшие пять лет точно никуда не уйду 😉. Можно даже не брать новые задачи в работу. Но, как и в разработке, в менеджменте очень сильно влияют приоритеты. Часть из них задаются общим темпом компании и руководства, часть формируешь ты сам.

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

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

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

В конце хотел бы зафиксировать мысли, которые я повторяю про себя, сталкиваясь с различными ситуациями на работе:

1. Не все такие, как ты.
2. Всем не поможешь, но важно создать возможности для людей.
3. Возраст совсем ни на что не влияет.

Я тут в пятницу в небольшой панельной дискуссии участвую, приходите поздороваться :)