Пару месяцев назад у нас с Айратом разгорелась дискуссию на тему эффективности работы в офисе и на удалёнке.

С началом пандемии мы ушли из офисов в домашние офисы и я помню разговоры в офисе, в середине марта 2020 года, про то, что «эта удалёнка всего на пару недель», но лично для меня удалёнка продолжается до сих пор* и я испытываю почти максимальное удовольствие от неё.

Правда, как только пандемия немного отступила, то многие компании решили вернуть сотрудников в офисы. Это произошло и с моей командой в Альфе, мы вернулись на гибридный график до следующей вспышки заболеваний (т.е. примерно на месяц) и больше уже не возвращались.

Хочу поделиться мыслями про удалёнку и почему мне она нравится:

1 — Организация работы на удалёнке

Если вдруг вы не читали книгу Джейсона Фрайда и DHH «Remote. Офис не обязателен» (Remote: Office Not Required), то там есть очень важная мысль про то, что невозможно уйти на удалённую работу, если сам работодатель не создаёт условия для этой удалённой работы.

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

Когда нам настроили нормальный доступ без RDP производительность нашей команды выросла в разы и за время нахождения в локдауне (а это больше месяца) — мы запустили сразу несколько кредитных продуктов и провели хороший рефакторинг.

2 — Правильная организация рабочего времени

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

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

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

3 — Правильное рабочее место

Рабочее место и рабочий сетап (WFH setup) — это, наверное, одни из самых больших моих инвестиций в продуктивность и эффективность на удалёнке. Многие компании предоставляют бюджет для оснащения домашнего офиса и рекомендую использовать его по максимуму: хороший стол, кресло, эргономичная клавиатура и хорошее освещение. Моё рабочее место до недавнего времени выглядело вот так и я не знаю ни одного офиса в Алматы, который был бы подготовлен для работы таких больших людей, как я.

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

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

Примерно половина моей карьеры прошла именно так

Удобный GitHub

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

Быстрый опрос моих друзей-разработчиков показал, что не многие знают, что есть расширение, которое в разы улучшает пользовательский опыт на GitHub — это Refined GitHub. Вы только посмотрите на список фич, которые там реализовали — https://github.com/refined-github/refined-github#highlights-

Безусловно, одно из самых полезных расширений и которое никак не нужно настраивать. В качестве полезного дополнения могу назвать ещё OctoLinker, благодаря которому можно переходить по импортам из ваших файлов в другие файлы — https://github.com/OctoLinker/OctoLinker.

⛵️ Элемент за вьюпортом!

Раньше, когда я часто занимался вёрсткой и делал адаптивные интерфейсы, то иногда я сталкивался с тем, что некоторые элементы выходили за пределы viewport и появлялись зоны горизонтального скролла.

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

Для таких случаев я пользовался следующим хаком, через кастомный CSS:

*,
*:after,
*:before {
  outline: 1px solid red;
}

На все элементы на странице вешаем красный outline в 1px и находим виновников поехавшей вёрстки.

Сегодня увидел более элегантное решение с использованием JavaScript:

document.querySelectorAll('*').forEach((el) => {
  if (el.offsetWidth > document.documentElement.offsetWidth) {
    console.log(el);
  }
});

Ищем всем элементы на странице, если offsetWidth элемента больше, чем offsetWidth нашего документа — выводим элемент в консоль, а уже после этого мы можем (как минимум, в Chrome) нажать правой кнопкой на элемент в консоли и выбрать Scroll into view, чтобы увидеть его на странице.

Останется только поправить проблему и заниматься вёрсткой дальше.

У нас открыт CFP на следующий AlmatyJS Light.

А также мы ищем интересные помещения для проведения митапов с оборудованием (90+ человек, проектор/экран, звук), можете кидать предложения в комментариях или мне в личные сообщения.

https://t.me/almaty_js/90

GitHub Copilot X

Пока мы празднуем Наурыз, GitHub выпустили анонс GitHub Copilot X — развитие Copilot вместе с GPT-4 под капотом, поддержкой чата и голосовых запросов, интеграцией в Pull Request-ы и генерированием документации.

Сейчас Copilot автодополняет ваш код тоже вместе с AI, но Copilot X унесёт нас в будущее программирования, где AI становится вашей “уточкой” и вашим коллегой в парном программировании.

Фичи, которые меня впечатлили:

Генерация тестов внутри PR: AI анализирует код и даёт рекомендацию по обновлению или созданию тестов — https://githubnext.com/projects/copilot-for-pull-requests#gentest

Ревью PR: это просто невероятная оптимизация рабочего времени, особенно, когда работаешь с джуниор разработчиками — https://githubnext.com/projects/copilot-for-pull-requests#reviewing-pull-requests-with-ai

Записываемся в Waitlist и ждём — https://github.com/github-copilot/chat_waitlist_signup/join

Если вы сегодня увидели похожую ошибку при попытке пуша в GitHub, то вы не одиноки.
GitHub, случайно, хост ключ обновили сегодня.

Надо перегенерить ключи и добавить хост потом в разрешённые — ssh-keygen -R github.com

https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

Анонс новых митапов на последнем @almaty_js

Ребята, я пока что тестирую, донатить не обязательно.

Но спасибо всем, кто уже совершил пожертвование 🤝

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

Вчера вышел эпизод Kolesa Podcast записанный с моим участием.

Для меня это был первый опыт записи в подкасте и мне очень понравилось то, как легко и быстро у нас прошла запись этого эпизода.
Старался не торопиться, чтобы люди что-то поняли 😀
Этот эпизод больше направлен на людей, которые только хотят войти в IT и на ранних этапах своей карьеры, но не смотря на это есть моменты, когда я уходил в исторический обзор и вспоминал про времена jQuery и становление фронтенда в Казахстане.

Спасибо Кристине Абдраимовой и Вадиму Манченко за возможность поговорить на такую интересную тему.
Отдельная благодарность моим подписчикам и друзьям за поддержку в соц.сетях и на YouTube.

Смотрите эпизод по ссылке — https://www.youtube.com/watch?v=Fded-9B6Pwg

Аудиоверсии доступны в Apple Podcast и Яндекс.Музыке.

💡 Про бремя знаний

За последние 10 лет я сделал разные пет/фан-проекты:

1. Расширения iNikolayev и kNurtas, которые меняют картинки на странице на фотографии Игоря Николаева или Кайрата Нуртаса;
2. Telegram бот для проверки баланса на карточке ONAY (отключен, т.к. разработчики закрыли доступ к API на проверку);
3. Telegram бот для быстрого (инлайн) перевода с казахской кириллицы на казахскую латиницу;
4. Telegram бот для Almaty Bike (пока что не работает, т.к. я не активный пользователь системы);
5. Telegram канал с парсингом новых казахстанских доменов;
6. Твиттер бот с курсом тенге по данным Нацбанка;

Наверное, было что-то ещё, что я уже не припомню или проект не оставил особый след.

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

Мне важно было получить моментальный фидбек от пользователей или просто удовольствие от разработки, изучая что-то новое (например, Geospatial Queries запросы в Almaty Bike боте, чтобы достать ближайшие к пользователю станции).

Сейчас у меня в голове крутятся несколько проектов, разной степени проработанности и сложности, но меня что-то останавливает от их реализации.

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

Я насмотрелся «хороших» подходов к разработке и теперь не могу начать делать что-то, пока у меня не будет условной доски в JIRA, где будут все задачки. Дизайны не будут лежать в Figma. CI/CD настроено и отлажено.

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

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

📩 Виды резюме, которые я ненавижу (у разработчиков)

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

С одной стороны, это экономило время, т.к. до собеседований доходили кандидаты ± подходящие для собеседования, с другой стороны — мне приходилось смотреть на кучу непонятных, пустых или нерелевантных резюме, которые каким-то образом попадали в выборку от наших рекрутёров. С теми рекрутёрами, что проводили в банке достаточно много времени, у меня получалось наладить работу так, что ко мне попадали только релевантные резюме, но с новыми рекрутёрами всегда приходилось проходить этап, когда присылают резюме не подходящих кандидатов, ещё и в формате doc/docx 😀

Я выделил следующие виды резюме, которые мне не нравятся:

Резюме для всего

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

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

Классическая ситуация: у кандидата указан опыт в 10 лет, из них 1 год опыта в IT и 9 лет опыта мерчендайзером.

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

Резюме без информации

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

Компания ABC — Разработчик — 04.2020 - 04.2023

И добить эту ситуацию может описание для позиции: «Писал код»

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

Резюме, где очень много информации

Один раз мне попалось резюме, где кандидат перечислил задачи из JIRA, которые он делал. Прям так и написал:

JIRA-1234 — Кнопка «Войти» на странице авторизации
JIRA-1235 — Кнопка «Выйти» в меню

И так далее.

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

Идеальное резюме

Для меня, идеальное резюме — это то, которое даёт понять, что за кандидат стоит за ним.

Я выделяю следующие важные пункты резюме:

1. Актуальный опыт работы — не забывайте отправлять самое свежее резюме рекрутёру.
2. Технологический стэк по последним позициями — если наша вакансия срочная, то нам важно найти человека, который быстро поймёт или уже работал с нашим стэком.
3. Нормальное описание вашей работы — какие цели были выполнены, какие фичи (крупные) были реализованы, цифры (уменьшил размер бандла на 200кб) очень хорошо усиливают резюме.
4. Nice to have: короткий блок «Обо мне» и ссылка на ваш GitHub, где есть что-то. Если у вас пустой GitHub или вы вообще не активны на нём, то лучше не тратить время и не добавлять ссылку на него.

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

Ваше резюме — это ваше лицо.

Картинка в слайде передаёт моё состояние.

Сегодня на CodeFest пришёл послушать Нам Максима с докладом про переход проектов из аутсорса в инхаус.

Совсем скоро я вернусь с полезными постами в канал и сделаю несколько объявлений, но пока есть такая новость:

12 октября, силами AlmatyJS и Altel Digital, пройдет Hacktoberfest 2023 Central Asia, часть глобальной инициативы DigitalOcean, ILLA Cloud и Appwrite по распространению Open Source.

Я большой фанат открытого кода и для меня всегда было приятно, когда у кандидатов на собеседованиях был хоть какой-нибудь вклад в OSS проекты, поэтому я, впервые за долгое время, решил выступить с докладом «Как перестать бояться и сделать первый PR».

До встречи на митапе!

https://events.mlh.io/events/10428-hacktoberfest-2023-central-asia-almaty

Сегодня на сцене Hacktober Fest Никита Баев.
Никита - руководитель центра компетенций Front в Береке банк, co-founder AlmatyJS, founder Nikita paper company и разработчик с опытом более 10 лет, выступает с докладом «Как не бояться и сделать свой первый PR»

🥷🏼 Список вещей, которые должен знать Senior

Недавно набрёл на статью Камиля Фурнье о вещах, которые должен уметь Senior разработчик кроме разработки.

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

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

Я выбрал несколько пунктов, с которыми часто сталкиваюсь в работе:

1. How to take negative feedback gracefully

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

2. How to tell someone they’re wrong without making them feel ashamed

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

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

3. How to help someone get promoted

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

4. How to communicate project status to stakeholders

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


А что для вас является признаком хорошего Senior разработчика?

Остальные пункты по ссылке — https://www.elidedbranches.com/2021/06/an-incomplete-list-of-skills-senior.html (Web Archive)

Третье выступление с нашей конференции Hacktoberfest Central Asia!

Никита Баев, Руководитель Центра Компетенций в Bereke Bank, рассказал о том, как перестать бояться и сделать первый PR. Это, можно сказать, пошаговая инструкция для начинающих и не только о том, как начать контрибьютить в Open Source. Плюсы, минусы, подводные камни - про все это в выступлении Никиты.

Смотреть

🙋🏼 Всем привет, на связи Никита.

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

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

🎄 2023 заканчивается

Так как это мой “экспертный” канал, то хочется подвести мои “профессиональные” итоги года.

График коммитов на GitHub очень ярко показывает самое главное изменение в этом году — впервые в жизни я перешёл на менеджерскую роль в «Bereke Bank», чтобы развивать Центр Компетенций по разработке фронтальных систем.

Это большой вызов для меня, т.к. последние 11 лет я большую часть времени уделял только разработке и работа с людьми занимала малый процент моей работы, а теперь наличие свободных слотов в календаре удивляет меня 😁

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

Между делом помог команде abr tech сделать важные улучшения продукта abr+ и вывести бронирование в ресторанах (которое я просил сделать ещё в 2020 году) на самые загруженные рестораны сети.

Это было непростой год, полный перемен и новых вызовов. Смотрим в светлое будущее в 2024 году и никогда не останавливаемся.

Всех с наступающим Новым годом!