🥸 О мифе сеньорского кода и чистоте разработки

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

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

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

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

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

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

Вот основные принципы хорошего кода:

✏️ Декомпозиция: разбивайте код на более мелкие, логичные части. Это упрощает понимание, отладку и позволяет использовать код повторно.

✏️ Разделяйте ответственность: каждая функция, компонент или модуль должны выполнять одну конкретную задачу. Это делает код более предсказуемым и простым в поддержке.

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

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

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

✏️ Делайте компоненты модифицируемыми: при разработке учитывайте возможность добавления новой функциональности без изменения уже существующего кода. Это упростит поддержку и добавление новых фич.

✏️ Избегайте жесткой связанности модулей: минимизируйте зависимости между модулями. Если один компонент сильно зависит от другого, это усложнит поддержку и тестирование. Используйте инъекцию зависимостей и интерфейсы для уменьшения связанности.

💡 В 80% случаев хороший код — это не паттерны, а простая логика и внимание к деталям.

#frontend #react #senior

👩‍💻 Подключение компонента с помощью connect

Хотя хуки являются современным способом работы с Redux, вы также можете использовать метод connect из библиотеки react-redux для подключения компонентов к Redux. Это более старый способ, но он по-прежнему широко используется и имеет свои преимущества.

// Компонент
const TodoList = ({ todos, addTodo, removeTodo }) => {
    // some logic
    return ();
};

// Определяем, какие данные из Redux store передать компоненту
const mapStateToProps = (state) => ({
    todos: state.todos.todos,
});

// Определяем, какие действия передать компоненту
const mapDispatchToProps = {
    addTodo,
    removeTodo,
};

// Подключаем компонент к Redux
export default connect(mapStateToProps, mapDispatchToProps)(TodoList);

Делаю сейчас курс по Redux + Redux Toolkit + RTK Query и вспомнил, как раньше подключались компоненты. Блин, выглядит круто. Может снова так делать.😅

Кто помнит? Олды есть?

#redux #react

👩‍💻 Принципы Redux

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

🔒 Единое хранилище (Single Source of Truth)

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

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

const initialState = {
    todos: [],
    user: null,
};

// Всё состояние хранится в одном объекте
const state = {
    todos: ['Задача 1', 'Задача 2'],
    user: { name: 'Иван', age: 30 },
};

👀 Состояние только для чтения (Read-Only State)

Единственным способом изменения состояния является отправка действия (action). Это гарантирует, что изменения состояния происходят только через определенные точки (actions), что делает их предсказуемыми.

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

// Действие для добавления задачи
const addTodo = (text) => ({
    type: 'ADD_TODO',
    payload: text,
});

// Изменение состояния только через действие
store.dispatch(addTodo('Новая задача'));

✨ Чистые функции редюсеры (Pure Functions)

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

Чистые функции делают состояние предсказуемым и упрощают отладку. Они не имеют побочных эффектов и не влияют на внешние состояния.

const todoReducer = (state = initialState, action) => {
    switch (action.type) {
        case 'ADD_TODO':
            return {
                ...state,
                todos: [...state.todos, action.payload],
            };
        default:
            return state; // Возвращаем новое состояние, не изменяя текущее
    }
};

⬇️ Однонаправленный поток данных (Unidirectional Data Flow)

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

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

// Пример потока данных
const mapStateToProps = (state) => ({
    todos: state.todos,
});

// Компонент получает данные
const TodoList = ({ todos }) => (
    <ul>
        {todos.map((todo, index) => (
            <li key={index}>{todo}</li>
        ))}
    </ul>
);

// Связываем компонент с Redux
export default connect(mapStateToProps)(TodoList);

#redux #frontend #react #flux

🖥 Функция-конструктор в JavaScript

Она позволяет задавать шаблон для объектов, чтобы каждый новый объект, созданный через этот конструктор, имел определенные свойства и методы. Давайте разберем, как работает функция-конструктор.

✏️ Создание функции-конструктора
Функция-конструктор выглядит как обычная функция, но она пишется с заглавной буквы по соглашению, чтобы отличаться от других функций. Внутри конструктора используется this для задания свойств создаваемого объекта.

function Person(name, age) {
    this.name = name; // свойство name
    this.age = age;   // свойство age
}

🎮 Создание объектов с помощью конструктора
Чтобы создать объект с помощью конструктора, используется оператор new. Он:

- Создает новый пустой объект.
- Связывает его с this внутри конструктора.
- Возвращает этот объект.

const person1 = new Person("Alice", 25);
console.log(person1.name); // Alice
console.log(person1.age);  // 25

➕ Добавление методов в конструктор
Если мы добавим метод прямо в конструктор, то он будет копироваться в каждый новый объект, что может тратить память.

function Person(name, age) {
    this.name = name;
    this.age = age;
    this.sayHello = function() {
        console.log(`Hi, I'm ${this.name}`);
    };
}

const person1 = new Person("Alice", 25);
person1.sayHello(); // Hi, I'm Alice

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

function Person(name, age) {
    this.name = name;
    this.age = age;
}

Person.prototype.sayHello = function() {
    console.log(`Hi, I'm ${this.name}`);
};

const person1 = new Person("Alice", 25);
const person2 = new Person("Bob", 30);

person1.sayHello(); // Hi, I'm Alice
person2.sayHello(); // Hi, I'm Bob

💭 Как работает this в конструкторе
В функции-конструкторе this указывает на новый объект, который создается при вызове через new. Это позволяет настраивать свойства и методы нового объекта.

💎 Продвинутые аспекты
- Наследование. Используя прототипы, можно создавать наследуемые свойства и методы.
- Проверка с instanceof. Для проверки, создан ли объект через конструктор, можно использовать instanceof.

console.log(person1 instanceof Person); // true

#javanoscript #this #function

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

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

Накрутка, фильтры и нейронки не нужны, если каждый начнет выполнять свою работу на 100%.

Посмотрите видео Антохи, рекомендую 👍

🔗 https://www.youtube.com/watch?v=XMh6jFELLsw

⛔️ Топ причин, по которым могут уволить во время испытательного срока

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

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

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

💡 Что делать:
- Проверяйте верстку на соответствие макету с помощью Pixel Perfect.
- Старайтесь устранять все замечания разом, чтобы не засыпать коллег бессмысленными коммитами.

2. Отправка неаккуратных Pull Request
Задача — отправлять чистый, аккуратный коммит с минимальным количеством файлов и изменений. Если в файле не было задачи или необходимости в правках, не вносите туда изменения, даже если это просто пробел, кавычка или отступ. Изменение структуры, не связанной с задачей, отвлекает и создает беспорядок в истории проекта.

💡 Что делать:
- Добавляйте в PR только те файлы, которые реально были затронуты задачей.
- Не меняйте стили и форматирование файлов, если это не связано с вашей задачей.

3. Отправка нерабочей функциональности
Если вы сделали кнопку для открытия меню, убедитесь, что меню действительно открывается. Когда тестировщик запускает ваше приложение и видит, что оно не работает, это считается серьезной ошибкой. Подобные ошибки сразу попадают в "черный список". Ошибки функциональности — это прямой показатель недоработки перед сдачей.

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

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

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

❗️ Следите за тем, что вы даете на проверку!

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

Учитесь работать над ошибками и доводить каждую задачу до идеала.

#frontend #work

🥵 Стресс после трудоустройства

Трудоустройство в IT — это всегда вызов. Независимо от уровня опыта, у большинства возникают одинаковые опасения: "Разберусь ли в проекте?", "Не разочарую ли команду?", "Смогу ли выполнить ожидания?" Эти вопросы сопровождают нас не только в начале карьеры, но и спустя годы работы.

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

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

💡 Вот несколько советов для снижения стресса на новом месте:

1. Дайте себе время
Не требуйте от себя всего сразу. Привыкание к проекту занимает время.

2. Задавайте вопросы
Никто не ожидает, что вы всё знаете. Спрашивайте — это быстрее приведет к пониманию задач.

3. Осваивайте поэтапно
Беритесь за одну задачу за раз, избегайте перегрузки.

4. Найдите коллег для поддержки
Опытные сотрудники могут поделиться знаниями и упростить адаптацию.

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

6. Снимите самокритику
Ошибки неизбежны. Оценивайте свои усилия, а не только результаты.

7. Берегите здоровье
Режим сна и питания помогут избежать выгорания.

Антоха на стриме рассказал подробнее про трудоустройство и испытательный срок. Кстати, у него новый YouTube-канал — в ближайшее время он выпустит много годного контента 👍

https://www.youtube.com/live/KMsrfLvRLN0?si=TEFseo6--7wDmqGF&t=520

👩‍💻 React Новости

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

Ставьте лукас, если смотрели React Новости 👍

🔗 Ссылка на видео

🖥 DOM Mutation Observer

Mutation Observer — это интерфейс, позволяющий отслеживать изменения в DOM, такие как добавление или удаление элементов, изменение атрибутов или текста. Он предоставляет более эффективный способ наблюдать за изменениями, чем старые методы вроде Mutation Events, так как не блокирует поток выполнения и может отслеживать сразу несколько изменений.

Mutation Observer полезен, если нужно:
- отслеживать изменения в структуре DOM (например, добавление или удаление элементов);
- реагировать на изменения атрибутов элементов;
- мониторить текстовое содержимое элементов, например, для динамически обновляемых данных.

Создание Mutation Observer

Создать Mutation Observer можно с помощью конструктора MutationObserver, в который передается колбэк-функция. Эта функция будет вызываться с массивом записей (`MutationRecord`), описывающих изменения.

const observer = new MutationObserver((mutationsList) => {
  mutationsList.forEach((mutation) => {
    console.log(mutation);
  });
});

Каждый объект `mutation` в `mutationsList` содержит информацию о произошедшем изменении, включая:
- `type` — тип изменения (`childList`, `attributes`, или `characterData`);
- `target` — целевой элемент, где произошло изменение;
- `addedNodes` и `removedNodes` — список добавленных или удаленных узлов, если `type` — `childList`;
- `attributeName` — имя измененного атрибута, если `type` — `attributes`.

Начало наблюдения

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

const targetNode = document.getElementById('targetElement');
observer.observe(targetNode, {
  childList: true, // следить за добавлением и удалением дочерних элементов
  attributes: true, // следить за изменением атрибутов
  characterData: true, // следить за изменением текстового содержимого
  subtree: true // отслеживать изменения во всех потомках
});

Остановка наблюдения

Когда больше не нужно отслеживать изменения, можно остановить наблюдение с помощью метода disconnect():

observer.disconnect();

Полезные параметры конфигурации
- `childList`: отслеживает добавление и удаление дочерних элементов.
- `attributes`: отслеживает изменения атрибутов у целевого элемента.
- `characterData`: отслеживает изменения текстового содержимого.
- `subtree`: если установлено в `true`, позволяет отслеживать изменения не только у целевого элемента, но и у всех его потомков.

#javanoscript #observer

🖥 Intersection Observer

Intersection Observer — это интерфейс, позволяющий отслеживать, когда элемент появляется в зоне видимости, перекрывает другой элемент или выходит за границы видимой области (viewport). Он предоставляет эффективный способ наблюдения за видимостью элементов, чем старые методы вроде событий прокрутки и проверки getBoundingClientRect(), так как не вызывает перерисовку и работает асинхронно.

Intersection Observer полезен, если нужно:
- отслеживать появление элементов на экране (например, для ленивой загрузки изображений);
- анимировать элементы при их появлении в зоне видимости;
- отслеживать видимость рекламы или элементов пользовательского интерфейса.

Создание Intersection Observer

Создать Intersection Observer можно с помощью конструктора IntersectionObserver, в который передается колбэк-функция. Эта функция будет вызываться с массивом записей (IntersectionObserverEntry), описывающих пересечения.

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    console.log(entry);
  });
});

Каждый объект entry в entries содержит информацию о пересечении, включая:
- isIntersecting — флаг, указывающий, находится ли элемент в зоне видимости;
- target — целевой элемент, для которого произошло пересечение;
- intersectionRatio — процент видимой части элемента;
- boundingClientRect — размеры и положение целевого элемента относительно видимой области.

Начало наблюдения

Чтобы начать наблюдение, нужно использовать метод observe и указать целевой элемент:

const targetNode = document.getElementById('targetElement');
observer.observe(targetNode);

Остановка наблюдения

Когда больше не нужно отслеживать пересечения, можно остановить наблюдение с помощью метода unobserve() или полностью прекратить работу с disconnect():

observer.unobserve(targetNode);
observer.disconnect();

Полезные параметры конфигурации

При создании IntersectionObserver можно указать дополнительные настройки, которые управляют его поведением:
- root: элемент, который будет использоваться в качестве контейнера для отслеживания видимости. По умолчанию — null, то есть будет использоваться viewport.
- rootMargin: отступы вокруг root, которые позволяют изменять зону видимости (например, rootMargin: "0px 0px -50% 0px").
- threshold: массив значений (от 0 до 1), задающий, какой процент видимости элемента должен быть достигнут, чтобы вызвался колбэк. Например, threshold: [0, 0.5, 1] вызовет колбэк при 0%, 50%, и 100% видимости.

#javanoscript #intersection_observer

🥸 Дедовщина в IT

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

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

Если будет время, посмотрите это видео на досуге. База 💯.

https://www.youtube.com/watch?v=MGWZP4OjCHM

🤫 Почему ИИ не заменит программистов

Ко мне часто приходят на консультации по фронтенд-разработке, и один из самых популярных вопросов звучит так:
"А стоит ли вообще начинать учиться, если ИИ скоро заменит программистов? Я боюсь, что выучу всё, а работы не будет, потому что всё будут делать машины."

Я решил поделиться своими мыслями на эту тему. Вот несколько причин, почему я уверен, что ИИ не заменит программистов:

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

Креативность и нестандартное мышление
Программирование — это не просто написание кода. Это поиск новых решений, генерация идей и эксперименты. ИИ отлично справляется с рутиной, но творческий процесс, интуиция и способность мыслить "вне коробки" остаются человеческой прерогативой.

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

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

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

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

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

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

❓ А что вы думаете?

#ai

👀 Контроль сотрудников на работе: история из личного опыта

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

Рабочий день начинался с обязательного включения тайм-трекера. Программа фиксировала всё: время работы, активность на клавиатуре и мыши, а также записывала экран. Если активность снижалась, мог последовать вопрос от тимлида: "Почему у тебя так мало активности? Ты целый день ничего не делал?".

Самое сложное заключалось в том, что после 10 минут бездействия таймер сбрасывался на 10 минут назад и останавливался. Нужно было набирать ровно 8 часов активности — ни минутой меньше. Представьте, как я бегал в туалет, делал чай или обедал! У меня не было ноутбука, поэтому я буквально каждые 8 минут возвращался к компьютеру, чтобы не сбился таймер.

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

Этот опыт научил меня многому, но и вымотал колоссально. Теперь я с пониманием отношусь к людям, которые сталкиваются с подобными системами контроля.

А у вас был подобный опыт? Делитесь в комментариях!
Если интересна тема, рекомендую видео Антохи: https://youtu.be/3eMAc4Dc5sY.

Флешбеки до сих пор... 😬

🚀 [Версия 1.0.0] - Релиз платформы!

Привет, друзья! 🎉 Мы рады сообщить, что первая версия нашей платформы готова и доступна! В этой версии:

✔️ Добавлен сервис подготовки к собеседованиям.

Мы сделали первый шаг и теперь работаем над новыми фичами, чтобы помочь вам ещё быстрее и эффективнее подготовиться к важным этапам в карьере. Ваши отзывы очень важны для нас, пишите, что вам нравится и что можно улучшить! 💬

🔥 Что дальше? Следите за обновлениями – скоро будет ещё больше интересных возможностей!

👍 Обучайтесь, общайтесь, растите вместе с https://yeahub.ru

#release #news #update #yeahub

Какие претензии у айтишников к новичкам?

Это дополнение к посту о Дедовщине в IT. Стрим про Гейткиперов)
Залетайте на стрим 🔥

https://www.youtube.com/watch?v=fGl689uzDuY