Александр Белькевич </> Frontend вдохновляет

#frontend_mylife

Расскажите, что вы изучали в последнее время? Нужно для контента в ближайшем будущем) чем больше вас ответит, тем лучше для меня 😃

#frontend_useful

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

pen.new - новый проект в Codepen

vue.new / react.new / ng.new / ts.new / js.new / nuxt.new- новый проект Vue / React / Angular / TS / JS / Nuxt в CodeSandbox

github.new / repo.new - новая репа на GitHub

figma.new - новый проект в Figma

meet.new - создание нового Google Meet

Это только несколько полезных шорткатов. Огромное множество других можно посмотреть здесь:

https://whats.new/shortcuts/

#frontend_useful

Пропустил как-то, но оказывается месяц назад ESLint стал поддерживать JSON и Markdown.

На самом деле полезная тема, рекомендую ознакомиться

https://eslint.org/blog/2024/10/eslint-json-markdown-support/

#frontend_post

🚀 Как понять, что ты уже Senior-разработчик?

Дисклеймер: все это субъективное мнение, поэтому всегда можно накинуть на вентилятор в комментариях 😃

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

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

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

3️⃣ У вас есть опыт работы с разными технологиями. Или хотя бы вы готовы пересесть при необходимости на другой стек. Senior-разработчику нужно уметь быстро адаптироваться к новым технологиям и инструментам. Вы должны знать, какие инструменты лучше всего подходят для конкретной задачи, и уметь их применять.

4️⃣ Вас приглашают участвовать в архитектурных обсуждениях. Когда команда начинает обсуждать архитектуру проекта, ваше мнение становится важным. Это значит, что ваши знания и опыт ценятся коллегами. Конечно, если в компании вы один Junior разработчик и больше никого нет, то вы тоже будете определять архитектуру, но мы не про такие ситуации говорим 😃

5️⃣ Вам доверяют важные проекты. Если руководство поручает вам сложные и ответственные задачи, это говорит о том, что они видят в вас профессионала высокого уровня.

6️⃣ Менторство. Вы начинаете помогать младшим коллегам, делиться своими знаниями и опытом. Это важный этап становления senior-разработчика.

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

8️⃣ Опыт работы с legacy-кодом. Умение разбираться в чужом коде и вносить изменения так, чтобы не сломать существующую функциональность, тоже является признаком senior-уровня. Да, иногда проще переписать код заново. Но не всегда есть на это время и деньги у бизнеса.

9️⃣ Рефлексия. Вы постоянно анализируете свою работу, ищете способы улучшить процессы и подходы. Это помогает вам расти профессионально.

Свое мнение смело пишите в комментариях 🙂 Ну и поддержите ❤️, чтобы я понимал, что вам заходят подобные посты.

#frontend_mylife

Судя по прошлому опросу немало тех, кто отказывался от офферов. Но есть и те, кто через это еще не проходил.

Для многих отказаться от официального предложения работать в какой-либо компании - это что-то из области фантастики.

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

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

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

Выбор между прямыми конкурентами

В конце 2020 года я неожиданно оказался без работы и стал "пылесосить" вакансии на разных сервисах. Я даже выкладывал здесь то, в какие компании я ходил и как проходили собеседования, но получилось так, что на LinkedIn мне написали 2 прямых конкурента.

Знаете, что самое интересное? Собеседования проходили очень похоже: максимальное дружелюбие, похожий стек, похожие проблемы, техническое собеседование с упором на софт-скиллы (а не "что такое eventloop") и так далее.

В итоге на руках у меня 2 оффера. Заработная плата одинаковая, условия одинаковые. В итоге выбирал исходя из популярности сервиса. Общался со знакомыми и мне говорили "ой, да, я пользовался этим проектом, мне нравилось". Ну и по итогу выбор был сделан только благодаря этому.

Отказ на финальном этапе

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

В итоге стал проходить стандартный набор "HR - Тех. собес - Общение тех. руководителем" в один из российских банков (нет, не Сбер и не Т-Банк).

И все проходило хорошо, все участники этой цепи были прекрасными. Я получаю оффер на руки и меня смущают ровно 3 строчки:

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

2. Обязанность сидеть от звонка до звонка с 9 до 18, ровно час на обед и за этим строго следят.

3. Заработная плата меньше оговоренной.

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

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

2. Можно гибко попробовать выстроить рабочий день. К примеру, не с 9 до 18, а с 8 до 17 или с 10 до 19. Но все остальное так же строго проверяется.

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

В итоге я отказался от такого щедрого предложения 😁

Расскажите, по каким причинам вы отказывали компаниям? Может, тоже были веселые и интересные истории 😊

#frontend_mylife

@frontend_lead_mentor раскопал промт для chatGPT, который на основе ваших запросов (если у вас они сохраняются в память) рисует вас и то, что ваш окружает.

На самом деле получается забавный результат)

Based on what you know of me, draw a picture of what you think my life currently looks like.

Попробуйте ввести в chatGPT промт выше и делитесь, что тем, что получилось 😃

#frontend_post

Как понять, что ты уже Middle?

Грейды (Junior, Middle, Senior) очень субъективны. Рано или поздно каждый разработчик сталкивается с тем, что при переходе из одной компании в другую он меняет грейд. Причем разменять cтатус Senior на Middle вообще легко - просто перейти в компанию более скилловую и узнать, что у тебя есть "болевые точки", которые надо улучшать для роста.

Но в целом, если закрыть глаза на бигтех (там требования, как правило, жестче), можно выделить основные отличия middle от junior.

🧐 Знание основных языков и технологий: Junior разработчик обычно хорошо владеет базовыми языками и технологиями, такими как HTML, CSS и JavaScript. Middle разработчик должен иметь более глубокие знания и опыт в работе с ними, а также умение применять их для решения более сложных задач.

👩‍💻 Работа с фреймворками. Да, на сегодняшний день Junior должен уметь работать с фреймворком на базовом уровне, но некоторые тонкости вылезают уже с опытом. И очень хорошо видно на собеседовании, встречались ли вы с ними.

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

😗 Умение работать в команде: Middle разработчики обычно участвуют в командной разработке, поэтому важно иметь навыки совместной работы, включая коммуникацию и совместные постановку и решение задач.

🪲 Middle разработчики должны быть способными решать более сложные технические задачи и принимать самостоятельные решения.

🙀 Проактивность и обучение: Middle разработчик должен проявлять инициативу в обучении новым технологиям и методам разработки, а также быть готовым делиться своими знаниями с junior разработчиками.

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

А как вы себя оцениваете, если отбросить синдром самозванца? И как бы вы отличали джуна от мидла?

#frontend_mylife

Говорят, чужие дети растут быстро. Но на самом деле свои растут ещё быстрее.

Вчера вроде был ещё маленький кабачок, а сегодня уже отмечали 5 лет 🙂

Время - ты куда бежишь то? 😃

#frontend_post

Недавно (на самом деле недели 3 назад, но я выпал из реальности на какое-то время) подписчик задал вопрос:

Как передавать знания о проекте новым разработчикам?

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

👋 Документация — это основа

Самое первое и важное — это качественная документация. Она должна быть не только технической, но и “человеческой”. Основные компоненты:

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

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

Описание основных сценариев использования: Покажите, как работают ключевые фичи с точки зрения пользователя. Это поможет разработчику быстрее понять логику проекта.

Все это можно описывать, например, в Confluence от Jira. Ну или в любом другом месте, где ваша команда взаимодействует.

👋 Как работают компоненты?

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

Для меня идеал - Storybook. Там можно и описание подробное сделать, и варианты использования показать.

👋 Выделите важные моменты

Часто встречающиеся баги и решения: В больших проектах есть “болячки”, с которыми сталкиваются все разработчики. Лучше предупредить о них заранее.

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

4. Интерактивное обучение

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

👋 Менторство и поддержка

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

👋 Обновляемость гайда

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

А как вы передаете знания в вашей команде? Или как, на ваш взгляд, было бы идеально это делать?

#frontend_mylife

В выходные не особо хочется читать что-то серьезное. Поэтому делюсь своим рабочим местом 😃

Делитесь своим сетапом) на чем и с чем работаете? 🙂

#frontend_mylife

Пока болел и были долгие бессонные ночи, нужно было себя чем-то занять)

Поэтому немало поизучал игры на Nintendo Switch, которую недавно купил.

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

2. Вторую часть Ori начал, но пока на начальном уровне) В первой части интересный сюжет. Здесь, судя по отзывам, драму и разные грустные моменты выкрутили на максимум. Я такое люблю, посмотрим)

3. Mario + Rabbits Kingdom Battle. Игра про знаменитого трубопроводчика и идиотских кроликов 😃 В принципе, весело) Много пошаговых боев (в принципе игра строится на них), яркая, сочная.

4. Ну и то, что вообще не отпускает пока: Animal Crossing. Строишь свой остров, заводишь мимишных игровых друзей в виде животных, делаешь свою ферму, устраиваешь торговлю, и платишь ипотеку 🤣 Игровое время привязано к реальному. То есть если у тебя ночь - в игре тоже ночь. У тебя зима - и там тоже. Пока топ из всего, что попробовал)

————

В понедельник выкачу очень интересный пост на тему организации рабочих процессов и создания библиотеки знаний 🙂

Если за долгое время накопилось ещё то, что хочется почитать от меня - пишите в комментариях)

#frontend_mylife

Короче. Обещал интересный пост и пропал по нескольким причинам:

- Интенсив. Не много, но отнимает время.

- Болезни. Мало спал и из-за этого котелок трещал по швам

- Много работы. Даже не так. МНОГО РАБОТЫ. Обязательно расскажу, но чуть позже.

Сегодня кое-как возвращаюсь к блогу. Готовлю новый интересный пост, который обещал. Не теряйте

#frontend_mylife

На работе лид установил AI для митов, чтобы собирать главные тезисы, которые потом приходят на почту 😃

На самом деле прикольная тема)

Прикладываю ссылку, с помощью чего сделано)

https://tldv.io/

#frontend_mylife

Завтра или в понедельник выпущу пост на тему, которую предложил подписчик 🙃

А сегодня ребята с интенсива будут начинать получать доступы к интенсиву и завтра начнется плотная работа ❤️

2 задания: разработка виджета с комментариями и работа с API Telegram

Призовой фонд: 8000 рублей

Все места разобраны, но 2 места выделю дополнительно. Так что кто решил оставить запись на последний день - пишите в личку :)

#frontend_mylife

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

Пока - больно) То что видно на скриншоте (59 ошибок) - это малая часть ошибок. В сумме около 350 вылезло. И это у нашей команды не самый большой проект)

❤️ жмякай для поддержки моральных сил

У вас, кстати, есть опыт перехода на новый стек или обновление старого до актуальной версии?